A financial enterprise uses a multi-tier Google Cloud resource hierarchy structured as follows: Organization: example.com Folder: Engineering Folder: Backend-Services Project: payment-prod Resource: Cloud Storage Bucket payment-logs A security administrator reviews the following IAM allow policy bindings for the user auditor@example.com across this lineage: roles/viewer granted on the Engineering folder roles/storage.objectViewer granted on the Backend-Services folder roles/storage.admin granted on the payment-prod project To prevent auditor@example.com from modifying objects in the payment-logs bucket, the administrator removes all bucket-level role bindings so that no direct allow policy is set on payment-logs. What is the effective permission level of auditor@example.com on the payment-logs bucket, and why?

The user retains full administrative control over the bucket because IAM allow policies are additive and inherited down the resource hierarchy, meaning project-level grants cannot be revoked by omitting bucket-level bindings.: ### What IAM Policy Inheritance Is In Google Cloud, the **resource hierarchy** organizes resources into a parent-child structure consisting of the organization, folders, projects, and individual service resources. **IAM allow policies** are attached to these container nodes and are inherited down the tree. The union of all allow policies applied directly to a resource and its ancestors forms the **effective allow policy**. ### How Policy Inheritance Determines Effective Permissions - **Additive Evaluation**: IAM allow policies are strictly additive. If a principal is granted a role at any ancestor level (such as the `payment-prod` project), that role automatically propagates to all descendant resources within that container. - **Inherited Project Rights**: Because `roles/storage.admin` is granted at the `payment-prod` project level, the user inherits complete control (`storage.buckets.*` and `storage.objects.*`) over every bucket in that project, including `payment-logs`. - **Absence of Child Policy**: Omitting or deleting direct role bindings on the child bucket does not revoke or restrict permissions inherited from parent folders or projects. ### Key Characteristics of IAM Allow Policy Inheritance - **Ancestral Precedence**: A permission granted at a higher hierarchy level cannot be reduced or overridden simply by omitting permissions at a lower hierarchy level. - **Union of Grants**: The effective permissions for any API operation equal the logical **union** of permissions granted across all parent folders, projects, and the organization. - **Container-Level Propagation**: Assigning a role to a container automatically extends those capabilities to non-configurable child resources or resources without explicit child policies. ### Why This Is Optimal Understanding that allow policies are strictly cumulative ensures cloud architects recognize that restricting access requires modifying the specific ancestor node where the role was granted, implementing **IAM Deny policies**, or using separate trust boundaries (projects/folders) to achieve least privilege.

StudyCerts

Iam Policy Inheritance Effective Permissions Hierarchy | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Iam Policy Inheritance Effective Permissions Hierarchy

Section: Identity and Access Management (IAM)

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 financial enterprise uses a multi-tier Google Cloud resource hierarchy structured as follows:

Organization: example.com
- Folder: Engineering
  - Folder: Backend-Services
    - Project: payment-prod
      - Resource: Cloud Storage Bucket payment-logs

A security administrator reviews the following IAM allow policy bindings for the user auditor@example.com across this lineage:

roles/viewer granted on the Engineering folder
roles/storage.objectViewer granted on the Backend-Services folder
roles/storage.admin granted on the payment-prod project

To prevent auditor@example.com from modifying objects in the payment-logs bucket, the administrator removes all bucket-level role bindings so that no direct allow policy is set on payment-logs.

What is the effective permission level of auditor@example.com on the payment-logs bucket, and why?

The user is denied all access to the bucket because Cloud Storage requires an explicit bucket-level allow policy for any data or administrative operations.

The user only has read-only access to objects because the roles/storage.objectViewer role granted on the Backend-Services folder overrides lower project-level policies.

The user is restricted to roles/viewer access because the highest parent container in the hierarchy sets the maximum permissible access ceiling.

The user retains full administrative control over the bucket because IAM allow policies are additive and inherited down the resource hierarchy, meaning project-level grants cannot be revoked by omitting bucket-level bindings.

Professional Cloud Architect

Iam Policy Inheritance Effective Permissions Hierarchy

Related questions