Google PCA Design and plan a cloud solution architecture Practice Question

Exhibit

```json
{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "allUsers"
      ]
    }
  ]
}
```

Refer to the exhibit. A Cloud Storage bucket has this IAM policy. What security recommendation should be made?

⚠ Common exam trap

Google Cloud often tests the misconception that `allAuthenticatedUsers` is a secure alternative to `allUsers`, but the trap is that it still allows any authenticated identity (including attackers) to access the data, whereas signed URLs provide granular, revocable, and auditable access.

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 the `allUsers` member and use signed URLs for public access.

The IAM policy grants `roles/storage.objectViewer` to `allUsers`, which makes the bucket's objects publicly readable by anyone on the internet. This is a security risk because it allows anonymous access without authentication or logging. The recommended practice is to remove the `allUsers` member and instead use signed URLs (which embed a time-limited access token) to grant temporary, controlled access to specific objects.

Answer analysis

Option-by-option breakdown

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

✓
Remove the `allUsers` member and use signed URLs for public access.
Why this is correct
Removing `allUsers` eliminates anonymous, unauthenticated access to every object, satisfying the least-privilege constraint. Signed URLs instead grant time-limited, cryptographically authenticated access to specific objects, so public distribution still works without exposing the entire bucket's contents to enumeration or unintended reads.
✗
Change `allUsers` to `allAuthenticatedUsers` to allow only authenticated users.
Why it's wrong here
allAuthenticatedUsers still grants read access to anyone with a Google account, so the bucket remains publicly readable; it merely excludes anonymous callers. The binding must instead be scoped to specific principals, such as named service accounts or a Google Group, to close the exposure.
✗
Enable uniform bucket-level access and update the IAM policy.
Why it's wrong here
Uniform bucket-level access disables object ACLs, so it cannot fix a policy granting public access through bucket IAM bindings; the recommendation should instead remove or restrict the public principal. It is tempting as an access-control hardening step, and would be correct when consolidating ACL-based permissions into IAM.
✗
Remove the `roles/storage.objectViewer` role binding entirely.
Why it's wrong here
Removing the binding strips legitimate read access from every principal, including the service accounts and users who need it, rather than narrowing the allUsers grant that exposes the bucket publicly. The recommendation is to delete only the allUsers member, not the role binding itself.

Go deeper

Google PCA Design and plan a cloud solution architecture Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question