TF-004 Implement and maintain state Practice Question
A team of five engineers manages infrastructure using Terraform with remote state stored in an S3 bucket and state locking via a DynamoDB table. After a power outage, an engineer notices that a terraform apply command fails with the message: 'Error: Error acquiring the state lock'. The engineer suspects that a lock from a previous run has not been released. The team needs to proceed with applying changes. Which action should the engineer take to resolve the issue safely?
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 obtained from the error message.
The `terraform force-unlock` command is the intended safe method to release a stuck lock when the lock holder process is confirmed dead. The lock ID is provided in the error message. Option A is incorrect because Terraform state locks do not have a default automatic expiration; they must be explicitly released. Option B is risky: directly deleting the lock record from DynamoDB can lead to inconsistent state if not done carefully, and is not recommended as a standard practice. Option D bypasses locking entirely with `-lock=false`, which can cause state corruption if other operations are in progress, so it is unsafe.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Wait for the lock to expire automatically (locks have a 5-minute TTL).
Why it's wrong here
Terraform state locks, particularly when utilizing remote backends like S3 with DynamoDB for locking, are designed to be persistent and do not possess a default time-to-live (TTL). They are intended to prevent concurrent operations indefinitely until explicitly released by a `terraform unlock` or `terraform force-unlock` command. Therefore, waiting for an automatic expiration is a misconception, as the lock will remain active, continuously blocking any subsequent Terraform operations.
- ✗
Delete the lock record from the DynamoDB table using the AWS CLI.
Why it's wrong here
Directly deleting a lock record from the DynamoDB table using the AWS CLI bypasses Terraform's internal state management and validation processes. While it might remove the physical lock, this action can lead to an inconsistent state within Terraform's understanding of the infrastructure, potentially causing future operations to fail or misbehave due to a desynchronized lock status. The `terraform force-unlock` command is the controlled and safe method for releasing a stale lock, ensuring state integrity.
- ✓
Run terraform force-unlock with the lock ID obtained from the error message.
Why this is correct
The `terraform force-unlock` command is the officially supported and safest method for releasing a persistent state lock when the original process that acquired it has crashed or is no longer active. This command specifically requires the lock ID, which is typically provided within the error message when an operation attempts to acquire an already held lock. Using `force-unlock` ensures that Terraform's backend properly acknowledges the lock's release, preventing potential state corruption that could arise from manual intervention.
- ✗
Run terraform apply with the -lock=false flag to bypass locking.
Why it's wrong here
Running `terraform apply` with the `-lock=false` flag explicitly instructs Terraform to proceed with an operation even if a state lock is currently held. While technically possible, this action is extremely dangerous as it completely bypasses the critical concurrency control mechanism designed to prevent simultaneous modifications to the state file. Doing so risks severe state corruption and data loss if another operation is genuinely in progress, leading to unpredictable and potentially unrecoverable infrastructure configurations.
Visual reference
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 →
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.