Examkin

Question

Difficulty: HardManaging Cloud Projects and Resource Hierarchy

An organization manages its Google Cloud resources using the hierarchy: Organization -> Finance Folder -> Analytics Project. A compliance auditor requires read-only access strictly to resources inside the Analytics Project. However, a junior administrator previously granted the user the Viewer role (roles/viewer) at the Finance Folder level. When you try to restrict access by removing the Viewer role binding specifically on the Analytics Project, the user can still view all resources in the project. Which fundamental rule of the Google Cloud resource hierarchy explains this behavior, and what is the proper action to enforce the principle of least privilege?

  1. IAM policy evaluation is additive down the resource hierarchy and permissions granted at a parent node cannot be revoked at a child node; you must remove the role at the folder level and grant a predefined role on the project.Answer
  2. B
    Child resource nodes automatically override parent policies when child bindings are modified; you must execute a gcloud command using the --force-override flag at the project level to break policy inheritance.
  3. C
    Primitive roles like Viewer always supersede folder restrictions; assigning a specialized predefined role at the project level will automatically revoke the inherited primitive role.
  4. D
    Folder permissions are permanently tied to the billing account associated with the folder; you must unlink the project from the billing account before child IAM policies can take effect.

Answer

IAM policy evaluation is additive down the resource hierarchy, meaning permissions granted at a parent node (Folder) are inherited by child nodes (Project) and cannot be revoked at the child level. To restrict access to a single project, the role must be revoked at the folder level and granted directly on the target project.
In Google Cloud IAM, policy inheritance is effective and additive down the resource hierarchy. Any role granted at a parent node (such as a Folder) is inherited by all child resources (such as Projects). Child nodes cannot revoke or subtract permissions granted higher up. Therefore, to ensure the compliance auditor only has access to the single project, the broad role must be removed at the folder level and assigned directly at the project level.

Step-by-Step Solution

1
Analyze how IAM permissions flow in the GCP resource hierarchy.
Identify that policies are inherited additively from Organization -> Folder -> Project -> Resource.
Permissions granted at higher levels automatically apply to all child resources contained within that parent scope.
2
Determine why removing the role at the project level failed to restrict access.
Realize that child policy bindings can only add permissions, never subtract or negate inherited permissions from parent nodes.
Inheritance cannot be blocked or revoked at lower levels in standard IAM policy binding.
3
Formulate the correct administrative remediation to achieve least privilege.
Revoke the broad Viewer role at the Finance Folder level, then grant the necessary predefined role specifically on the Analytics Project.
Scoping IAM roles to the precise target resource prevents unintended access across sibling projects in the folder.

Key Concept

Resource Hierarchy IAM Policy Inheritance and Least Privilege
Estimated Time:2m 0s
Rate this question

Topics

Managing Cloud Projects and Resource Hierarchy

More questions from this topic