An enterprise organizes its Google Cloud resources under an Engineering parent folder, which contains two subfolders: Development and Production. A security auditor discovers that the group dev-team@example.com is currently bound to the Compute Instance Admin role (roles/compute.instanceAdmin) directly on the Engineering folder. The security team must enforce the following access requirements: Developers must retain full administrative control over Compute Engine instances within projects located in the Development folder. Developers must be restricted to read-only access (roles/compute.viewer) for Compute Engine instances within projects located in the Production folder. Which architectural change should the security team implement to satisfy these access requirements?

Remove the role binding on the parent Engineering folder, grant roles/compute.instanceAdmin on the Development folder, and grant roles/compute.viewer on the Production folder.: ### What scoped folder-level role assignment is Scoped role assignment involves applying IAM allow policies at the most granular, appropriate container level within the resource hierarchy rather than at an overly broad parent node. ### How it meets the requirements - **Enforcing administrative access in Development:** Granting `roles/compute.instanceAdmin` directly on the `Development` folder ensures that all child projects and Compute Engine instances beneath it inherit instance administration permissions. - **Enforcing read-only access in Production:** Granting `roles/compute.viewer` directly on the `Production` folder provides developer access to view infrastructure without inheriting administrative permissions from a parent folder. - **Eliminating excessive inheritance:** Removing the broad administrative role binding from the common ancestor (`Engineering` folder) prevents unwanted permissions from propagating down into production workloads. ### Key advantages and capabilities - **Aligns with least privilege:** Enforces the principle of least privilege by granting permissions strictly at the boundary where they are needed. - **Leverages natural inheritance:** Takes advantage of hierarchical inheritance so that new projects created inside either folder automatically receive the proper baseline permissions. - **Simplifies policy governance:** Avoids complex exception handling or object-level permission overrides across dozens of individual production instances and projects. - **Ensures consistent environment separation:** Maintains clear separation of duties between non-production and production environments. ### Why this is optimal In Google Cloud IAM, allow policies are strictly **additive** and inherited downwards through the resource hierarchy. A child resource's effective policy is the union of all allow policies attached to the resource and its ancestors. Because an allow policy at a child level cannot revoke, restrict, or override an inherited allow permission from a higher level, removing the high-privilege grant from the parent node and scoping distinct roles at the child folder level is the standard and correct approach.