Resolving State Lock Errors in Terraform
An organization uses Terraform with remote state stored in S3 and DynamoDB for state locking. During a plan, they receive the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. What is the most likely cause?
Quick Answer
The correct answer is that another Terraform process is currently running and holds the state lock. This error occurs because Terraform uses DynamoDB’s conditional write operations to enforce exclusive access to the state file; when a second process attempts to acquire the lock while the first holds it, DynamoDB returns a ConditionalCheckFailedException, signaling that the lock item already exists with a matching lock ID. On the HashiCorp Terraform Associate TF-003 exam, this question tests your understanding of remote state locking mechanics and the specific error messages that arise from concurrent operations—a common trap is confusing this with configuration issues like incorrect IAM permissions or a missing DynamoDB table, which would produce different errors such as AccessDeniedException or ResourceNotFoundException. Remember the memory tip: “Locked out? Check for another run in progress first.”
⚠ Common exam trap
A common pitfall in Terraform exams is confusing S3 state file corruption with DynamoDB state lock contention. The ConditionalCheckFailedException specifically indicates that another process holds the lock, not that the state file is damaged.
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
✓
Another Terraform process is currently running and holds the state lock.
The error 'ConditionalCheckFailedException' occurs when DynamoDB's conditional put operation fails, which happens when a lock item already exists in the DynamoDB table. This indicates another Terraform process currently holds the state lock, preventing concurrent operations. Terraform uses DynamoDB's conditional writes to ensure only one process can acquire the lock at a time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The state file in S3 is corrupted.
Why it's wrong here
A corrupted state file would cause parsing errors, not lock errors.
- ✗
The DynamoDB table is not configured with a primary key named LockID.
Why it's wrong here
Missing primary key would cause table creation error but not 'ConditionalCheckFailedException'.
- ✗
The S3 bucket does not have versioning enabled.
Why it's wrong here
Missing versioning causes state file versioning issues, not lock acquisition errors.
- ✓
Another Terraform process is currently running and holds the state lock.
Why this is correct
Lock acquisition fails because another process holds the lock.
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
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 →
Same concept, more angles
2 more ways 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. Refer to the exhibit. A user encounters this error while running 'terraform plan'. What is the best course of action?
hard- ✓ A.Run 'terraform force-unlock' with the lock ID after verifying no other process holds the lock
- B.Change the backend to local and run plan again
- C.Delete the state file and run terraform init
- D.Wait for 5 minutes and retry
Why A: The error indicates that the state file is locked, which prevents concurrent operations to avoid corruption. Running 'terraform force-unlock' with the lock ID is the correct recovery step, but only after verifying that no other Terraform process is actively using the state. This command releases the lock from the backend (e.g., S3, Consul, or Terraform Cloud), allowing subsequent plans or applies to proceed.
Variation 2. Refer to the exhibit. A Terraform plan fails with the error shown. What is the most likely cause?
easy- A.The S3 bucket does not have versioning enabled.
- B.The DynamoDB table is not configured correctly.
- C.The state file is corrupted.
- ✓ D.Another Terraform run is currently in progress.
Why D: The error message indicates that Terraform cannot acquire a state lock. This typically occurs when another Terraform run is already in progress and holds the lock on the state file. Terraform uses a locking mechanism (often via DynamoDB) to prevent concurrent modifications; if a lock is already held, subsequent runs will fail with this error until the lock is released or expires.
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.