Google ACE Practice Question: Has a policy requiring all new GCP projects to be…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  IAM deny policies on the organization + VPC Service Controls

  Why it's wrong here

  IAM deny policies are used to explicitly block specific actions or resources, and VPC Service Controls restrict allowed API calls and data exfiltration within service perimeters, but neither implements a positive constraint on project placement or billing account selection. An IAM deny policy could deny the `resourcemanager.projects.create` permission organization-wide, but that would prevent all project creation and still not allow exceptions for specific approved folders; it cannot express 'allow creation only under folder X'. VPC Service Controls operate at the API layer for services like GCS and BigQuery, not at the resource management API level, so they have no bearing on which billing account is attached to a newly created project.

• ✓

  Organization policies to restrict allowed billing accounts + granting Project Creator role only at approved folder level

  Why this is correct

  This is the correct preventive approach because the `billing.allowedBillingAccounts` organization policy (constraint: `constraints/billing.allowedBillingAccounts`) restricts the set of billing accounts that can be associated with a project, and it is evaluated at project creation time, not after the fact. Scoping the Project Creator role to only approved folders via IAM roles on those folders means a user can create a project only within those resource boundaries, because the permission to create a project is inherited down the hierarchy only from those folders. Together these controls ensure that any new project is created in an approved folder and must use an allowed billing account, preventing non-compliant project sprawl before it happens.

• ✗

  Cloud Asset Inventory alerts + manual review of new projects

  Why it's wrong here

  Cloud Asset Inventory is a visibility service that continuously snapshots your resource hierarchy, but it is entirely reactive: it can only flag a non-compliant project after the project already exists in an unapproved folder or linked to a prohibited billing account. Alerts trigger manual review, which is a post-hoc control—by the time a reviewer acts, the project is already provisioned with its own IAM policies and can be used within the organization. It also provides no mechanism to block the project creation call at runtime, so it fails as a preventive guardrail for project placement or billing account usage.

• ✗

  Requiring multi-factor authentication for all project creators

  Why it's wrong here

  Requiring multi-factor authentication for all project creators strengthens identity verification but does not alter the authorization context under which the project creation API call is made. A user who passes MFA still holds whatever IAM role they have, such as Project Creator at the organization level, so they can still create a project in any folder and attach any billing account they can access—provided the IAM role permits those actions. MFA only proves who is making the request; it does not constrain where the new project lands in the resource hierarchy or which billing account is linked, which are the two specific conditions the security goal requires.

Go deeper

Related to this question