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?
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.
Why this answer
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.
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.
How to eliminate wrong answers
Option A is wrong because adding a condition to the `objectViewer` binding does not address the core issue: `allUsers` still has public access. Conditions restrict access based on attributes (e.g., IP address), but they do not remove the fact that unauthenticated users can attempt to read objects. Option C is wrong because removing the entire `objectViewer` binding would also remove legitimate, authenticated users who need read access, which is overly destructive and not the immediate required action.
Option D is wrong because changing the role to `objectAdmin` for `allUsers` would escalate privileges, granting public users write and delete permissions on objects, making the security risk even worse.