HashiCorp Terraform Associate (004) Question 168
Single answer6b Describe state lockingA team stores Terraform state remotely in Amazon S3 and uses a DynamoDB table for state locking. During a production deployment, one engineer starts terraform apply and leaves their laptop disconnected before the command finishes. A second engineer then tries to run terraform apply against the same workspace and receives an error that the state is locked. The team has confirmed no Terraform operation is currently running. What is the most appropriate next step to safely proceed?
- A
Run
terraform force-unlock <LOCK_ID>after verifying the original operation is no longer in progress - B
Delete the
terraform.tfstatefile from the S3 bucket so Terraform can recreate it on the next apply - C
Re-run
terraform applywith-lock=falseto bypass the stale lock and avoid blocking the deployment - D
Run
terraform refreshfirst, because refresh automatically clears stale state locks in DynamoDB
Show answer and explanation
Correct answer: A
Explanation
Terraform state locking is designed to prevent multiple users or processes from modifying the same state file at the same time. In shared environments, this is a critical protection against state corruption. With an S3 backend, Terraform can use a DynamoDB table to coordinate locks. If an operation is interrupted, the lock can remain behind as a stale lock. In that case, after confirming no Terraform run is still active, the correct action is to remove the stale lock with terraform force-unlock. Best practice is to investigate first, because unlocking while another operation is genuinely running could allow concurrent state changes. HashiCorp documentation for backends and the force-unlock command emphasizes that state locking protects shared state and that force-unlock should be used carefully when a lock persists after an abnormal termination.
- A. Correct.
Correct. State locking prevents concurrent operations from corrupting state. If a lock remains after an interrupted run and you have verified no active Terraform process still owns it, the appropriate remediation is to use
terraform force-unlock <LOCK_ID>. This removes the stale lock so a new operation can safely acquire the lock and proceed. The key safety requirement is confirming the original operation is truly no longer running before unlocking. - B. Incorrect.
Incorrect. Deleting the state file is dangerous and unnecessary. The state file contains Terraform's record of managed infrastructure. Removing it from S3 would not be a safe way to clear a lock and could lead to orphaned resources, drift, or attempts to recreate existing infrastructure. Lock metadata and state data serve different purposes.
- C. Incorrect.
Incorrect. Using
-lock=falsedisables state locking for that command, which can allow concurrent writes to state and risk corruption. This flag is not the recommended response to a stale lock in a shared environment. It is a common misconception to treat locking as optional during team operations; in practice, bypassing locks should be avoided except in very limited, controlled situations. - D. Incorrect.
Incorrect.
terraform refreshdoes not exist to clear locks automatically. Terraform commands that access state still respect locking behavior, and a stale lock must be handled explicitly. Choosing this option reflects a misunderstanding of both the purpose of refresh and how backend locking works.