TF-004 Understand IaC concepts Practice Question
A team of five engineers uses Terraform with a remote backend in AWS S3 with DynamoDB state locking. One engineer runs 'terraform apply' but it hangs at 'Acquiring state lock'. What is the most likely cause?
⚠ Common exam trap
HashiCorp often tests the distinction between a hang (lock contention) and a hard failure (access denied, region mismatch, or backend misconfiguration), so the trap here is that candidates may confuse a permission or configuration error with a lock acquisition timeout.
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 engineer has an active lock from a previous run that was not released.
The most likely cause is that another engineer has an active lock from a previous run that was not released. Terraform uses DynamoDB state locking to prevent concurrent modifications to the state file. When `terraform apply` hangs at 'Acquiring state lock', it indicates that the lock item in the DynamoDB table is still present, meaning a prior operation either crashed, was interrupted, or the lock was not explicitly released via `force-unlock`.
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 engineer has an active lock from a previous run that was not released.
Why this is correct
When Terraform attempts to acquire a state lock, it checks for an existing lock held by another operation on the remote backend. If a lock is found, Terraform will wait for a configurable timeout period, continuously retrying to acquire the lock. This mechanism prevents concurrent state modifications, ensuring state consistency in collaborative environments. An unreleased lock from a previous, possibly failed, run will cause subsequent operations to indefinitely wait or timeout until the lock is manually released or expires.
- ✗
The S3 bucket policy denies the request.
Why it's wrong here
An S3 bucket policy defines granular permissions for accessing the bucket and its objects, including the Terraform state file. If the policy denies the Terraform user's or role's request to read or write state, Terraform would immediately receive an 'Access Denied' error from AWS. This is a direct authorization failure, indicating insufficient permissions, rather than a state where Terraform waits for an underlying resource to become available or a lock to be released.
- ✗
A recent 'terraform init' was run without the proper backend configuration.
Why it's wrong here
Running `terraform init` without the correct backend configuration means Terraform cannot properly initialize the remote state storage. This would manifest as an immediate configuration error during the `init` command itself, or subsequent commands would fail because the backend is not configured. Terraform would be unable to even attempt state operations, rather than successfully connecting to the backend and then waiting for a lock or resource.
- ✗
The DynamoDB table is in a different AWS region.
Why it's wrong here
DynamoDB is commonly used by Terraform for state locking, requiring the table to be in the same AWS region as specified in the backend configuration. If the configured region for the DynamoDB table does not match its actual region, Terraform will encounter a region mismatch error when attempting to access the table. This is a fundamental connectivity and configuration issue, preventing the lock mechanism from functioning at all, not a scenario where Terraform waits for an active lock to clear.
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.