TF-004 Read, generate and modify configuration Practice Question
You are managing a Terraform configuration for a multi-tier application that includes AWS EC2 instances, an RDS database, and an Application Load Balancer. The configuration uses multiple modules and remote state stored in an S3 bucket with DynamoDB locking. Recently, a colleague made changes to the configuration and applied them successfully. However, you now need to make additional changes and, when you run 'terraform plan', you receive an error: "Error: Error acquiring the state lock". The error message indicates that the lock is held by a different user. You have confirmed that your colleague is not currently running Terraform. What is the most appropriate course of action to proceed with your changes?
⚠ Common exam trap
HashiCorp often tests the misconception that manual S3 or DynamoDB manipulation is acceptable, when in fact Terraform provides a safe, built-in command (`force-unlock`) to handle stale locks without risking state corruption.
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 <lock_id>' to remove the stale lock.
Terraform uses DynamoDB for state locking to prevent concurrent modifications. When a lock becomes stale (e.g., due to a crash or network interruption), `terraform force-unlock <lock_id>` is the proper command to manually release it. This preserves the integrity of the state file and avoids manual S3 or DynamoDB edits, which could corrupt the state or break the locking mechanism.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Edit the state file to remove the lock metadata.
Why it's wrong here
Directly editing the Terraform state file, even to remove lock metadata, is highly dangerous and strongly discouraged. The state file is a critical record of your infrastructure, and manual modifications can easily introduce syntax errors, corrupt the state, or lead to inconsistencies between your configuration and real-world resources. This can result in unexpected infrastructure changes, resource loss, or an inability to manage your infrastructure with Terraform.
- ✗
Run 'terraform init -reconfigure' to reset the backend and release the lock.
Why it's wrong here
Running `terraform init -reconfigure` is used to reinitialize the backend configuration, for example, when changing backend settings or moving to a new backend. This command specifically focuses on setting up the connection to the remote state storage and does not interact with active or stale state locks. Therefore, it will not release an existing state lock, as its purpose is entirely different from lock management.
- ✗
Delete the lock file from the S3 bucket manually.
Why it's wrong here
Manually deleting the lock file directly from the S3 bucket is an unsafe practice because it bypasses Terraform's internal state management and locking mechanisms. While it might remove the physical lock object, Terraform's internal state might not be aware of this manual intervention, potentially leading to race conditions or an inconsistent understanding of the lock status. The `terraform force-unlock` command is designed to handle this operation safely and atomically, ensuring consistency.
- ✓
Run 'terraform force-unlock <lock_id>' to remove the stale lock.
Why this is correct
The `terraform force-unlock <lock_id>` command is the correct and recommended method for releasing a stale state lock that was not automatically released after a failed or interrupted operation. This command safely interacts with the backend's locking mechanism, ensuring that the lock is properly removed and the state is accessible for subsequent operations. Requiring the `<lock_id>` adds a crucial layer of safety, preventing accidental unlocking of an active or incorrect lock.
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.