TF-004 Implement and maintain state Practice Question
An organization uses a shared remote backend. They want to prevent concurrent apply operations that could corrupt the state. What built-in mechanism does Terraform provide?
⚠ Common exam trap
HashiCorp often tests the distinction between state locking and state file versioning, where candidates confuse versioning (which provides recovery) with locking (which prevents concurrent writes).
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
✓
State locking
Terraform's state locking mechanism prevents concurrent operations that could corrupt the state file by acquiring a lock on the backend before running `plan` or `apply`. When using a shared remote backend, the lock is held for the duration of the operation and released upon completion, ensuring only one process modifies the state at a time. Option D refers to state file versioning, which provides the ability to recover previous versions but does not prevent concurrent writes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
State locking
Why this is correct
State locking is a critical feature for shared remote backends, designed to prevent race conditions and state corruption when multiple users or automated processes attempt to modify the infrastructure simultaneously. When an operation like `terraform plan` or `terraform apply` begins, Terraform acquires a lock on the state file, preventing any other operation from writing to it until the current operation completes or the lock is explicitly released. This ensures atomic updates, guaranteeing that only one modification occurs at a time, thus maintaining state consistency and integrity.
- ✗
File permissions on the remote state file
Why it's wrong here
While file permissions (e.g., ACLs in S3 or IAM policies) can restrict *who* can access or modify the remote state file, they are fundamentally insufficient for preventing concurrent *writes* by multiple authorized users or processes in a distributed environment. Permissions control authorization, not concurrency. They cannot coordinate multiple simultaneous write attempts to ensure atomicity or prevent race conditions, which is precisely the problem state locking addresses. A coordinated locking service is required to manage concurrent access across different clients.
- ✗
Workspace isolation
Why it's wrong here
Terraform workspaces allow multiple distinct state files to coexist within a single backend configuration, typically used to manage different environments (e.g., dev, staging, prod) from the same configuration. While they provide logical separation of infrastructure states, they offer no mechanism to prevent multiple users or automated processes from simultaneously attempting to modify the *same* active workspace's state file. This means concurrent `terraform apply` operations on the `default` workspace, for instance, would still lead to potential state corruption without another safeguard.
- ✗
State file versioning
Why it's wrong here
State file versioning, often provided by remote backends like S3 or Azure Blob Storage, automatically saves previous versions of the state file whenever it is updated. This feature is invaluable for auditing changes, rolling back to a known good configuration after an error, or recovering from accidental deletions. However, versioning is a reactive mechanism for historical data management and does not actively prevent multiple concurrent `terraform apply` operations from attempting to write to the *current* state file simultaneously, which could still lead to data loss or corruption before a new version is even created.
- ✗
Backend versioning
Why it's wrong here
"Backend versioning" typically refers to the ability of the remote storage service (e.g., S3 bucket versioning) to store multiple historical versions of the state file, similar to state file versioning. Alternatively, it could refer to version control for the Terraform configuration itself, which manages changes to the HCL code. Neither of these mechanisms, however, provides an active, real-time coordination layer to prevent multiple `terraform apply` commands from simultaneously attempting to modify the *current* state file. They are primarily for historical tracking and recovery, not for enforcing exclusive write access during an operation.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 TF-004 practice question is part of Courseiva's free HashiCorp 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 TF-004 exam.