DOP-C02 Configuration Management and IaC Practice Question
A company uses Terraform to manage a multi-account AWS environment. The Terraform state files are stored in an S3 bucket with DynamoDB locking. Recently, a DevOps engineer ran 'terraform apply' from a CI/CD pipeline, and it failed with the error: 'Error acquiring the state lock. Lock ID: "abc123". Possible causes: Another process has the lock; or a previous process crashed.' The engineer checks DynamoDB and sees that the lock item exists but there is no active Terraform process. The engineer needs to proceed with the deployment urgently. What should the engineer do?
⚠ Common exam trap
DOP-C02 often tests whether candidates know the safe, Terraform-native way to clear a stale lock versus dangerous manual deletion or state manipulation.
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
✓
Use the 'terraform force-unlock' command with the lock ID to remove the lock.
The correct action is to use 'terraform force-unlock' with the lock ID to remove the stale lock. This command is specifically designed to safely release a lock when no active Terraform process holds it, allowing the deployment to proceed. It ensures the lock is removed in a controlled manner, preserving 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.
- ✓
Use the 'terraform force-unlock' command with the lock ID to remove the lock.
Why this is correct
Terraform's `force-unlock` command is the sanctioned recovery mechanism for a stale lock. Run `terraform force-unlock <LOCK_ID>` from the CLI using the lock ID printed in the error message (or found in the DynamoDB `LockID` item); this removes the lock item via a properly logged API call. It is safe only when you confirm no other `terraform` process is actively applying or planning against that state, because it overrides mutual exclusion.
- ✗
Wait for the lock to expire automatically.
Why it's wrong here
DynamoDB-backed state locks contain no TTL or expiry attribute—they persist indefinitely until a successful `terraform apply` releases them or an operator explicitly removes them. The conditional write Terraform uses to acquire the lock will keep failing while the lock record exists, so waiting has no effect. A lock is never automatically released after a timeout; if the original process crashed, the lock remains orphaned and requires manual intervention.
- ✗
Delete the state file from S3 and recreate it from the last backup.
Why it's wrong here
Deleting the S3 state object restores the workspace to a backup but does not remove the DynamoDB lock record, so the next run would still be blocked. More importantly, the current state file is the source of truth for existing infrastructure; deleting it (even for a restore) risks losing recent resource metadata, causing Terraform to plan the destruction/recreation of resources. This is an unnecessarily destructive workaround that compounds the original locking problem.
- ✗
Manually delete the lock item from DynamoDB using the AWS Console.
Why it's wrong here
While deleting the item from the `terraform-lock` DynamoDB table can clear a stale lock, doing it through the AWS Console bypasses Terraform's tracking and audit trail. The CLI records the unlock action in the local log and validates that you intend to break the lock; a manual delete gives no such guard and is easy to do while a legitimate operation is actually running, potentially corrupting state. Use `force-unlock` as the supported path unless the table itself is unavailable.
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
One of 1,298 original DOP-C02 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.