TF-004 Implement and maintain state Practice Question
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?
⚠ Common exam trap
HashiCorp often tests the distinction between a legitimate lock held by another user (Option B) and a stale lock from a crashed process (Option A), where candidates mistakenly think any lock error means someone else is actively working.
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
✓
A previous terraform apply command was interrupted or crashed, leaving a stale lock.
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).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A previous terraform apply command was interrupted or crashed, leaving a stale lock.
Why this is correct
When a `terraform apply` command is interrupted unexpectedly, such as due to a process crash, network failure, or manual termination, Terraform might fail to release the state lock it acquired at the beginning of the operation. This leaves a "stale" lock entry in the backend, preventing any subsequent Terraform commands from acquiring the necessary lock to modify the state. Terraform's state locking mechanism is designed to prevent concurrent modifications, so a persistent stale lock effectively blocks all further state-modifying operations until it is manually released, directly causing an "Error acquiring state lock" message.
- ✗
Another team member is actively running terraform apply on the same state.
Why it's wrong here
If another team member is actively running a `terraform apply` command on the same state, Terraform will legitimately acquire a state lock to prevent concurrent modifications. While this would temporarily block other operations from acquiring the lock, the lock would be released automatically upon the successful completion or graceful failure of their command. This scenario represents a temporary, active lock that resolves itself, rather than a persistent "stale" lock that indicates an underlying issue with the lock mechanism itself or requires manual intervention.
- ✗
The backend configuration was changed without running terraform init.
Why it's wrong here
Changing the backend configuration (e.g., modifying the S3 bucket name, key path, or region) without subsequently running `terraform init` would lead to an error indicating that Terraform cannot find or properly access the configured state. This typically manifests as an error about the backend not being initialized, an inability to read the state file, or a configuration mismatch. Terraform would not even attempt to acquire a state lock if it doesn't know where the state is or how to correctly access its backend, thus this would not cause a lock acquisition error.
- ✗
The state file contains resources that no longer exist in the cloud provider.
Why it's wrong here
When the Terraform state file lists resources that have been manually deleted, modified, or provisioned outside of Terraform's management (a condition known as "state drift"), it signifies that the state is out of sync with the actual infrastructure. While state drift is a significant operational issue that can lead to unexpected changes or errors during `terraform apply` or `terraform plan`, it is a data consistency problem. It does not directly cause an error related to acquiring a state lock, which is a concurrency control mechanism.
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
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.