GCP Professional Cloud Security Engineer Practice Question

Your organization must ensure that, except for the central backup service account ([email protected]), no identity can ever delete objects from the legacy archive bucket gs://prod-archive. The bucket already inherits several project-level bindings that grant roles/storage.objectAdmin to numerous teams, and more permissions might be added later. You are not allowed to modify or remove any existing allow bindings on the project or bucket. What is the most future-proof way to meet the requirement with the least ongoing maintenance effort?

Attach a project-level IAM Deny policy that lists storage.objects.delete in deniedPermissions, targets principal://* (all principals), and lists serviceAccount:[email protected] in exceptionPrincipals.
Add an IAM Condition to every current and future roles/storage.objectAdmin binding that allows deletes only when request.auth.principal equals the backup service account.
Remove the existing roles/storage.objectAdmin bindings, replace them with custom roles that exclude storage.objects.delete, and grant roles/storage.objectAdmin on the bucket only to the backup service account.
Create an organization-level IAM Deny policy that blocks storage.objects.delete for everyone, then add a bucket-level allow binding giving roles/storage.objectAdmin to the backup service account so it overrides the deny.

Report Issue

Answer Description

In Google Cloud IAM, deny policies are evaluated before any allow bindings at the same or lower level, and an allow binding can never override a deny. Although Cloud Storage buckets do not support attached deny policies, you can attach a deny policy to the project that owns the bucket. By creating a project-level deny rule that blocks storage.objects.delete for all principals while adding serviceAccount:[email protected] to exceptionPrincipals, you guarantee that deletes are prevented for everyone except the backup service account. Because the deny applies before any current or future allow bindings inherited by the bucket, no additional maintenance is required when new roles are granted. Approaches that rely on editing every allow binding or custom role are error-prone and require continual updates, and an allow binding cannot override a deny, so granting an Allow only to the backup account after a global deny would not work unless that account is exempted in the deny policy itself.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.