TF-004 Understand IaC concepts Practice Question
A company uses Terraform to manage infrastructure on AWS. They have a configuration that creates an S3 bucket and a DynamoDB table for state locking. The team notices that sometimes when two members run terraform apply simultaneously, they get a state locking error. However, they want to allow concurrent operations on different workspaces. What is the best approach?
⚠ Common exam trap
HashiCorp often tests the misconception that DynamoDB locking is global across all workspaces, when in fact the lock is scoped to the specific state file path, which includes the workspace name.
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
✓
Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.
Terraform natively supports per-workspace state files, and when using a remote backend like S3 with DynamoDB for state locking, each workspace's state file is stored at a distinct path in S3. The DynamoDB lock entry is tied to the specific state file path via the LockID, so concurrent operations on different workspaces acquire separate locks and do not conflict. This setup allows multiple team members to run terraform apply simultaneously as long as they are working in different workspaces.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the DynamoDB table and use local state files to avoid locking issues.
Why it's wrong here
Removing the DynamoDB table eliminates the crucial remote state locking mechanism, which is essential for preventing concurrent modifications to the Terraform state in a team environment. Relying solely on local state files makes collaboration impossible, as it creates a high risk of state corruption and overwrites when multiple team members attempt to apply changes simultaneously. This approach severely undermines the integrity and reliability of infrastructure management.
- ✗
Configure all team members to use the same workspace so that only one person can apply at a time.
Why it's wrong here
Configuring all team members to use a single workspace fundamentally defeats the purpose of Terraform workspaces, which are designed to provide isolated environments for different stages or features. This approach severely limits team productivity by enforcing serial operations, as only one person can safely apply changes at any given time. It also eliminates the ability to manage distinct infrastructure configurations for development, staging, and production environments within the same backend.
- ✗
Keep the current setup because the error is harmless and users can retry.
Why it's wrong here
While some transient errors might resolve with a retry, consistently encountering state locking issues indicates a fundamental problem with concurrent operations or backend configuration that should be addressed. Accepting repeated errors and requiring manual retries introduces significant operational friction and diminishes the developer experience. A robust Terraform setup aims for predictable and reliable execution, not one that frequently demands user intervention for expected issues.
- ✓
Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.
Why this is correct
Terraform workspaces inherently create separate state files within the configured remote backend, such as an S3 bucket. Each of these distinct state files is then protected by its own unique lock entry in the DynamoDB table, preventing concurrent modifications to that specific workspace's state. This design allows multiple team members to concurrently apply changes to different workspaces without conflict, leveraging the robust locking mechanisms provided by the remote backend.
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
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.