Google ACE Setting Up a Cloud Solution Environment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a custom role with permissions to enable APIs

  Why it's wrong here

  Creating a custom IAM role that grants permissions such as serviceusage.services.enable only authorizes a principal to call the Service Usage API; it does not constrain which service names can be enabled, because the permission applies to any API in the project. IAM roles, including custom ones, are not evaluated against an allowlist of available services, so a user with this role could easily enable unsupported or costly services. To actually restrict the set of APIs, you need an organization policy, not a custom IAM role.

• ✓

  Use an organization policy to restrict the set of allowed APIs

  Why this is correct

  Use an organization policy with the constraints/serviceusage.services constraint on the organization, folder, or project to define an allowlist of Google API service names, such as compute.googleapis.com and storage.googleapis.com. This policy is enforced at access time and inherited hierarchically, so no project-level IAM change can bypass the allowed set. It is the proper guardrail to ensure that only approved APIs can be enabled across a new project, regardless of who holds IAM permissions.

• ✗

  Set a budget to limit API usage costs

  Why it's wrong here

  Setting a budget or budget alert in Cloud Billing only triggers cost notifications when spending thresholds are forecast or reached; it cannot prevent an API from being enabled or stop IAM users from enabling additional services. Billing data is reactive and has no API-enablement authorization logic, so it fails to address the requirement of restricting which APIs can be enabled. Budgets are useful for controlling costs, but they are not an access-control mechanism and do not limit the set of available APIs.

• ✗

  Assign the Owner role to the project

  Why it's wrong here

  Assigning a user the Owner IAM role at the project level grants them the most privileged access, including the ability to modify IAM policies, enable and disable APIs, and manage all resources within the project. This does not restrict anything; it deliberately expands a principal's power over the project. Because the requirement is to impose a limitation, the Owner role is the opposite of the needed control and would amplify the risk of unauthorized API enablement.

• ✓

  Disable all APIs and enable only the required ones

  Why this is correct

  In a fresh project, you can explicitly disable every API except the required ones through Service Usage, which leaves only an approved set of services available for use. This works as a per-project configuration baseline, but unlike an organization policy, it can be reversed by any principal with serviceusage.services.enable permission unless IAM is also hardened. It is still a correct step toward ensuring that only approved APIs are available, but it lacks the centralized enforcement provided by an organization policy.

Go deeper

Related to this question