TF-004 Use Terraform outside the core workflow Practice Question
A team uses an S3 backend with DynamoDB for state locking. They notice that sometimes terraform plan fails because the state is locked. What is the best practice to handle this in an automated pipeline?
⚠ Common exam trap
Candidates often assume increasing timeouts or disabling locking is acceptable for automation, but HashiCorp tests the understanding that state locking is a safety mechanism and the correct fix is to prevent concurrent access, not to bypass or extend the lock.
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
✓
Serialize pipeline runs to avoid concurrent execution
Serializing pipeline runs is the best practice to prevent concurrent Terraform operations from competing for the same state lock. When multiple pipeline jobs attempt to run `terraform plan` or `terraform apply` simultaneously, DynamoDB-based state locking ensures only one operation holds the lock at a time, causing the others to fail. By enforcing sequential execution (e.g., via CI/CD stage dependencies or a mutex), you avoid lock contention entirely without risking data corruption or bypassing safety mechanisms.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Serialize pipeline runs to avoid concurrent execution
Why this is correct
Serializing pipeline runs is the most effective and recommended approach to prevent state corruption when using a shared Terraform state backend. This strategy ensures that only one Terraform operation (e.g., plan or apply) can acquire the state lock and modify the state at any given time. By eliminating concurrent execution, it directly addresses the root cause of state locking conflicts and race conditions, maintaining the integrity of the remote state file.
- ✗
Use force-unlock before each plan
Why it's wrong here
Using `terraform force-unlock` before each plan is a highly risky practice and not a solution for managing concurrent operations. This command is intended for exceptional circumstances to release an orphaned lock, not as a routine step. Routinely forcing unlocks bypasses the critical state protection mechanism, potentially allowing multiple operations to modify the state simultaneously and leading to severe state corruption or data loss if another legitimate operation is actively holding the lock.
- ✗
Increase the lock timeout
Why it's wrong here
Increasing the lock timeout merely dictates how long Terraform will wait to acquire a lock before failing, rather than preventing concurrent runs altogether. While it might reduce transient failures in a highly contended environment, it does not stop multiple pipeline runs from attempting to acquire the lock simultaneously. The fundamental issue of concurrent execution persists, and operations will still block or eventually fail if the lock is held for extended periods, rather than being prevented from starting.
- ✗
Use -lock=false in the pipeline
Why it's wrong here
Using the `-lock=false` flag in a pipeline explicitly disables Terraform's state locking mechanism, which is extremely dangerous in a shared environment. This flag instructs Terraform to proceed with state operations without attempting to acquire or release a lock, completely negating the purpose of using a backend with state locking. Disabling locking guarantees state corruption if multiple operations run concurrently, as there is no mechanism to prevent simultaneous, conflicting writes to the remote state file.
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.