TF-004 Understand Terraform basics Practice Question
A company uses Terraform to manage infrastructure across dev, staging, and production environments. They use Terraform workspaces to separate state files. The backend is configured with an S3 bucket for state storage and a DynamoDB table for state locking. Recently, the team has grown from 2 to 10 developers, and they frequently encounter the error: 'Error acquiring the state lock' when running terraform apply in quick succession. The error message includes: 'Lock Info: ID: ... Operation: Apply. Who: user@company.com. Version: 1.0.0. Created: ...' The error occurs intermittently, especially during peak deployment times. The DynamoDB table is configured with 5 read and 5 write capacity units. The team's current workflow involves multiple developers running apply on different workspaces simultaneously. Which course of action should the team take to minimize state locking errors?
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
✓
Increase the DynamoDB table's write capacity units to a higher value.
Increasing DynamoDB write capacity reduces contention and lock acquisition failures during concurrent applies. Option D (implementing a pre-apply hook) is not standard and could add complexity. Options A and C disable or bypass locking, which is dangerous.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable state locking to eliminate the error.
Why it's wrong here
Disabling state locking entirely removes the critical safeguard against concurrent modifications to the Terraform state file. Without this protection, multiple `terraform apply` operations could simultaneously attempt to write to the same state, leading to race conditions and data corruption. This would inevitably result in an inconsistent and unreliable record of the infrastructure, making future operations unpredictable and potentially destructive to the managed resources.
- ✓
Increase the DynamoDB table's write capacity units to a higher value.
Why this is correct
Terraform's S3 backend utilizes a DynamoDB table for state locking, where a lock is acquired by writing a unique item to this table. Insufficient write capacity units (WCUs) on the DynamoDB table can cause these lock acquisition attempts to be throttled or fail, especially under high concurrency from multiple developers. Increasing the WCUs ensures that DynamoDB can handle the required throughput for lock writes and updates, thereby reducing throttling errors and allowing successful lock acquisition.
- ✗
Use a different backend that does not support locking, such as local state.
Why it's wrong here
Using a local state backend means the state file resides on the individual developer's machine, completely bypassing any shared locking mechanism. This makes it impossible for a team to coordinate operations, as concurrent `terraform apply` commands from different developers would operate on independent, unmanaged state files. This approach inevitably leads to infrastructure drift and potential overwrites, as each developer's view of the infrastructure would be inconsistent and not managed by a central source of truth.
- ✗
Implement a pre-apply hook that checks if the state is already locked and waits.
Why it's wrong here
A pre-apply hook that checks for a lock and waits does not address the root cause: insufficient DynamoDB write capacity units (5) causing lock contention under concurrent apply operations from 10 developers. The hook merely introduces a polling delay, but the lock acquisition itself still fails when write capacity is exhausted. This approach is tempting because it mimics retry logic used in CI/CD pipelines to handle transient network failures, where waiting for a lock to release is effective when the bottleneck is sequential execution, not throughput capacity.
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.