TF-004 Implement and maintain state Practice Question
A platform team stores Terraform state in an S3 bucket and uses a DynamoDB table for state locking. An engineer's `terraform apply` was interrupted by a workstation crash, and the lock entry remains in DynamoDB. Other engineers now receive 'Error acquiring the state lock' when they run plans. The team wants to safely clear the lock without risking state corruption. Which sequence of actions is most appropriate?
⚠ Common exam trap
The trap here is thinking that deleting the DynamoDB lock item or disabling locking is equivalent to force-unlock; only force-unlock safely targets and removes the specific lock.
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
✓
Run `terraform force-unlock` with the lock ID, after verifying no other Terraform process is actively running against the same state.
A stale lock after an interrupted apply is best cleared with `terraform force-unlock`, which removes the specific lock entry identified by the lock ID. Before doing so, the team must confirm no other Terraform process is running against the same state, because force-unlock provides no coordination. Manually deleting the DynamoDB item, disabling locking, or pushing state all bypass Terraform's safety mechanisms and can cause concurrent writes or leave the backend inconsistent.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run `terraform force-unlock` with the lock ID, after verifying no other Terraform process is actively running against the same state.
Why this is correct
`terraform force-unlock` removes the lock entry from the backend, allowing subsequent operations to proceed. The critical safety step is confirming that no other process is mid-apply; if one is, removing the lock permits concurrent writes and can corrupt state. Once verified, force-unlock is the supported mechanism and requires the lock ID reported in the error message, ensuring the correct lock is targeted.
- ✗
Delete the lock item directly from the DynamoDB table using the AWS CLI.
Why it's wrong here
Manually deleting the DynamoDB item bypasses Terraform's lock management and provides no coordination guarantees. If a process is still running, it may continue writing while a new process also acquires the lock, leading to state corruption. The DynamoDB item also contains metadata Terraform uses for lock validation, and removing it out-of-band can leave the backend in an inconsistent state that Terraform cannot diagnose cleanly.
- ✗
Disable state locking in the backend configuration, apply the change, then re-enable locking.
Why it's wrong here
Disabling locking does not clear the existing lock entry in DynamoDB; it only stops Terraform from attempting to acquire locks going forward. The stale item remains, and re-enabling locking would cause the same error to reappear. Worse, operating with locking disabled removes protection against concurrent applies, which is exactly the risk the team is trying to avoid during a recovery operation.
- ✗
Run `terraform state pull` to refresh the local copy, then `terraform state push` to overwrite the remote state.
Why it's wrong here
Pulling and pushing state does not interact with the lock table. `terraform state pull` reads remote state, and `terraform state push` forcibly writes state without acquiring a lock in the normal way, which can bypass the very protection that prevents concurrent modification. This sequence neither clears the stale DynamoDB lock entry nor addresses the root cause, and it introduces a risk of overwriting newer 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
This TF-004 question is part of Courseiva's 434-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
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.