An enterprise organization is structuring access for its engineering teams across distinct application environments organized into Development, Testing, and Production folders in Google Cloud. The organization has the following access and operational requirements: Multiple product squads (such as Squad Alpha and Squad Beta) require granular administrative permissions on their squad-specific resources within the Development folder. All developers across all squads must automatically inherit broad read-only and monitoring permissions across all non-production environment folders. Elevated write access to the Production folder must be restricted strictly to squad leads. User onboarding and offboarding must be managed with minimal administrative overhead, avoiding direct IAM policy updates on Google Cloud resource nodes while preserving clear audit trails. Which Cloud Identity group hierarchy and IAM binding design should the security engineer implement?

Create functional role groups bound to IAM roles at the environment folder levels, nest squad-specific member groups into broad organizational role groups, and assign individual engineers exclusively to the squad-specific leaf groups.: ### What Nested Group Hierarchy in Cloud Identity Is A **nested group hierarchy** in Cloud Identity (or Google Workspace) is an identity architecture where specialized sub-groups (child/leaf groups) are added as members of higher-level parent groups. In Google Cloud IAM, permissions bound to a parent group are transitively inherited by all members of any nested child groups. This design separates **identity lifecycle management** (membership updates in Cloud Identity) from **access policy management** (IAM role bindings attached to folders and projects). ### How It Meets the Requirements - **Granular squad-level access**: Squad-specific leaf groups (such as `squad-alpha-devs@example.com` and `squad-beta-devs@example.com`) are directly assigned administrative IAM roles on their respective squad projects within the `Development` folder. - **Broad non-production access**: A parent group (such as `all-engineers@example.com`) is granted read-only roles (e.g., `roles/viewer`, `roles/logging.viewer`) at the `Development` and `Testing` folder levels. Nesting `squad-alpha-devs@` and `squad-beta-devs@` into `all-engineers@` ensures every engineer automatically inherits non-production read access without duplicate role assignments. - **Restricted production access**: A dedicated `squad-leads@example.com` group is created and bound to elevated roles at the `Production` folder level. Squad engineers are not added to this group, preventing unintended privilege escalation. - **Operational efficiency and auditability**: Adding or removing a user from their specific squad leaf group automatically grants or revokes both squad-level administrative access and inherited organization-wide read access. IAM policies on Google Cloud folders and projects remain static, minimizing configuration drift and policy churn while Cloud Audit Logs clearly trace user identities via group expansion. ### Key Advantages - **Principle of least privilege**: Enables precise role assignments at leaf levels while leveraging inheritance for baseline permissions. - **Administrative decoupling**: Directory administrators handle group memberships in Cloud Identity without requiring IAM Admin privileges in Google Cloud. - **Reduced policy bloat**: Prevents exceeding IAM policy size limits by binding roles to centralized groups rather than individual user accounts. - **Simplified offboarding**: Removing a departing employee from their leaf squad group instantly revokes all inherited and direct cloud access across all environments. ### Why This Is Optimal This approach aligns with Google Cloud enterprise landing zone best practices by combining hierarchical resource governance (environment folders) with role-based identity abstractions (nested groups). It eliminates manual user-level IAM bindings and minimizes administrative overhead across multi-environment deployments.

Design Nested Group Hierarchy Iam | Professional Cloud Security Engineer

Design Nested Group Hierarchy 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.

An enterprise organization is structuring access for its engineering teams across distinct application environments organized into Development, Testing, and Production folders in Google Cloud. The organization has the following access and operational requirements:

Multiple product squads (such as Squad Alpha and Squad Beta) require granular administrative permissions on their squad-specific resources within the Development folder.
All developers across all squads must automatically inherit broad read-only and monitoring permissions across all non-production environment folders.
Elevated write access to the Production folder must be restricted strictly to squad leads.
User onboarding and offboarding must be managed with minimal administrative overhead, avoiding direct IAM policy updates on Google Cloud resource nodes while preserving clear audit trails.

Which Cloud Identity group hierarchy and IAM binding design should the security engineer implement?

Bind IAM roles directly to individual user accounts on the relevant folders and use Cloud Audit Logs to track identity permissions across environments.

Create functional role groups bound to IAM roles at the environment folder levels, nest squad-specific member groups into broad organizational role groups, and assign individual engineers exclusively to the squad-specific leaf groups.

Create flat, environment-specific groups for each environment tier, assign direct IAM role bindings at each project level, and add individual user accounts directly to each environment group.

Create a single top-level group for all engineering staff, bind that group to the Project Editor role at the organization root, and use IAM Deny policies to block non-lead access in Production.

Professional Cloud Security Engineer

Design Nested Group Hierarchy Iam

Related questions