Google ACE Deploying and Implementing a Cloud Solution Practice Question

A team is using Terraform to manage Google Cloud resources. They want to store the Terraform state file in a Cloud Storage bucket with versioning enabled. Which backend configuration should they use?

⚠ Common exam trap

The trap here is the gs:// prefix — candidates familiar with gsutil commands assume the bucket argument needs the URI scheme, but Terraform's GCS backend requires only the bare bucket name.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

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

The correct backend block for Google Cloud Storage in Terraform is backend "gcs", and the bucket argument must be the bare bucket name (e.g., "my-terraform-state-bucket") without the gs:// scheme prefix. Terraform's GCS backend automatically uses the Google Cloud Storage API and supports object versioning natively when enabled on the bucket. This configuration stores the state file at gs://my-terraform-state-bucket/terraform/state/default.tfstate.

Answer analysis

Option-by-option breakdown

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

✗
terraform { backend "cloud" { bucket = "my-terraform-state-bucket" prefix = "terraform/state" } }
Why it's wrong here
Terraform has no "cloud" backend type; valid Google Cloud state storage uses the gcs backend. It is tempting because the name suggests native cloud storage, and would be correct only if such a backend existed, whereas the actual supported backend for Cloud Storage is gcs.
✓
terraform { backend "gcs" { bucket = "my-terraform-state-bucket" prefix = "terraform/state" } }
Why this is correct
The gcs backend block points Terraform at the Cloud Storage bucket holding remote state, and the prefix namespaces the state object within that bucket. Versioning is configured on the bucket itself, so the backend only needs bucket and prefix.
✗
terraform { backend "gcs" { bucket = "gs://my-terraform-state-bucket" prefix = "terraform/state" } }
Why it's wrong here
The gcs backend value must be the bare bucket name; the gs:// scheme prefix is invalid and Terraform rejects the configuration. It is tempting because gs:// is the standard Cloud Storage URI form, and would be correct in gcloud or gsutil commands, where that prefix is required.
✗
terraform { backend "remote" { hostname = "app.terraform.io" organization = "my-org" workspaces { name = "my-workspace" } } }
Why it's wrong here
The remote backend stores state in Terraform Cloud, not a Cloud Storage bucket, so versioning there is irrelevant to the requirement. It is tempting because remote backends centralise state with locking, and would be correct when teams use Terraform Cloud or Enterprise workspaces instead of GCS.

Go deeper

Google ACE Deploying and Implementing a Cloud Solution Practice Question

Why each option matters

Option-by-option breakdown

Related to this question