HashiCorp Terraform Associate (004) Question 165
Single answer6b Describe state lockingA team stores Terraform state remotely in Amazon S3 and uses a DynamoDB table for state locking. During a deployment, one engineer starts terraform apply, and a second engineer immediately runs another terraform apply against the same workspace from a different machine. The second command fails because the state is locked. What is the best explanation of why this happens and how the team should respond?
- A
Terraform uses the lock to prevent concurrent operations that could corrupt or overwrite state; the second engineer should wait for the first operation to finish or investigate a stale lock before forcing unlock.
- B
Terraform locks only provider plugins, so the second engineer can safely rerun the command with
-lock=falseto bypass the protection without risk. - C
The lock indicates that the S3 backend is unavailable, so the team should migrate the state to a local backend before retrying the apply.
- D
State locking occurs only during
terraform plan, so the error means the second engineer is using a different Terraform version than the first engineer.
Show answer and explanation
Correct answer: A
Explanation
State locking is a safety mechanism that prevents concurrent operations against the same Terraform state. In collaborative environments, this is critical because two simultaneous writes could cause lost updates, inconsistent resource tracking, or corrupted state. Backends that support locking, such as the S3 backend when paired with the appropriate locking mechanism, allow Terraform to serialize state-changing operations. Best practice is to use remote state with locking enabled for team use, wait for legitimate operations to complete, and use terraform force-unlock only after confirming the lock is stale, such as after a crashed or interrupted run. This aligns with Terraform documentation on state locking and backend behavior, which emphasizes protecting shared state during write operations.
- A. Correct.
Correct. State locking is designed to prevent multiple Terraform operations from modifying the same state at the same time. With supported backends, Terraform acquires a lock before operations that could write state, such as
apply, to avoid race conditions and state corruption. The right response is usually to wait until the current operation completes. If a lock remains after an interrupted run, the team can investigate and, if appropriate, useterraform force-unlockcarefully. - B. Incorrect.
Incorrect. This reflects a common misconception. Terraform state locking protects the state file, not provider plugins. Although Terraform has a
-lock=falseflag for some commands, bypassing locking on shared state is risky and is not the safe default response in a team environment because concurrent writes can damage state consistency. - C. Incorrect.
Incorrect. A lock error does not mean the S3 backend itself is unavailable. In this scenario, the backend is functioning as intended by coordinating access through the lock mechanism. Moving state to a local backend would remove collaboration safeguards and would be a step backward for team workflows.
- D. Incorrect.
Incorrect. State locking is not limited to
terraform plan, and lock errors are not an indicator of Terraform version mismatch. Locks are relevant for operations that may write state, especiallyapply, and in many backends planning can also involve locking depending on command behavior and backend support.