HashiCorp Terraform Associate (004) Question 166
Single answer6b Describe state lockingA team stores Terraform state for a shared AWS environment in a remote backend and has started seeing occasional failures during terraform apply in their CI pipeline. One pipeline run reports that the state is locked, while another engineer says they may have canceled a previous apply midway through. The team wants to prevent concurrent state modifications but also recover safely when a lock is left behind. Which action is the best next step?
- A
Run
terraform force-unlockonly after confirming no other Terraform operation is still using the state lock - B
Delete the remote state file and rerun
terraform applyso Terraform can recreate the lock metadata - C
Disable state locking by passing
-lock=falsein CI so multiple applies can complete without waiting - D
Run
terraform refreshlocally to clear the lock before restarting the pipeline
Show answer and explanation
Correct answer: A
Explanation
Terraform state locking is used to prevent simultaneous operations from modifying the same state, which helps avoid corruption and inconsistent infrastructure tracking. In shared environments, remote backends commonly provide locking support so only one Terraform operation can hold the lock at a time. If an operation is interrupted, a stale lock can remain. The correct response is not to disable locking or delete state, but to confirm that no active operation is still running and then remove the orphaned lock with terraform force-unlock. HashiCorp documentation and best practices emphasize keeping locking enabled for collaborative workflows and using manual unlock cautiously, since unlocking an active operation can lead to concurrent writes and state damage.
- A. Correct.
Correct. State locking exists to prevent concurrent operations from writing to the same state at the same time. If a previous operation crashed or was interrupted, the lock can remain and block future runs. The safe recovery action is to verify that no Terraform process is currently operating on that state and then use
terraform force-unlockto remove the stale lock. This matches Terraform best practice: only manually unlock when you are certain the lock is orphaned. - B. Incorrect.
Incorrect. Deleting the remote state file is dangerous and unrelated to properly clearing a lock. The state file contains Terraform's record of managed infrastructure, and deleting it can cause drift, resource recreation, or loss of tracking. Locks are meant to protect the state, not be fixed by removing the state itself.
- C. Incorrect.
Incorrect. Using
-lock=falsebypasses Terraform's concurrency protection and increases the risk of state corruption when multiple users or pipelines operate on the same workspace. This is a common but unsafe workaround. State locking should generally remain enabled for shared state, especially in team and CI/CD environments. - D. Incorrect.
Incorrect.
terraform refreshdoes not clear a backend lock. A lock is managed by the backend during state operations, and refresh is not a lock recovery mechanism. Someone might choose this option because refresh reads real infrastructure state, but it does not remove stale locks.