TF-004 Use the core Terraform workflow Practice Question
An organization uses a remote backend (S3) with DynamoDB for state locking. A developer runs `terraform plan` and gets the error: "Error acquiring the state lock: ConditionalCheckFailedException". What is the most likely cause?
⚠ Common exam trap
HashiCorp often tests the distinction between DynamoDB-specific errors (ConditionalCheckFailedException) versus S3 or configuration errors, trapping candidates who confuse state locking failures with backend connectivity issues.
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
✓
Another Terraform process is currently holding the state lock
The error 'ConditionalCheckFailedException' occurs when Terraform attempts to acquire a lock in DynamoDB but the conditional write fails because the lock item already exists with a different lock ID. This indicates another Terraform process (or a stale lock) is currently holding the state lock, preventing concurrent operations to protect state integrity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Another Terraform process is currently holding the state lock
Why this is correct
When Terraform attempts to acquire a state lock using DynamoDB, it performs a conditional write operation to a specific item in the lock table. A "conditional check fails" error specifically indicates that this write could not proceed because the expected conditions were not met, typically meaning another process has already written a lock item or the version ID does not match. This mechanism prevents concurrent state modifications, signifying that another Terraform process is actively holding the lock to protect state integrity and avoid race conditions.
- ✗
The S3 bucket does not exist
Why it's wrong here
If the specified S3 bucket for storing the remote state did not exist, Terraform would encounter a distinct error message directly related to S3 API failures, such as "NoSuchBucket" or "InvalidBucketName". This type of error occurs during the initial backend configuration or when Terraform attempts to access the state file, clearly indicating a resource availability issue rather than a state locking conflict within an existing resource.
- ✗
The DynamoDB table is not yet created
Why it's wrong here
A missing DynamoDB table, which is configured for state locking, would result in a "ResourceNotFoundException" or a similar error from the AWS API. Terraform would fail to initialize the backend or acquire a lock because the target resource for the lock operation is absent. This is fundamentally different from a conditional check failure, which implies the table exists but the specific write condition for the lock was not met.
- ✗
The Terraform version is incompatible with the backend
Why it's wrong here
Terraform version incompatibility with the backend typically manifests as errors related to state file format parsing, provider API mismatches, or unexpected configuration schema issues. These errors would usually occur during `terraform init` when attempting to read or interpret the state, or during `plan`/`apply` if the state cannot be properly deserialized. Such issues are distinct from a specific DynamoDB conditional write failure related to state locking, which points to a concurrent operation.
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.