TF-004 Use the core Terraform workflow Practice Question
A team uses Terraform with remote state in Azure Storage. They have a CI/CD pipeline that runs terraform plan and apply. Recently, a team member ran terraform apply manually from their local machine and the process crashed due to a network interruption. Now, the pipeline's next run fails with an error: "Error: Error acquiring the state lock". The team is unsure who holds the lock. They need to proceed with the pipeline as soon as possible. What should they do?
⚠ Common exam trap
HashiCorp often tests the misconception that `-lock=false` is a safe workaround for lock issues, but in reality it bypasses safety guarantees and can lead to state corruption, while `force-unlock` is the correct, intended recovery 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 with the lock ID to break the lock.
The correct action is to use `terraform force-unlock` with the lock ID to break the stale lock. When a Terraform process crashes while holding a state lock (stored in Azure Blob Storage via the `azurerm` backend), the lock remains in place, blocking all subsequent operations. The `force-unlock` command is the designed mechanism to manually release such locks, and the lock ID can be obtained from the error message or by querying the Azure Storage blob's lease state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use terraform force-unlock with the lock ID to break the lock.
Why this is correct
When a Terraform operation fails midway, it can leave a state lock in place, preventing subsequent operations. The `terraform force-unlock` command is specifically designed to manually release such a "stuck" lock. It requires the lock ID, which can typically be found in the error message of the failed operation or by inspecting the backend. While effective, it must be used with extreme caution to avoid concurrent state modifications and potential corruption, ensuring no other operations are genuinely running.
- ✗
Wait for the lock to expire automatically.
Why it's wrong here
This approach is incorrect because state locks, particularly when using Azure Storage as a remote backend, do not automatically expire. Unlike some other locking mechanisms, Terraform's state locking in Azure Blob Storage is persistent until explicitly released. Waiting indefinitely would simply keep the state locked, preventing any further Terraform operations and requiring manual intervention to resolve the impasse.
- ✗
Re-run terraform apply with -lock=false to skip locking.
Why it's wrong here
Using `terraform apply -lock=false` is highly discouraged and does not resolve a stuck lock; instead, it instructs Terraform to proceed without attempting to acquire a new lock. This flag bypasses the critical state locking mechanism, making the state vulnerable to concurrent modifications from other Terraform operations. Such concurrent writes can lead to severe state corruption, data loss, and inconsistencies between your infrastructure and the Terraform state file.
- ✗
Delete the .terraform folder and reinitialize.
Why it's wrong here
Deleting the local `.terraform` directory and reinitializing Terraform will not resolve a remote state lock. The `.terraform` folder contains provider plugins, modules, and other local configuration data, but it does not store information about remote state locks. The actual state lock is maintained by the configured remote backend, such as Azure Storage, and persists independently of the local working directory's contents.
Visual reference
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
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.