DOP-C02 Configuration Management and IaC Practice Question
A company uses Terraform to manage AWS infrastructure. They have a state file stored in an S3 bucket with DynamoDB locking. After a failed 'terraform apply', the state file is locked. The DevOps engineer tries to run 'terraform plan' but gets an error: 'Error acquiring the state lock'. What should the engineer do to resolve this issue?
⚠ Common exam trap
Many candidates assume DynamoDB locks have a TTL or that manual deletion is safe, but AWS DynamoDB does not enforce TTL on lock items by default, and Terraform's locking protocol requires the lock ID to be explicitly provided to prevent accidental release of another process's 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
✓
Run 'terraform force-unlock' with the lock ID
Terraform uses DynamoDB to implement state locking, and after a failed apply, the lock entry remains in the table. The `terraform force-unlock` command with the specific lock ID (obtained from the error message or via `terraform lock` commands) is the designed mechanism to manually release a stuck lock without corrupting the state file. This approach preserves the existing state and avoids data loss.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Manually delete the lock item from the DynamoDB table
Why it's wrong here
Manually deleting the lock item from the DynamoDB table is technically possible because Terraform stores lock metadata as a DynamoDB item, but it bypasses Terraform's safety mechanisms and can leave stale lock records or corrupt state consistency if the operation is in progress. The proper procedure is to use the CLI's `force-unlock` command, which validates the lock ID and safely clears the lock without risking accidental state deletion or concurrent operation conflicts.
- ✗
Wait for the lock to expire automatically
Why it's wrong here
Terraform state locks do not have a built-in Time-to-Live (TTL) mechanism; DynamoDB lock items persist indefinitely until explicitly released by the process that acquired them or removed via `force-unlock`. Waiting will only delay the team indefinitely and can block all subsequent `terraform plan` or `apply` operations, so this is not a viable resolution strategy.
- ✓
Run 'terraform force-unlock' with the lock ID
Why this is correct
`terraform force-unlock <LOCK_ID>` is the designed recovery mechanism for stale or stuck locks, and it directly interacts with the backend's locking system to remove the lock item while preserving the integrity of the state file. This command requires the exact lock ID from the error message and is safe when the previous operation is truly no longer running; it is the recommended alternative to manual DynamoDB edits or destructive state file actions.
- ✗
Delete the state file from S3 and re-run terraform init
Why it's wrong here
Deleting the state file from S3 and re-running `terraform init` is catastrophic because it permanently removes the only record of managed resources, making it impossible to reconcile or apply changes without losing all resource tracking. This action also does not clear the lock item in DynamoDB, so the lock would persist even after the state is gone, and it violates the principle of treating state as immutable data that must be managed with versioning and locking.
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 DOP-C02 question from scratch — 1,013 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 DOP-C02 practice question is part of Courseiva's free Amazon Web Services 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 DOP-C02 exam.