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 destroys all tracked resource mappings, causing Terraform to plan recreation of existing infrastructure. The temptation is that a fresh state clears the lock, but the correct action is `terraform force-unlock` with the lock ID, which releases the lock without touching state contents.
- ✓
Run terraform force-unlock with the lock ID
Why this is correct
terraform force-unlock releases a stale state lock using the lock ID reported in the error message, restoring immediate write access to the remote state. This satisfies the stem's requirement to unlock straight away without waiting for the lock to expire.
- ✗
Manually edit the state file to remove the lock
Why it's wrong here
Editing the state file directly corrupts its serial and lineage metadata, and Terraform Cloud's remote backend ignores local edits, so the lock persists. The tempting appeal is bypassing the lock API, but that is what `terraform force-unlock` exists for on remote backends.
- ✗
Run terraform unlock
Why it's wrong here
No terraform unlock command exists; state locking is released with terraform force-unlock, supplying the lock ID. The name is tempting because it mirrors the intended action, but running it produces an unknown-command error rather than clearing the lock.
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 →
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: When using an S3 backend, Terraform state locking is implemented via a DynamoDB table. If two users run apply/plan concurrently, the second operation is blocked because it cannot acquire the lock, preventing state corruption. This is the standard AWS-recommended configuration for S3 backends.
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: Terraform uses a state locking mechanism to prevent concurrent operations that could corrupt the state file. When another user (or CI/CD pipeline) is running terraform plan or terraform apply against the same backend, the lock is held and any subsequent apply fails with a 'state file is locked' error. The correct resolution is to wait for the other operation to finish or, if it is stale, force-unlock it.
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.