An enterprise security team is establishing authorization guardrails across Google Cloud resource hierarchies. The team needs to enforce the following access requirements on a folder named Production-Workloads: Prevent all developers in the Google Group developers@example.com from creating and deleting service account keys across all current and future projects in the folder, even if they hold broad project-level Owner or Editor IAM roles. Permit a specialized operational response team in breakglass-ops@example.com (whose members are also in developers@example.com) to retain full permissions to create and delete service account keys within these projects. Apply the restriction centrally with automated inheritance, ensuring deny rules override allow grants without requiring individual policy modifications on each underlying project. Which configuration should the security team implement to satisfy these requirements?

Create an IAM deny policy attached to the Production-Workloads folder with a deny rule that sets deniedPermissions to iam.googleapis.com/serviceAccountKeys.create and iam.googleapis.com/serviceAccountKeys.delete, deniedPrincipals to principalSet://goog/group/developers@example.com, and exceptionPrincipals to principalSet://goog/group/breakglass-ops@example.com.: ### What IAM Deny Policies with Principal Exceptions Are **IAM deny policies** allow administrators to define explicit, non-negotiable security boundaries that prevent specific principals from exercising designated permissions, regardless of the allow policies or IAM roles granted to them. ### How It Meets the Requirements - **Folder-level attachment and inheritance**: Attaching the deny policy to the `Production-Workloads` folder (`cloudresourcemanager.googleapis.com/folders/FOLDER_ID`) ensures the deny rules are automatically **inherited** by all current and future child projects in the folder hierarchy. - **Denied permissions**: Explicitly listing `iam.googleapis.com/serviceAccountKeys.create` and `iam.googleapis.com/serviceAccountKeys.delete` in `deniedPermissions` restricts the precise API operations associated with service account key generation and destruction. - **Principal targets and exceptions**: Specifying `principalSet://goog/group/developers@example.com` under `deniedPrincipals` targets the developer population, while specifying `principalSet://goog/group/breakglass-ops@example.com` under `exceptionPrincipals` exempts emergency response operators. During IAM policy evaluation, deny policies are evaluated **before allow policies**, and principals listed in `exceptionPrincipals` are completely exempt from the deny rule, allowing their existing allow grants to function normally. ### Key Advantages and Capabilities - **Precedence over allow grants**: Deny policies override any broad project-level or folder-level allow grants (such as `roles/owner` or `roles/editor`). - **Hierarchical governance**: Enforces centralized guardrails at the folder boundary, preventing administrative drift or accidental privilege escalation in child projects. - **Granular exceptions**: Supports exempting specific sub-groups or users directly within the deny rule without dismantling parent group memberships. - **Declarative structure**: Uses the standard IAM `v2` policy structure with fully qualified permission identifiers. ### Why This Is Optimal This solution enforces uniform security guardrails across the entire folder hierarchy while explicitly handling group overlap via `exceptionPrincipals`. It eliminates the operational overhead of managing individual project-level allow policies and ensures strict enforcement through IAM's built-in evaluation order.

Iam Deny Policy Hierarchy Exceptions | Professional Cloud Security Engineer

Iam Deny Policy Hierarchy Exceptions

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 security team is establishing authorization guardrails across Google Cloud resource hierarchies. The team needs to enforce the following access requirements on a folder named Production-Workloads:

Prevent all developers in the Google Group developers@example.com from creating and deleting service account keys across all current and future projects in the folder, even if they hold broad project-level Owner or Editor IAM roles.
Permit a specialized operational response team in breakglass-ops@example.com (whose members are also in developers@example.com) to retain full permissions to create and delete service account keys within these projects.
Apply the restriction centrally with automated inheritance, ensuring deny rules override allow grants without requiring individual policy modifications on each underlying project.

Which configuration should the security team implement to satisfy these requirements?

Update the folder-level IAM allow policy by attaching an IAM Condition to the existing Owner and Editor role bindings that checks resource.matchTag() to block service account key actions for developers@example.com.

Create an IAM deny policy attached to the Production-Workloads folder with a deny rule that sets deniedPermissions to iam.googleapis.com/serviceAccountKeys.create and iam.googleapis.com/serviceAccountKeys.delete, deniedPrincipals to principalSet://goog/group/developers@example.com, and exceptionPrincipals to principalSet://goog/group/breakglass-ops@example.com.

Create an IAM deny policy attached to each individual project in the folder with deniedPrincipals set to principalSet://goog/group/developers@example.com and deniedPermissions set to iam.googleapis.com/serviceAccountKeys.*, and grant a custom role containing key management permissions to breakglass-ops@example.com on each project.

Apply the Organization Policy constraint constraints/iam.disableServiceAccountKeyCreation at the Production-Workloads folder level and add an IAM condition exemption for breakglass-ops@example.com.

Professional Cloud Security Engineer

Iam Deny Policy Hierarchy Exceptions

Related questions