Google ACE Practice Question: A team is creating a new GCP project for a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Use a gcloud script with `gcloud projects create`, `gcloud beta billing projects link`, and `gcloud services enable`.

  Why it's wrong here

  A gcloud-based shell script is an imperative, procedural approach: each command executes against live cloud state without Terraform's plan/apply cycle, so there is no pre-execution validation of whether resources already exist or whether dependencies are satisfied. Commands like `gcloud beta billing projects link` are callable independently but not idempotent by default, and if a step fails mid-script, there is no rollback or state file to reconcile partial provisioning. Although you can script folder placement and API enablement, the result is not a self-healing, drift-detecting IaC solution, and reviewing a bash script for approval is far less transparent than reviewing a declarative HCL configuration.

• ✓

  Use Terraform with `google_project`, `google_project_service`, and billing account linkage resources.

  Why this is correct

  Terraform is the right choice because it provides a declarative, end-to-end project bootstrap in a single `terraform plan`/`apply` workflow. The `google_project` resource can specify the parent folder, billing account, and project name, while `google_project_service` entries enable required APIs such as compute.googleapis.com; Terraform's dependency graph automatically ensures the project exists and is linked to billing before services are enabled. Because Terraform stores real-world resource IDs in its state file, re-running apply after a manual change detects drift and either corrects it or surfaces a plan, making the whole process idempotent and auditable.

• ✗

  Use Cloud Console to manually create the project, then document the steps in a runbook.

  Why it's wrong here

  Manually creating the project in the Cloud Console and writing a runbook is not an Infrastructure-as-Code solution at all: every click is unrepeatable in a controlled way, and a person may mis-select the folder, billing account, or API list without an automated guardrail. The resulting project configuration exists only as human memory and a runbook, which cannot be version-controlled, code-reviewed, or automatically diffed against a desired state. This approach also scales poorly when bootstrapping many projects across an organization and makes audit trail recovery dependent on Cloud Console's logs rather than a reproducible declaration.

• ✗

  Use Cloud Deployment Manager with a Python template to create the project.

  Why it's wrong here

  Cloud Deployment Manager is a Google-native IaC tool and can create projects through YAML/Python templates, but it lacks first-class resource types for linking a project to a Cloud Billing account; you would have to resort to a separate gcloud command or a custom type, leaving part of the bootstrap outside the deployment. Its template engine is less expressive than HCL for dealing with multi-resource dependencies and dynamic values, and Google has shifted strategic IaC investment toward Terraform. Additionally, Deployment Manager does not maintain a comparable state-managed, plan-review artifact, so it cannot match Terraform's level of pre-apply validation and drift correction.

Go deeper

Related to this question