TF-004 Use Terraform outside the core workflow Practice Question
A DevOps team manages infrastructure for a large e-commerce platform using Terraform with a remote backend in an S3 bucket with DynamoDB state locking. Recently, a team member ran `terraform apply` from their local machine but the command failed with the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. The state file is not locked according to the DynamoDB table. After investigation, the team finds that the DynamoDB table has a TTL attribute enabled on the 'LockID' field, and old lock records are automatically deleted after a few minutes. The team suspects that another engineer's `terraform plan` process from a CI/CD pipeline might have created a lock that was subsequently deleted by TTL before it was released, causing the conflict. Which action should the team take to prevent this issue from recurring?
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
✓
Disable the TTL attribute on the DynamoDB table that stores lock information.
The error occurs because the DynamoDB table has a TTL attribute that automatically deletes lock records before the lock is released. Disabling TTL on the DynamoDB table ensures lock records persist until the lock is intentionally released, preventing false lock conflicts. Option A is incorrect because local state eliminates locking and central management. Option C is incorrect because increasing TTL only delays deletion but does not guarantee the lock won't be deleted during a long-running operation. Option D is incorrect because force-unlock is a manual recovery step, not a preventive measure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch to using local state files to avoid the locking issue entirely.
Why it's wrong here
Switching to local state files is not a viable solution for a DevOps team managing infrastructure, especially in a large e-commerce environment. Local state files lack any form of concurrent access control or locking mechanism, making them highly susceptible to race conditions and state corruption when multiple operators apply changes simultaneously. This approach eliminates the benefits of shared state and introduces significant risks of overwriting changes and diverging infrastructure configurations, leading to operational instability.
- ✓
Disable the TTL attribute on the DynamoDB table that stores lock information.
Why this is correct
Disabling the Time-To-Live (TTL) attribute on the DynamoDB table used for Terraform state locking is the correct solution. TTL automatically deletes items after a specified period, which can prematurely remove an active lock if a `terraform apply` operation takes longer than the TTL duration. This premature deletion would allow another concurrent operation to acquire a lock, leading to potential state corruption or resource conflicts. Ensuring locks persist until explicitly released by Terraform prevents such race conditions.
- ✗
Increase the TTL value to 24 hours to ensure locks are not deleted during normal operations.
Why it's wrong here
Increasing the TTL value to 24 hours is merely a temporary workaround and does not fundamentally resolve the issue of premature lock deletion. While a longer TTL reduces the *probability* of a lock expiring during a typical `terraform apply` run, it does not eliminate the risk entirely. Unforeseen delays, complex deployments, or long-running operations could still exceed even a 24-hour TTL, leading to the same state corruption risks that a shorter TTL presents. A robust locking mechanism should not rely on arbitrary time limits for active locks.
- ✗
Use `terraform force-unlock` before each `terraform apply` to clear any stale locks.
Why it's wrong here
Using `terraform force-unlock` before every `terraform apply` is an inappropriate and dangerous operational practice. `force-unlock` is an emergency command designed for manual intervention to release a genuinely stale or orphaned lock, typically after a crash or network interruption. Routinely forcing unlocks bypasses the critical state locking mechanism, allowing concurrent operations to proceed without protection, which inevitably leads to state corruption and infrastructure inconsistencies. It should only be used with extreme caution and verification that no other operation is active.
Visual reference
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.