hardMultiple ChoiceObjective-mapped
Google ACE Practice Question: Managing Terraform state for a GCP infrastructure…
You are managing Terraform state for a GCP infrastructure project shared by a team of 5 engineers. You need to prevent simultaneous `terraform apply` operations from causing state corruption. What is the recommended backend configuration?
⚠ Common exam trap
Google Cloud often tests the distinction between a remote backend that supports locking (like `gcs` or `s3`) versus a remote backend that only stores state (like `consul` without locking or a plain HTTP backend), and the trap here is that candidates may think any remote storage (like Cloud Source Repository) or a third-party service (like Terraform Cloud) is equally valid, when the question specifically requires a GCP-native solution with locking.
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
✓
Configure the `gcs` backend in Terraform, pointing to a Cloud Storage bucket with versioning enabled.
The `gcs` backend with versioning enabled provides both remote state storage and built-in state locking via Cloud Storage's object-level consistency model. When one engineer runs `terraform apply`, the backend acquires a lock by writing a lock file to the bucket; other concurrent operations are blocked until the lock is released, preventing state corruption. Versioning further protects against accidental state deletion or corruption by allowing rollback to previous state versions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store state locally on each engineer's machine and merge state files manually after each apply.
Why it's wrong here
Keeping state files only on each engineer's machine means there is no single source of truth, so two engineers can run 'terraform plan/apply' against different states and drift quickly. Terraform state is a JSON mapping of resources to real infrastructure, and it is not designed to be merged; any manual merge of conflicting state files is error-prone and commonly leads to corruption. You also lose all locking and cannot detect concurrent operations, so a team would be applying inconsistent or stale configurations.
- ✓
Configure the `gcs` backend in Terraform, pointing to a Cloud Storage bucket with versioning enabled.
Why this is correct
The gcs backend stores Terraform state in a Cloud Storage bucket, which automatically enables state locking via the bucket's object semantics. While one apply is running, a lock is held so a second 'terraform apply' fails with a lock error, preventing concurrent destructive changes. Enabling versioning on the bucket preserves prior state generations, giving you a rollback path if a state update is corrupted or incorrect.
- ✗
Use Terraform Cloud (HashiCorp) as the backend for state locking.
Why it's wrong here
Terraform Cloud does provide robust remote state locking and collaboration, but it is a HashiCorp SaaS product, not a GCP-native service. Using it would require managing an external account, network access, and a separate billing relationship, whereas the question calls for a solution that stays within Google Cloud. A GCS bucket backend gives you equivalent locking and state storage without leaving the GCP environment, so Terraform Cloud is unnecessary and not the best answer.
- ✗
Use a Cloud Source Repository to store state files with branch-based locking.
Why it's wrong here
Cloud Source Repository is a Git-based code host; Git tracks file versions but has no concept of Terraform's per-apply state lock or transactional updates. 'Branch-based locking' is not what Terraform consumes and won't prevent two engineers from running 'terraform apply' from different branches at the same time. Additionally, state files contain sensitive data such as resource attributes and secrets, and they should never be stored in a source control system that may be widely accessed or retained in history.
Go deeper
Related to this question
About these practice questions
Courseiva writes every ACE question from scratch — 769 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.