Two engineers start terraform apply against the same production configuration at almost the same moment. One uses a remote backend that supports locking; another team runs the same configuration as an HCP Terraform workspace. What prevents conflicting writes to state in each case?
Select an answer to reveal the explanation.
Short Explanation
Think of the state lock as a talking stick: whoever holds it writes, and you wait your turn. HCP Terraform goes one better and lines runs up in a queue for each workspace, so they never collide.
Full Explanation
For backends that support locking, Terraform acquires a lock before any operation that could write state, and a second operation that cannot obtain the lock waits or fails with lock details, depending on the lock timeout, until the first finishes and releases it. This serializes writers and prevents a corrupted or interleaved state. In HCP Terraform, each workspace processes runs one at a time in the order they were queued, so two triggered applies never execute concurrently against the same workspace state. Terraform performs no merging of concurrent state changes; state is a single snapshot, which is exactly why locking exists. Silent last-writer-wins overwriting is the failure that locking prevents, and manual coordination is not the mechanism Terraform relies on. Concurrent writes are blocked at the time of the operation, not detected later as drift; drift describes differences between real infrastructure and state, not between two runs. Exam caveat: force-unlock is only for releasing a lock left behind by a crashed process, after confirming no operation still holds it, and it is not a way to run applies concurrently. Operational check: start a plan, attempt a second one against the same state, and confirm the second reports that the state is locked, naming the holder.