A cloud administrator attempts to restrict a DevOps engineer's permissions within a specific Google Cloud project residing inside a folder named 'Production'. The DevOps engineer was previously assigned the Compute Admin (`roles/compute.admin`) role at the 'Production' folder level. The administrator removes the engineer's Compute Admin role assignment from the child project's IAM policy page. However, the engineer can still create and delete Compute Engine instances inside that project. What is the cause of this behavior?
- IAM permissions granted at a parent level in the resource hierarchy are inherited by child resources and cannot be revoked at the child resource level.Answer
- BProject-level IAM policy modifications require up to 24 hours to take effect due to global caching across child folders.
- CThe Compute Admin role is a primitive role that automatically overrides resource hierarchy boundaries across all folders.
- DThe project's linked billing account grants implicit Compute Admin access to any user with Folder Viewer permissions.
Answer
IAM permissions granted at a parent resource level in Google Cloud are inherited down the resource hierarchy and cannot be restricted or revoked at a lower child level.
In Google Cloud, IAM policies are inherited downward through the resource hierarchy (Organization → Folder → Project → Resource) and are strictly additive. If a user is granted a role at a higher level (such as a Folder), that permission applies to all child resources within that folder. Removing a role binding on a child project does not remove or override the binding inherited from the parent folder.
Step-by-Step Solution
Key Concept
Resource Hierarchy IAM Policy Inheritance