TF-004 Implement and maintain state Practice Question
A DevOps engineer manages infrastructure with Terraform using an S3 backend with DynamoDB locking. During a `terraform apply`, the engineer's network connection drops. After reconnecting, they run `terraform plan` and get an error: "Error acquiring the state lock." The lock is from the previous session. The engineer has verified that no other operations are running. What is the appropriate next step to proceed?
⚠ Common exam trap
Candidates often mistakenly think that Terraform locks have a timeout or that `terraform init` can reset backend state issues, leading them to choose waiting or reinitializing instead of using the explicit `force-unlock` command.
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
✓
Use `terraform force-unlock <lock_id>` to remove the stale lock
`terraform force-unlock` is the intended mechanism to manually remove a stale lock from the DynamoDB table when the process that held the lock has terminated abnormally. The engineer has confirmed no other operations are running, so the lock is orphaned and safe to remove. This command requires the specific lock ID, which is provided in the error message.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the DynamoDB table and recreate it
Why it's wrong here
Deleting the DynamoDB table used for state locking would irrevocably remove all current and historical lock entries. This action would immediately disable state locking for all Terraform users and operations, potentially leading to concurrent state modifications and corruption. Recreating the table would only provide an empty locking mechanism, requiring all active operations to re-establish their locks, which is highly disruptive and unnecessary.
- ✗
Wait 15 minutes for the lock to expire automatically
Why it's wrong here
Terraform state locks, particularly those managed by a remote backend like AWS DynamoDB, do not automatically expire after a set period. A lock persists indefinitely until it is explicitly released by a successful `terraform apply` or `terraform destroy` operation, or manually removed using `terraform force-unlock`. Waiting would be futile as the stale lock would continue to prevent further operations.
- ✓
Use `terraform force-unlock <lock_id>` to remove the stale lock
Why this is correct
When a Terraform operation fails or is interrupted, it can leave behind a stale state lock in the remote backend, such as an entry in the DynamoDB table. The `terraform force-unlock <lock_id>` command is specifically designed to remove such persistent, but no longer active, lock entries. By providing the unique `lock_id`, this command directly instructs the backend to clear the specific lock, enabling subsequent Terraform operations to proceed safely.
- ✗
Run `terraform init` to reset the backend connection
Why it's wrong here
Running `terraform init` initializes the working directory, downloading providers, modules, and configuring the backend. While it establishes or re-establishes the connection to the remote state backend, it does not possess any functionality to clear or reset existing state locks. Its purpose is setup and configuration, not state management or lock resolution, making it ineffective for removing a stale 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
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.