Force Unlock Terraform State
A team is using a remote backend in Terraform Cloud. After a failed apply, the state file is locked. The team lead wants to unlock the state immediately. What should be done?
Quick Answer
The answer is to run terraform force-unlock with the lock ID. This is the correct approach because Terraform Cloud uses a locking mechanism on the remote backend to prevent concurrent state modifications and corruption; when a terraform apply fails, the lock persists as a safety measure, and the force-unlock command is the only built-in way to override that lock without bypassing Terraform’s integrity checks. On the HashiCorp Terraform Associate TF-003 exam, this question tests your understanding of state management and backend safety—a common trap is assuming you can delete or manually edit the state file, which would risk data loss and is explicitly discouraged. Instead, remember that you must first retrieve the lock ID from the error message or Terraform Cloud UI, then run terraform force-unlock <LOCK_ID>. A helpful memory tip: think of it as a “safety key” for a stuck lock—never force the file, only force the lock.
⚠ Common exam trap
Many exam-takers confuse `terraform force-unlock` with a non-existent `terraform unlock` command, or mistakenly think that deleting or editing the state file is a valid workaround, when in fact Terraform's state locking is enforced at the backend API level and requires the proper command with the lock ID.
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
The `terraform force-unlock` command with the lock ID is the correct way to manually unlock a state file in Terraform Cloud after a failed apply. This command overrides the backend's lock mechanism, which is designed to prevent concurrent modifications and state corruption. Deleting or editing the state file would bypass Terraform's safety guarantees and risk data loss or inconsistency.
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 state file from the backend and reinitialize
Why it's wrong here
Deleting the state file is destructive and can cause data loss.
- ✓
Run terraform force-unlock with the lock ID
Why this is correct
The terraform force-unlock command with the lock ID manually releases the lock.
- ✗
Manually edit the state file to remove the lock
Why it's wrong here
Editing the state file directly is risky and not recommended.
- ✗
Run terraform unlock
Why it's wrong here
There is no terraform unlock command; the correct command is terraform force-unlock.
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 →
Same concept, more angles
4 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. A team is using a shared backend for Terraform state. After running terraform apply, the state file is locked for an extended period, causing other team members to fail with 'Error acquiring the state lock'. What is the most likely cause?
easy- ✓ A.A previous terraform apply command was interrupted or crashed, leaving a stale lock.
- B.Another team member is actively running terraform apply on the same state.
- C.The backend configuration was changed without running terraform init.
- D.The state file contains resources that no longer exist in the cloud provider.
Why A: Terraform uses a locking mechanism (typically via DynamoDB for AWS S3 backends) to prevent concurrent state modifications. If a `terraform apply` is interrupted or crashes, the lock may not be released, leaving a stale lock entry. This causes subsequent operations to fail with 'Error acquiring the state lock' until the lock is manually removed or expires (if TTL is configured).
Variation 2. A team uses an S3 backend for Terraform state. During a `terraform apply`, another team member accidentally runs a plan that also modifies the same state. Which feature prevents state corruption in this scenario?
easy- A.The `-lock=false` flag
- B.Terraform Cloud remote operations
- ✓ C.State locking via DynamoDB
- D.State versioning in S3
Why C: State locking via DynamoDB prevents concurrent modifications to the state file, ensuring that only one operation can modify the state at a time. Option A (-lock=false) disables locking, which would allow concurrent modifications and risk corruption. Option B (Terraform Cloud remote operations) is not directly related to state locking in this S3 backend scenario. Option D (state versioning) helps recover from corruption but does not prevent simultaneous writes.
Variation 3. During a deployment, a user runs `terraform apply` but the command fails because the state lock cannot be acquired. They suspect the lock was released after the previous `apply` but is still held. What command can they use to force unlock the state?
medium- A.`terraform init -force-copy`
- ✓ B.`terraform force-unlock <lock_id>`
- C.`terraform state unlock`
- D.`terraform break-lock`
Why B: When Terraform cannot acquire a state lock because it was not properly released (e.g., after a crash or interrupted apply), the `force-unlock` command is the only built-in way to manually break the lock. You must provide the lock ID (obtained from the error message or backend) to override the lock, which is stored in the backend (e.g., DynamoDB, Consul) and prevents concurrent modifications. This command is designed for recovery scenarios where the lock holder is known to be dead.
Variation 4. Refer to the exhibit. A developer runs `terraform apply` but receives an error that the state file is locked. Which of the following is a likely cause?
medium- A.The DynamoDB table for locking is not configured
- B.The S3 bucket does not exist
- C.The IAM user lacks s3:ListBucket permission
- D.The encryption key is incorrect
- ✓ E.Another user has an active plan or apply running
Why E: A state lock error indicates that the state file is currently locked by another process. This commonly occurs when another user or an automated process is running a terraform plan or apply that holds the lock. Options such as a missing DynamoDB table, nonexistent S3 bucket, lack of s3:ListBucket permission, or incorrect encryption key would result in different error messages related to backend configuration or permissions, not a lock error.
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.