Google ACE Practice Question: A team's Cloud Storage bucket has fine-grained…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Enable Uniform Bucket-Level Access (UBLA) on the bucket

  Why this is correct

  Enabling Uniform Bucket-Level Access (UBLA) on the bucket disables object-level ACLs and makes all access decisions rely exclusively on bucket-level IAM policies. Existing object ACLs are no longer evaluated, and newly uploaded objects do not get individual ACLs; instead, every object inherits the bucket's IAM permissions. This eliminates the dual permission model and lets you manage access centrally via IAM roles, such as roles/storage.objectViewer, giving you a single, consistent authorization mechanism for all objects in the bucket.

• ✗

  Delete all ACLs on each object and set them to 'authenticated-read'

  Why it's wrong here

  Deleting object ACLs and setting them to `authenticated-read` is contradictory because `authenticated-read` is itself a predefined ACL that grants READER access to every authenticated Google user — a potentially larger audience than intended. Removing an existing ACL and applying this predefined ACL still leaves an ACL on the object, so ACL evaluation continues to happen; the bucket has not switched to IAM-only governance. Only Uniform Bucket-Level Access fully abandons object ACLs and enforces IAM policies at the bucket level.

• ✗

  Enable VPC Service Controls on the bucket

  Why it's wrong here

  VPC Service Controls operate at the network and API perimeter layer, using context-aware conditions to block exfiltration of Google Cloud services data; they do not modify the authorization model of Cloud Storage. A bucket inside a service perimeter still evaluates object ACLs exactly as before, and IAM-only access is not enforced — VPC SC simply adds an extra admission-control gate before a request reaches the bucket. Therefore, while VPC SC can reduce data exfiltration risk, it cannot replace or disable the object ACL mechanism.

• ✗

  Set the bucket's default object ACL to `projectPrivate` and apply it to all objects

  Why it's wrong here

  Setting the default object ACL to `projectPrivate` does not disable per-object ACLs — it simply changes which predefined ACL is automatically applied to new objects, granting the requesting project's owners/editors/viewers broad OWNER permissions. Even if you retroactively apply that default to all existing objects, every object still has an ACL that must be evaluated alongside IAM, so the permission model remains mixed and per-object ACLs are still in force. Uniform Bucket-Level Access is the only setting that makes IAM the sole authorization mechanism for the bucket and all objects.

Go deeper

Related to this question