Google ACE Practice Question: Refer to the exhibit

Exhibit

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:admin@example.com",
        "serviceAccount:sa@project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "allUsers"
      ]
    }
  ]
}

Refer to the exhibit. A team has this IAM policy on a Cloud Storage bucket. The bucket contains sensitive data. Which action should the team take immediately?

⚠ Common exam trap

Google Cloud often tests the misconception that adding conditions or changing roles can mitigate a public access exposure, when the correct immediate action is to remove the `allUsers` or `allAuthenticatedUsers` principal entirely.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Remove allUsers from the objectViewer binding.

The IAM policy grants `allUsers` (anyone on the internet) the `objectViewer` role on the bucket, which allows unauthenticated read access to all objects. Since the bucket contains sensitive data, this is a critical security exposure that must be removed immediately by deleting the `allUsers` principal from the binding.

Answer analysis

Option-by-option breakdown

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

✗
Add a condition to the objectViewer binding to restrict access.
Why it's wrong here
Adding a condition to the objectViewer binding limits when the allUsers principal can read, but it does not remove the public principal from the policy. Any user who meets the condition (e.g., a source IP range) still gains anonymous access, so the resource remains publicly reachable. Furthermore, conditions cannot retroactively apply to objects already public, and they add complexity without addressing the core issue: the presence of allUsers is what creates public exposure.
✓
Remove allUsers from the objectViewer binding.
Why this is correct
Removing allUsers from the objectViewer binding is the precise and correct fix because it eliminates the special principal that grants anonymous public read access while leaving the binding intact for any other IAM members. After this change, only authenticated users or principals explicitly added to the bucket policy can access the objects. This directly aligns with the principle of least privilege and avoids affecting other legitimate permissions in the same binding.
✗
Remove the entire objectViewer binding.
Why it's wrong here
Removing the entire objectViewer binding revokes the objectViewer role for every member, including service accounts or users that may legitimately need read access. If the binding included non-public principals, they would lose access unexpectedly, causing broken applications. The security issue is solely the allUsers principal, so a surgical removal of that principal is safer and less disruptive than deleting the entire binding.
✗
Change the objectViewer role to objectAdmin for allUsers.
Why it's wrong here
Changing the role to objectAdmin for allUsers replaces read-only access with full control, including object creation, deletion, and metadata modification. This enables the public to modify datasets, potentially corrupting data or incurring storage costs. It also still leaves the bucket publicly accessible, so it exacerbates the original security problem instead of solving it.

Go deeper

Google ACE Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question