TF-004 Use Terraform outside the core workflow Practice Question
An operator runs `terraform apply` and receives an error that the state file is locked. What is the most likely cause?
⚠ Common exam trap
Candidates often confuse state locking with file permissions (Option D) or assume the error is due to a stale state (Option A), but The TF-003 exam specifically tests the understanding that locking is a concurrency control mechanism, not a permission or syntax issue.
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
✓
Another user is running a Terraform operation
Terraform uses a state locking mechanism (typically via a backend like S3 with DynamoDB, or Consul) to prevent concurrent operations from corrupting the state file. When another user or process is running a Terraform operation (e.g., `apply`, `plan`, `destroy`), the lock is held, and any subsequent `terraform apply` will fail with a 'state file is locked' error. This is a fundamental safety feature to ensure state consistency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The state file is outdated and needs refresh
Why it's wrong here
An outdated state file, while potentially leading to resource drift or unexpected plan results, does not inherently trigger a state lock error during `terraform apply`. Terraform automatically performs a refresh as part of the `plan` phase before `apply`, so an explicit `terraform refresh` is rarely needed. If resources have been manually modified outside Terraform, the `apply` might propose incorrect changes or fail due to resource conflicts, but not specifically a state lock.
- ✗
The configuration has a syntax error
Why it's wrong here
A syntax error in the Terraform configuration files would typically be identified much earlier in the workflow. Commands like `terraform validate` or `terraform plan` are designed to parse the configuration and report such errors before attempting any state operations or resource provisioning. Therefore, a syntax error would prevent the `apply` command from even reaching the point where a state lock could be contended, instead failing with a parsing or validation error.
- ✓
Another user is running a Terraform operation
Why this is correct
Terraform state locking is a critical mechanism designed to prevent data corruption when multiple operators attempt to modify the state file concurrently. When one user initiates a `terraform apply` or other state-modifying operation, Terraform attempts to acquire an exclusive lock on the state. If another user is already holding that lock, the subsequent operation will fail with a state lock error, indicating that the state is currently in use and preventing simultaneous, conflicting updates.
- ✗
The user lacks write permissions to the state file
Why it's wrong here
If the user executing `terraform apply` lacks the necessary write permissions to the backend where the state file is stored, Terraform would typically return a `permission denied` error or a similar access control failure. This is distinct from a state lock error, which signifies that the state *can* be accessed but is currently reserved by another ongoing operation. A permissions issue indicates an inability to interact with the state backend at all due to insufficient authorization.
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.