Google ACE Deploying and Implementing a Cloud Solution 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.

• ✗

  backend "cloud" { bucket = "my-terraform-state" }

  Why it's wrong here

  The backend type "cloud" is not a recognized Terraform backend. Terraform defines specific backend identifiers like "local", "gcs", "s3", and "remote" (the latter for Terraform Cloud). Using "cloud" in a configuration will cause initialization to fail with a "backend not found" error because Terraform cannot interpret it. Additionally, even if you meant Terraform Cloud, the correct backend is "remote" or a cloud block in newer versions, not a backend "cloud" block with a bucket argument.

• ✗

  backend "local" { path = "terraform.tfstate" }

  Why it's wrong here

  The local backend stores state in a plain file on the same machine where Terraform runs. While this is acceptable for solo experiments, it is wrong here because it does not support shared locking, preventing multiple engineers from safely applying changes without conflict, and in a managed GCP environment state would be isolated to one machine. This setup also risks losing the state file, which would orphan the real infrastructure from its Terraform configuration. A shared remote backend like GCS is required for collaborative resource management.

• ✗

  backend "consul" { address = "consul.example.com" }

  Why it's wrong here

  Using the Consul backend for Terraform state is inappropriate in a Google Cloud context because Consul is a separate HashiCorp service-discovery and key-value store, not a GCP-native storage service. This backend would require deploying and maintaining a Consul cluster, adding operational overhead, and it does not provide GCP IAM integration, object versioning, or built-in encryption that the gcs backend offers. For team-based GCP resource management, remote state should be stored in a GCP service such as Cloud Storage, not an external system.

• ✓

  backend "gcs" { bucket = "my-terraform-state" }

  Why this is correct

  Configuring the gcs backend with a bucket name is the correct way to store Terraform state for GCP resources. The gcs backend uses a Cloud Storage bucket, which natively supports state file versioning, server-side encryption (including customer-managed keys via Cloud KMS), and access control through GCP IAM, providing both security and consistency for team use. It also enables state locking via bucket objects to prevent concurrent modifications. This is the recommended solution for centralized, durable remote state in GCP.

Go deeper

Related to this question