Google ACE Practice Question: An infrastructure team uses Terraform to manage…

Answer analysis

Option-by-option breakdown

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

• ✗

  google_project_iam_binding with the serviceusage.services.enable permission

  Why it's wrong here

  The google_project_iam_binding resource applies an IAM policy binding that grants roles and permissions to a principal—it simply declares who is allowed to perform certain actions. The permission 'serviceusage.services.enable' gives a principal the right to call the Service Usage API and enable services, but the IAM binding does not itself execute any enablement call. To actually enable an API, someone or something with that permission must make the API request, which is exactly what google_project_service does. Thus, using this resource alone leaves the API disabled and creates no Terraform state indicating an enabled service.

• ✓

  google_project_service with the desired service endpoint

  Why this is correct

  The google_project_service resource is the canonical way to enable a specific Google Cloud API for a project; it accepts the service's fully qualified endpoint, such as 'compute.googleapis.com' or 'sqladmin.googleapis.com'. When applied, it asynchronously activates that API and updates Terraform state only after the Service Usage API confirms the enablement. This resource also respects Terraform's dependency ordering, so resources that rely on an API can be deployed only after it is active. There is no other Terraform resource that directly performs API enablement for a project.

• ✗

  google_service_account with enabled_services block

  Why it's wrong here

  The google_service_account resource creates an identity used by workloads to authenticate to GCP, with fields like account_id, display_name, and description. It has no 'enabled_services' block or any equivalent mechanism to control the state of project APIs. Enabling an API is a project-level administrative action performed by the Service Usage API, not by the existence or configuration of a service account. Even if you create a service account, all required APIs must still be enabled separately via google_project_service or a manual gcloud command.

• ✗

  google_project with the services argument listing all required APIs

  Why it's wrong here

  The google_project resource is designed to manage the project's core metadata—its name, ID, folder placement, billing account, and labels—not to manage API enablement. It does not expose a 'services' argument; attempting to pass one would produce a schema validation error because the argument is undefined. Enabling APIs is intentionally delegated to the specialized google_project_service resource, which issues the underlying Service Usage API call. While the google_project resource may set up billing that is a prerequisite for many APIs, it never activates any API itself.

Go deeper

Related to this question