A DevOps team is managing access across a multi-tier Google Cloud resource hierarchy. A developer reports that they are unable to delete objects from a specific Cloud Storage bucket in a production project, despite having the Storage Object Admin (roles/storage.objectAdmin) role directly granted to their identity on that bucket. During your investigation of the resource hierarchy, you identify the following IAM configurations: Organization level: An IAM deny policy denies storage.objects.delete to all members of the developer group. Folder level: An IAM allow policy grants the developer group the Storage Object Viewer (roles/storage.objectViewer) role. Project level: No direct allow or deny bindings are configured for the developer. Bucket level: An IAM allow policy directly grants the developer the Storage Object Admin (roles/storage.objectAdmin) role. How does Google Cloud IAM evaluate these cumulative policies to determine the developer's effective permissions on the bucket?

The organization-level deny policy overrides all inherited and directly applied allow policies, preventing the developer from deleting objects despite the bucket-level grant.: ### What Policy Precedence and Deny Policies Are In Google Cloud Identity and Access Management (IAM), access evaluation follows a strict hierarchical evaluation order where **IAM deny policies** always take precedence over **IAM allow policies**, regardless of where the policies are attached in the resource hierarchy. ### How IAM Evaluates the Effective Access When the developer attempts to execute an action that requires `storage.objects.delete` on the Cloud Storage bucket, IAM resolves the request using the following evaluation sequence: 1. **Deny Policy Evaluation**: IAM first evaluates all applicable deny policies attached to the resource and all its ancestors (organization, folder, project, and resource). Because a deny policy at the **organization level** explicitly denies `storage.objects.delete` to the principal's group, the denial is absolute. 2. **Short-Circuit Denial**: If any applicable deny rule matches the principal, permission, and conditions, IAM immediately rejects the request without allowing lower-level allow policies to override it. 3. **Allow Policy Evaluation**: Even though the bucket-level allow policy grants the **Storage Object Admin** (`roles/storage.objectAdmin`) role—which contains the `storage.objects.delete` permission—this grant cannot supersede the ancestor deny rule. ### Key Rules of IAM Evaluation and Inheritance - **Deny overrides allow**: Deny policies create absolute guardrails that override any allow policy grants across the entire hierarchy. - **Allow policies are additive**: Allow policies at the organization, folder, project, and resource levels combine into a union of permissions, but they can never negate or bypass a deny policy. - **Inherited scope**: Policies attached at higher levels of the resource hierarchy (such as organizations and folders) automatically apply to all descendant containers and individual resources. ### Why This Is Optimal This evaluation model ensures that central governance and compliance guardrails set by organization security administrators cannot be inadvertently bypassed or overridden by project owners or resource-level administrators. Tools like **Policy Troubleshooter** and `gcloud beta projects get-ancestors-iam-policy --include-deny` can be used to quickly inspect these interacting layers.

Iam Effective Policy Inheritance Troubleshooting | Professional Cloud DevOps Engineer

Iam Effective Policy Inheritance Troubleshooting

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A DevOps team is managing access across a multi-tier Google Cloud resource hierarchy. A developer reports that they are unable to delete objects from a specific Cloud Storage bucket in a production project, despite having the Storage Object Admin (roles/storage.objectAdmin) role directly granted to their identity on that bucket.

During your investigation of the resource hierarchy, you identify the following IAM configurations:

Organization level: An IAM deny policy denies storage.objects.delete to all members of the developer group.
Folder level: An IAM allow policy grants the developer group the Storage Object Viewer (roles/storage.objectViewer) role.
Project level: No direct allow or deny bindings are configured for the developer.
Bucket level: An IAM allow policy directly grants the developer the Storage Object Admin (roles/storage.objectAdmin) role.

How does Google Cloud IAM evaluate these cumulative policies to determine the developer's effective permissions on the bucket?

The organization-level deny policy overrides all inherited and directly applied allow policies, preventing the developer from deleting objects despite the bucket-level grant.

The direct allow policy on the Cloud Storage bucket overrides inherited ancestor policies because resource-level bindings take precedence over organization-level rules.

The absence of a direct IAM binding at the project level creates an implicit boundary that prevents bucket-level role bindings from taking effect.

The folder-level Storage Object Viewer role restricts access down the hierarchy, narrowing all descendant project and bucket permissions to read-only.

Professional Cloud DevOps Engineer

Iam Effective Policy Inheritance Troubleshooting

Related questions