An enterprise organization manages a Google Cloud resource hierarchy consisting of an Organization node, several environment folders (Production, Staging, Development), and dozens of child projects. The security team wants to implement tag-based access control (TBAC) with IAM Conditions to grant the Cloud Operations team (cloud-ops@example.com) administrative permissions across virtual machines under the following requirements: The Cloud Operations team must be granted roles/compute.admin dynamically only on resources evaluated with the environment: production tag value. A safe default configuration must be applied so that all newly created and existing resources across the organization inherit a non-production tag state unless explicitly set. Projects under the Production folder must automatically inherit production tag enforcement without requiring per-project configuration, while allowing descendant resources to override the tag value when necessary. The IAM condition must minimize security risks associated with potential deletion and recreation of tag keys or values with identical names. Which strategy should the security engineer implement?

Bind the tag value `environment: default` to the Organization resource, attach the tag value `environment: production` to the `Production` folder, and grant `roles/compute.admin` to `cloud-ops@example.com` at the organization level using an IAM condition with `resource.matchTagId()` referencing the permanent tag key and value IDs.: ### What the solution is This architecture combines **Resource Manager tag inheritance**, **safe default tag bindings**, and **IAM Conditions** using **permanent resource IDs** (`tagKeys/KEY_ID` and `tagValues/VALUE_ID`) to dynamically enforce least-privilege administrative access across the Google Cloud resource hierarchy. ### How it meets the requirements - **Safe default baseline:** Binding `environment: default` at the root **Organization resource** ensures that all descendant folders, projects, and resources automatically inherit a baseline non-production tag state through hierarchy inheritance. - **Hierarchical inheritance & overrides:** Attaching `environment: production` directly to the `Production` folder overrides the organization-level safe default for that entire subtree. All child projects and compute instances under the `Production` folder automatically compute an **effective tag** of `environment: production` without manual project-level tagging, while retaining the capability to be overridden at lower levels if needed. - **Dynamic conditional access:** Granting `roles/compute.admin` at the organization level with a condition using `resource.matchTagId()` ensures that members of `cloud-ops@example.com` only obtain administrative rights when acting against resources whose effective tags match the production tag identifier. - **Protection against tag recreation risks:** Referencing **permanent tag IDs** (`tagKeys/123456789012` and `tagValues/567890123456`) ensures that if a tag key or value is deleted and subsequently recreated with identical short names or namespaced names, unauthorized access is not unintentionally restored or granted to the new tag resources. ### Key advantages and capabilities - **Centralized governance:** Eliminates administrative sprawl by evaluating permissions dynamically across all projects without requiring localized IAM role bindings. - **Deterministic evaluation:** Leverages Google Cloud Resource Manager's native tag inheritance logic where child bindings supersede parent bindings on the same key. - **Immutable identifier security:** Prevents configuration drift and privilege escalation attacks caused by namespace recycling. - **Effective tag calculation:** Inherited tags automatically apply to all supported descendant resources across the resource hierarchy tree. ### Why this is optimal This approach aligns with Google Cloud security best practices by implementing safe defaults at the root node, delegating environment-specific governance to folder structures, and utilizing immutable permanent identifiers in IAM CEL expressions to eliminate privilege escalation vectors.

Tag Based Iam Conditions Inheritance Hierarchy | Professional Cloud Security Engineer

Tag Based Iam Conditions Inheritance Hierarchy

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 manages a Google Cloud resource hierarchy consisting of an Organization node, several environment folders (Production, Staging, Development), and dozens of child projects. The security team wants to implement tag-based access control (TBAC) with IAM Conditions to grant the Cloud Operations team (cloud-ops@example.com) administrative permissions across virtual machines under the following requirements:

The Cloud Operations team must be granted roles/compute.admin dynamically only on resources evaluated with the environment: production tag value.
A safe default configuration must be applied so that all newly created and existing resources across the organization inherit a non-production tag state unless explicitly set.
Projects under the Production folder must automatically inherit production tag enforcement without requiring per-project configuration, while allowing descendant resources to override the tag value when necessary.
The IAM condition must minimize security risks associated with potential deletion and recreation of tag keys or values with identical names.

Which strategy should the security engineer implement?

Professional Cloud Security Engineer

Tag Based Iam Conditions Inheritance Hierarchy

Related questions