TF-004 Use Terraform outside the core workflow Practice Question
A team using a remote S3 backend with DynamoDB locking is experiencing frequent 'Error acquiring the state lock' messages in their CI/CD pipeline. The pipeline runs multiple concurrent jobs for different workspaces. What is the most likely cause and solution?
⚠ Common exam trap
HashiCorp often tests the misconception that DynamoDB capacity or S3 versioning are the root cause of lock errors, when the real issue is workspace-level contention in concurrent pipelines.
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
✓
The same workspace is being used for concurrent runs; use separate workspaces per environment.
The error 'Error acquiring the state lock' occurs when Terraform cannot obtain a lock on the state file for a specific workspace. In this scenario, the pipeline runs multiple concurrent jobs for different workspaces, but if the same workspace is inadvertently used across concurrent runs, Terraform's DynamoDB-based locking mechanism will prevent simultaneous access to that workspace's state. The solution is to ensure each environment (e.g., dev, staging, prod) uses a separate workspace, avoiding lock contention. Option B correctly identifies this as the most likely cause and solution.
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 DynamoDB table lacks sufficient read/write capacity; increase it.
Why it's wrong here
Terraform's state locking with DynamoDB primarily involves low-volume, atomic operations to acquire and release a lock. While insufficient capacity *could* theoretically cause issues, DynamoDB is highly optimized for such operations, and lock timeouts are almost always due to another process already holding the lock, not the database failing to process the lock request itself. Increasing capacity would not resolve the underlying contention.
- ✓
The same workspace is being used for concurrent runs; use separate workspaces per environment.
Why this is correct
Terraform workspaces provide isolated state files and, crucially, independent state locks within the same backend configuration. When multiple concurrent `terraform apply` or `terraform plan` operations target the *same* workspace, only one can acquire the state lock at a time, leading to subsequent runs timing out while waiting for the lock to be released. Using distinct workspaces for different environments or concurrent operations ensures each run attempts to acquire a separate lock, preventing contention.
- ✗
The pipeline is running too many jobs; increase the lock wait time.
Why it's wrong here
Increasing the lock wait time merely extends the period a Terraform operation will wait before giving up on acquiring a state lock. This does not resolve the fundamental issue of multiple concurrent operations attempting to modify the same state. While it might reduce *some* transient timeouts, it primarily delays the inevitable failure when true contention exists, potentially tying up pipeline resources for longer without successful completion. The root cause of contention remains unaddressed.
- ✗
The S3 bucket is not versioned; enable versioning.
Why it's wrong here
S3 bucket versioning is critical for maintaining a complete history of Terraform state file changes, enabling rollbacks to previous states and protecting against accidental deletions or corruptions. However, versioning solely pertains to the storage and retrieval of state file objects. It has no direct impact on Terraform's state locking mechanism, which is handled by a separate service like DynamoDB to prevent concurrent modifications.
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 — 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 →
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.