A security engineer is evaluating IAM access across an organization's resource hierarchy structured as follows: Folder: Finance-Dept Project: fin-analytics-prod (child of Finance-Dept) Cloud Storage Bucket: fin-audit-logs (located inside fin-analytics-prod) The following IAM allow policies are currently configured: At the Finance-Dept Folder level, the principal auditor@example.com is granted the Storage Admin (roles/storage.admin) role. At the fin-analytics-prod Project level, auditor@example.com is granted the Storage Object Viewer (roles/storage.objectViewer) role. At the fin-audit-logs Bucket level, a local administrator attempts to restrict access by granting auditor@example.com only the Storage Object Creator (roles/storage.objectCreator) role. What is the effective permission state of auditor@example.com on the fin-audit-logs bucket, and why?

The principal retains full administrative control because IAM allow policies are strictly additive and inherit downward from parent resources to child resources.: ### What IAM Policy Inheritance Is **Identity and Access Management (IAM)** in Google Cloud uses a hierarchical container model (Organization → Folders → Projects → Resources). In this hierarchy, child resources automatically inherit the IAM allow policies configured on all of their parent ancestors. The union of all allow policies applied directly to a resource and inherited from its parent hierarchy forms the **effective allow policy**. ### How It Evaluates the Scenario * **Folder level (`Finance-Dept`)**: The user `auditor@example.com` was granted `roles/storage.admin`, which contains full management and object manipulation permissions across all Cloud Storage buckets within that folder. * **Project level (`fin-analytics-prod`)**: Granting `roles/storage.objectViewer` adds read permissions, but does not diminish or revoke the folder-level administrative role. * **Bucket level (`fin-audit-logs`)**: Granting `roles/storage.objectCreator` adds object creation permissions directly on the bucket. * **Resulting effective permission**: Because allow policies are **strictly additive**, permissions cannot be restricted, narrowed, or overridden at a child level by applying a more restrictive allow policy. The user retains full **Storage Admin** capabilities across `fin-audit-logs`. ### Key Advantages and Hierarchy Principles * **Additive model**: Allow policies accumulate down the tree; child allow policies can only grant additional access, never restrict inherited access. * **Container-wide administration**: Managing permissions at the folder or organization level ensures uniform access across hundreds of downstream projects without per-resource configuration. * **Effective access calculation**: IAM evaluates the logical union of all ancestor allow policies during access checks. * **Least-privilege scoping**: Administrative roles must be applied at the smallest necessary scope to avoid unintended over-permissioning on child workloads. ### Why This Is Optimal Recognizing that allow policies propagate additively is critical for designing least-privilege security boundaries. When restrictions are needed, administrators must either move the resource outside the parent folder, remove the high-level role grant, or implement explicit **IAM Deny policies**.

Iam Policy Inheritance Effective Permissions | Professional Cloud Security Engineer

Iam Policy Inheritance Effective Permissions

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 security engineer is evaluating IAM access across an organization's resource hierarchy structured as follows:

Folder: Finance-Dept
Project: fin-analytics-prod (child of Finance-Dept)
Cloud Storage Bucket: fin-audit-logs (located inside fin-analytics-prod)

The following IAM allow policies are currently configured:

At the Finance-Dept Folder level, the principal auditor@example.com is granted the Storage Admin (roles/storage.admin) role.
At the fin-analytics-prod Project level, auditor@example.com is granted the Storage Object Viewer (roles/storage.objectViewer) role.
At the fin-audit-logs Bucket level, a local administrator attempts to restrict access by granting auditor@example.com only the Storage Object Creator (roles/storage.objectCreator) role.

What is the effective permission state of auditor@example.com on the fin-audit-logs bucket, and why?

The principal retains full administrative control because IAM allow policies are strictly additive and inherit downward from parent resources to child resources.

The principal has only the union of Storage Object Viewer and Storage Object Creator permissions because folder-level bindings do not propagate past the project boundary.

The principal's access is blocked due to conflicting role assignments between the folder, project, and bucket levels.

The principal has only Storage Object Creator permissions because resource-level IAM policies override parent project and folder policies.

Professional Cloud Security Engineer

Iam Policy Inheritance Effective Permissions

Related questions