Task 1.5: Defining the resource hierarchy.

• AA log-based alert on cluster creation and update audit entries that lack Binary Authorization

  Incorrect

  An alert fires after the cluster has been created or changed, which the team said is not enough, and its query is logic the team would maintain.

• BA custom organization policy constraint on GKE clusters that denies requests where Binary Authorization is off

  Incorrect

  It would block the request, but a custom constraint's condition is a CEL expression the team must write and maintain, and Google already publishes a managed constraint for this setting.

• CAn organization policy on the prod folder that enforces the managed constraint container.managed.enableBinaryAuthorization

  Correct

  This managed constraint requires Binary Authorization to be enabled when GKE clusters are created or updated, so a noncompliant request fails, and Google maintains its logic.

• DA Binary Authorization policy in each prod project that requires attestations for every image

  Incorrect

  The policy governs image deployment on clusters where Binary Authorization is enabled; it does not stop anyone from creating a cluster with it turned off.

Google publishes managed constraints for many GKE settings, among them container.managed.enableBinaryAuthorization ("Require enabling Binary Authorization for GKE clusters"), which applies when clusters are created or updated. Enforced through a policy on the folder, it makes a noncompliant request fail. A custom constraint is the tool for a setting that no Google-provided constraint covers, and it needs a CEL condition of your own; an alert only reports after the fact.

• AAllow us-central1 locations in a project policy that merges with the parent's allowed values

  Correct

  With inheritFromParent set to true, the project's allowed values are merged with the inherited ones, so the project gets the EU locations plus us-central1.

• BAllow us-central1 locations in a project policy that replaces the parent policy

  Incorrect

  A policy that does not inherit replaces the parent's values, so the project would lose the EU locations it uses today.

• CAdd us-central1 locations to the organization's policy

  Incorrect

  Changing the organization policy would let every project use us-central1, which the requirement forbids.

• DRemove the policy from the project's folder so that the project falls back to the default

  Incorrect

  Removing a folder policy changes every project in the folder, and the project would still inherit the organization's EU-only rule.

Organization policies are inherited down the hierarchy. A policy on a lower resource either replaces the inherited one or, with inheritFromParent set, is merged and reconciled with it. For list constraints such as resource locations, merging adds the child's allowed values to the parent's.

• AGrant the role at the folder level instead, because the policy applies only to projects

  Incorrect

  Organization policies are inherited by folders and projects alike, so the grant would fail there too.

• BTurn off the IAM recommender, which blocks grants to identities outside the domain

  Incorrect

  The recommender only suggests changes; it never blocks a grant.

• CAdd the partner's Google Workspace customer ID to the allowed values of the domain-restricted sharing policy

  Correct

  Organizations created on or after May 3, 2024 enforce iam.allowedPolicyMemberDomains by default with only their own domain, so the partner has to be added to the allowed list.

• DAsk the partner to create Gmail accounts, which the default policy allows

  Incorrect

  The default policy allows only the company's own domain, so private Gmail accounts are rejected as well.

Domain-restricted sharing limits which principals can be granted IAM roles in an organization. For organizations created on or after May 3, 2024, the legacy constraint iam.allowedPolicyMemberDomains is enforced by default with the organization's own domain as the only allowed value; the newer iam.managed.allowedPolicyMembers constraint offers the same control with principal sets.

• APut the policy in dry-run mode and review the audit logs it writes

  Correct

  A dry-run policy is evaluated like an enforced one, but violations are only written to audit logs instead of being denied.

• BEnforce the policy on one production project for a week and watch for incidents

  Incorrect

  Enforcing it refuses requests in that project, which is exactly the breakage the team wants to avoid.

• CRun Policy Simulator for allow policies against the new constraint

  Incorrect

  Policy Simulator previews changes to IAM allow policies, not organization policy constraints.

• DTurn on VPC Flow Logs everywhere to find VMs that receive internet traffic today

  Incorrect

  Flow logs show current traffic but not which future API requests the constraint would refuse.

Organization policies can be created in dry-run mode. They are evaluated like enforced policies, but a violating action is allowed and recorded in the audit logs, so a team can measure the impact of a constraint before turning on enforcement. Dry run is available for managed and custom constraints and a few legacy ones, which is why the managed constraint is used here rather than the legacy compute.vmExternalIpAccess.

• AReorganize all folders so that production projects sit in one folder, then set the policy on that folder

  Incorrect

  Moving projects could work but is a large change with its own risk, and it is not needed for this requirement.

• BOne organization-level policy whose rule is enforced only under a condition on that tag

  Correct

  Organization policies can be enforced conditionally on secure tags, so the rule follows the tag wherever a project sits.

• CA separate policy on each production project, set when the project is created

  Incorrect

  Per-project policies depend on every creator and miss projects that are tagged as production later.

• DAn IAM deny policy on the key creation permission, attached to every production project

  Incorrect

  Attached project by project, the deny policy misses projects tagged as production later, and the requirement is for the constraint itself to follow the tag.

Tags can scope organization policies: a policy rule can carry a condition on a tag key and value, and it is enforced only on resources that have, or inherit, that tag. This lets one policy target production resources wherever they sit in the hierarchy.

• ARemove the Owner role from the network team so that nobody holds the project delete permission

  Incorrect

  Taking away Owner also removes permissions the team needs, and someone must still hold the permission.

• BA daily export of the project's configuration so that it can be rebuilt after a deletion

  Incorrect

  A backup helps recovery after the damage; it does not block the deletion.

• CAn organization policy that disables the Resource Manager API in the host project

  Incorrect

  Disabling the API in the project would break project management and is not how deletion is protected.

• DA lien on the host project that restricts resourcemanager.projects.delete until it is removed

  Correct

  A lien blocks deletion of the project until an Organization Administrator or Project Owner removes it.

Project liens protect critical projects from accidental or malicious deletion. While a lien exists, the project cannot be deleted, and Google Cloud also places liens automatically in some cases, such as on projects whose service accounts are used across projects.