TF-004 Implement and maintain state Practice Question
A developer runs `terraform apply` and receives the error: 'Error acquiring the state lock'. Another engineer is currently running `terraform plan`. What should the developer do?
⚠ Common exam trap
A common misconception is that running `terraform force-unlock` is the standard way to resolve a lock error. In reality, this command should only be used to clear orphaned locks after confirming no other process is using the state. When another engineer is actively running `terraform plan`, the lock will be released automatically upon completion.
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
✓
Wait for the lock to be released automatically
Terraform uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When another engineer is running `terraform plan`, the lock is held for the duration of the plan to ensure consistency. The lock will be automatically released once the plan completes or times out, so waiting is the appropriate action.
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 init to reinitialize the backend
Why it's wrong here
Reinitialising the backend re-reads configuration but does not release the DynamoDB lock entry held by the running plan, so the apply still fails. It tempts when backend configuration has changed or state migration is needed, not for lock contention.
- ✓
Wait for the lock to be released automatically
Why this is correct
Terraform's state lock is held only for the duration of the other engineer's plan operation and is released automatically once that command finishes, so waiting lets the developer retry apply without forcing an unlock that could corrupt state.
- ✗
Run terraform force-unlock with the lock ID
Why it's wrong here
The lock is held legitimately by the running plan, so force-unlocking corrupts state consistency and can cause concurrent writes. Force-unlock suits only a confirmed stale lock after the holding process has died; here the developer should wait.
- ✗
Run terraform plan with -lock=false to bypass the lock
Why it's wrong here
Running plan with -lock=false skips lock acquisition entirely, permitting concurrent state access and risking corruption; it does not help the blocked apply. It tempts for read-only inspection against a locked backend, where skipping the lock is tolerable.
- ✗
Delete the lock file from the S3 bucket
Why it's wrong here
Deleting the lock file corrupts state integrity because the other engineer's plan still holds it; the lock exists precisely to prevent concurrent operations. It tempts when a lock is genuinely stale after a crashed run, where force-unlock with -force is the sanctioned remedy.
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 434 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 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.