HashiCorp Terraform Associate (004) Question 157
Single answer6 Terraform state managementA team stores Terraform state remotely in an S3 backend with state locking enabled through DynamoDB. During a deployment, a network interruption occurs after Terraform acquires the lock. Subsequent runs now fail with an error indicating that the state is locked, even though no Terraform process is currently running. The team wants to safely resume work without risking state corruption. Which action should they take?
- A
Run terraform force-unlock with the lock ID shown in the error message after confirming no other Terraform operation is in progress
- B
Delete the terraform.tfstate file from S3 so Terraform can recreate it on the next apply
- C
Run terraform refresh to clear the stale lock before re-running terraform apply
- D
Disable state locking in the backend configuration and rerun terraform apply
Show answer and explanation
Correct answer: A
Explanation
Terraform state locking is a core safety feature in state management, especially when using shared remote backends. In backends such as S3 with DynamoDB locking, Terraform creates a lock to prevent concurrent operations from modifying the same state file. If a run exits unexpectedly, the lock can remain even though no process is still active. In that case, the recommended action is to verify that no other operation is running and then use terraform force-unlock with the specific lock ID. This restores access without deleting or bypassing state protections. HashiCorp documentation and best practices emphasize using remote state with locking for team workflows and avoiding manual deletion of state files or disabling locks except in carefully controlled circumstances.
- A. Correct.
Correct. If a lock is left behind because a Terraform operation terminated unexpectedly, Terraform provides the terraform force-unlock command to remove the lock manually. This should only be done after verifying that no other Terraform process is actively using the state. In a remote backend scenario such as S3 with DynamoDB locking, this is the appropriate recovery action to avoid concurrent writes while restoring access to the state.
- B. Incorrect.
Incorrect. Deleting the state file from S3 is dangerous and can cause Terraform to lose track of existing infrastructure, potentially leading to resource recreation, drift, or destructive changes. A stale lock does not mean the state file itself is invalid. The problem is with the lock record, not the stored state data.
- C. Incorrect.
Incorrect. terraform refresh updates state with real infrastructure data, but it does not remove a backend lock. In fact, refresh itself requires access to the state and would also be blocked by the existing lock. This option reflects a common misconception that refresh is a general repair tool for state issues.
- D. Incorrect.
Incorrect. Disabling locking to bypass the problem is unsafe because locking exists to prevent simultaneous state modification. Turning it off can expose the team to state corruption if another operation is actually in progress or if multiple users run Terraform at the same time. Best practice is to resolve the stale lock rather than bypass the protection mechanism.