>DevOps Interview KB

Why does Google recommend uniform bucket-level access over fine-grained ACLs, and what actually breaks when you enable it on an existing bucket?

IntermediateConceptualPracticalGcpCloud Storage6 min read

Short Answer

Fine-grained access lets individual objects have their own ACLs independent of the bucket's IAM policy, which is flexible but makes reasoning about "who can actually access this bucket's contents" genuinely hard — a bucket's IAM policy alone doesn't tell you the full picture if any object has its own more-permissive ACL layered on top. Uniform bucket-level access eliminates object-level ACLs entirely, so IAM is the only access control mechanism, making the bucket's actual permissions fully visible from its IAM policy alone — the trade-off is that any workflow currently relying on object-level ACLs (a specific object made public via its own ACL, independent of the bucket's broader policy) breaks the moment uniform access is enabled, since those ACLs stop being honored.

Detailed Explanation

Fine-grained access is genuinely more flexible, which is exactly the source of the problem: with fine-grained access, a bucket's overall IAM policy might be relatively locked down, while a specific object within it has its own ACL granting broader (even public) access — this flexibility is useful for specific per-object sharing needs, but means you can't determine a bucket's actual full access surface by reading its IAM policy alone; you'd also need to audit every object's individual ACL.

Uniform bucket-level access makes IAM the single, complete source of truth for the bucket's access: once enabled, object-level ACLs are disabled and no longer evaluated at all — every access decision for the bucket and everything in it goes entirely through the bucket's IAM policy, meaning you genuinely can audit and reason about the complete access picture from one place.

This directly parallels AWS S3's push toward Block Public Access and bucket-policy-only access, away from ACLs: both cloud providers converged on the same architectural conclusion — object-level ACLs make auditing genuinely hard, and consolidating to policy/IAM-only access is safer and more auditable, even though it sacrifices some fine-grained flexibility.

Enabling uniform access on an existing bucket immediately stops honoring any existing object-level ACLs: if any object currently relies on its own ACL for the access it grants (a specific object shared publicly or with a specific external party via ACL, independent of the bucket's IAM policy), that access breaks the moment uniform access is enabled — anyone who relied on it loses access immediately, unless the equivalent access is granted via IAM before or immediately after the switch.

Auditing existing object-level ACLs before switching is the necessary due-diligence step: reviewing objects for any ACL granting access beyond what the bucket's own IAM policy already provides (particularly any object made public via its own ACL specifically) identifies exactly what will break, letting you either replicate that access via IAM (if it should be preserved) or confirm it should be broken (if it was actually an unintended, forgotten grant, which is itself a security-relevant finding).

Uniform bucket-level access can be reverted within 90 days of enabling it, but not indefinitely: this gives a limited safety window if the switch turns out to have broken something unexpectedly, but it's not a permanent escape hatch — after 90 days, the switch to uniform access becomes permanent, which matters for how confidently you should test the change before committing to it long-term.

Interview Follow-Up Questions

  • How would you audit an existing bucket's objects to find every ACL granting access beyond what the bucket's IAM policy already provides, before switching?
  • What's the equivalent AWS S3 concept, and how similar is the actual migration consideration?
  • How would you design a new bucket's access model from the start to avoid ever needing this kind of migration?

Key Takeaways

  • Fine-grained access lets individual objects have their own ACLs independent of the bucket's IAM policy, making full access auditing require checking every object, not just the bucket's IAM policy.
  • Uniform bucket-level access makes IAM the sole access control mechanism, disabling all object-level ACLs, so the bucket's IAM policy alone fully describes its access.
  • Enabling uniform access on an existing bucket immediately breaks any access currently granted only via an object-level ACL, not reflected in the bucket's IAM policy.
  • The switch to uniform access is reversible only within 90 days, so testing thoroughly before committing matters given the eventual permanence.

References

Last updated August 22, 2026 · Last reviewed August 22, 2026