TF-004 Use Terraform outside the core workflow Practice Question
A team is migrating from using local state to a remote backend for collaboration. They want to ensure that team members cannot overwrite each other's changes. Which feature should they enable?
⚠ Common exam trap
HashiCorp often tests the distinction between state locking (preventing concurrent writes) and state versioning (enabling rollback), causing candidates to confuse S3 versioning as a solution for overwrite prevention.
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 (e.g., DynamoDB)
State locking prevents concurrent modifications by ensuring that only one operation can modify the Terraform state at a time. When using a remote backend like S3 with DynamoDB, Terraform acquires a lock before writing to the state file and releases it after completion, preventing race conditions and state corruption.
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 (e.g., DynamoDB)
Why this is correct
When migrating to a remote backend, state locking is essential to prevent concurrent Terraform operations from corrupting the shared state file. This mechanism ensures that only one `terraform apply` or `terraform plan` operation can modify the state at any given time. Backends like S3, when configured with DynamoDB for locking, acquire an exclusive lock before modifying the state, releasing it upon completion. This critical feature maintains state integrity in collaborative environments.
- ✗
S3 bucket versioning
Why it's wrong here
S3 bucket versioning provides a history of all objects, allowing for recovery from accidental deletions or overwrites by retaining previous versions of the state file. While crucial for data durability and rollback capabilities, versioning does not prevent two separate `terraform apply` commands from simultaneously attempting to write to the *current* state. This means it cannot prevent race conditions or the corruption that arises from concurrent modifications, only offering a way to recover *after* such an event.
- ✗
Force unlock command
Why it's wrong here
The `terraform force-unlock` command is a troubleshooting utility designed to manually release a state lock that has become stuck due to an unexpected interruption, such as a crashed Terraform process. It is a remedial action, not a preventative measure for managing concurrent operations. Using `force-unlock` without verifying that no other operations are active can lead to severe state corruption, as it bypasses the very mechanism designed to protect against simultaneous modifications.
- ✗
Workspace isolation
Why it's wrong here
Terraform workspaces allow for multiple distinct state files to be managed by a single configuration, effectively isolating different environments like 'dev' and 'prod' within the same backend. While workspaces separate state files, they do not provide any mechanism to prevent multiple users or processes from concurrently applying changes *within* a single workspace. Therefore, state locking remains necessary to ensure integrity and prevent race conditions for operations targeting the same workspace's state.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 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 →
Same concept, more angles
1 more way this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO Terraform backends support remote state locking?
medium- ✓ A.s3
- B.local
- ✓ C.consul
- D.inmem
- E.http
Why A: The S3 backend supports remote state locking via DynamoDB. When you configure the S3 backend with a `dynamodb_table` parameter, Terraform uses DynamoDB's conditional writes to acquire and release locks. Similarly, the Consul backend also provides native state locking capabilities, leveraging Consul's key-value store for distributed locks, ensuring that only one user or process can modify the state at a time for both backends.
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.