An enterprise is designing its Google Cloud resource hierarchy to support multiple development teams while meeting strict security, compliance, and operational governance requirements: Centralized Network & Security Control: Dedicated central network and security teams must manage Shared VPC host infrastructure, hierarchical firewall policies, and organizational guardrails across all workloads. Environment Isolation & Access Control: Developers need administrative permissions within Development environments to rapidly iterate, but must have strictly restricted, read-only permissions in Production where changes are deployed exclusively through CI/CD service accounts. Policy Enforcement: Strict organizational policy constraints (such as disabling external IP addresses) must apply to all production workloads across all applications, while remaining permissive in development. Safe Governance Validation: The DevOps team must be able to validate changes to organization policies, access policies, and resource hierarchy restructuring before applying them to the live organization. Which resource hierarchy and access architecture should the team implement?

Use a single production organization structured with top-level environment folders (such as Production, Non-Production, and Common/Hub), place application-specific folders and projects as descendants, apply IAM bindings and organization policies at the folder level, and establish a separate staging organization to test hierarchy and policy changes.: ### What the Recommended Hierarchy Architecture Is This architecture establishes a **single production Google Cloud organization** structured hierarchically with top-level environment folders (`Production`, `Non-Production`, and `Common`/`Hub`), nesting application-specific projects underneath. In addition, it provisions an isolated, dedicated **staging organization** tied to a staging identity directory specifically to validate organization-wide policy updates and administrative changes. ### How it Meets the Enterprise Requirements - **Centralized Network & Security Control:** Network and security administrators are granted organization-level or hub-level IAM roles (such as `roles/compute.xpnAdmin`, `roles/compute.networkAdmin`, and `roles/compute.orgSecurityPolicyAdmin`). This allows central teams to administer Shared VPC host projects and hierarchical firewall policies while delegating subnet usage to developers via `roles/compute.networkUser`. - **Environment Isolation & Access Control:** By grouping projects into `Production` and `Non-Production` folders, allow policies are inherited down the hierarchy. Developers are granted `roles/compute.instanceAdmin` or team lead roles on the `Non-Production` folder, while the `Production` folder restricts developer access to viewer roles and grants deployment roles exclusively to CI/CD service accounts. - **Policy Enforcement:** Organizational policies (such as `constraints/compute.vmExternalIpAccess`) are defined at the `Production` folder level. This ensures all current and future production projects inherit the restriction automatically without affecting developer flexibility in `Non-Production`. - **Safe Governance Validation:** Utilizing a dedicated **staging organization** that mirrors the folder hierarchy allows infrastructure engineers to test disruptive IAM updates, hierarchy moves, and organization policies without impacting developer productivity or production uptime. ### Key Advantages and Capabilities - **Policy Inheritance:** Eliminates repetitive project-level configuration by enforcing security baselines at parent folder nodes. - **Shared VPC Alignment:** Allows Shared VPC host projects in a central folder to securely share subnets with service projects across different environment folders within the same organization. - **Blast Radius Containment:** Isolates administrative experiments to the staging organization while maintaining parity across development, test, and production workloads. - **Least Privilege Administration:** Separates networking and security administration from application workloads using distinct Google Groups. ### Why This Is Optimal This architecture strikes the ideal balance between administrative consistency, security governance, and operational agility. It prevents configuration drift between test and production while protecting production systems from unvalidated policy rollouts.

Design Resource Hierarchy Separation Of Duties | Professional Cloud DevOps Engineer

Design Resource Hierarchy Separation Of Duties

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 is designing its Google Cloud resource hierarchy to support multiple development teams while meeting strict security, compliance, and operational governance requirements:

Centralized Network & Security Control: Dedicated central network and security teams must manage Shared VPC host infrastructure, hierarchical firewall policies, and organizational guardrails across all workloads.
Environment Isolation & Access Control: Developers need administrative permissions within Development environments to rapidly iterate, but must have strictly restricted, read-only permissions in Production where changes are deployed exclusively through CI/CD service accounts.
Policy Enforcement: Strict organizational policy constraints (such as disabling external IP addresses) must apply to all production workloads across all applications, while remaining permissive in development.
Safe Governance Validation: The DevOps team must be able to validate changes to organization policies, access policies, and resource hierarchy restructuring before applying them to the live organization.

Which resource hierarchy and access architecture should the team implement?

Professional Cloud DevOps Engineer

Design Resource Hierarchy Separation Of Duties

Related questions