Two pipeline jobs for the same environment start terraform apply within seconds of each other. Both use an S3 backend configured with use_lockfile = true, and neither passes -lock=false. What happens to the job that starts second?
Select an answer to reveal the explanation.
Short Explanation
Think of the state lock like the single key to a server room: whoever grabs it first works, and the next person can't just walk in. Your second job hits a locked door and stops with an error, unless you told it to keep knocking for a while with -lock-timeout. The trap is assuming Terraform queues or merges runs for you; it just refuses to go on.
Full Explanation
When the configured backend supports locking, Terraform takes a lock automatically for every operation that could write state, and if acquiring that lock fails it does not continue. With the S3 backend, setting use_lockfile to true enables locking through a lock object stored next to the state object. The second apply therefore fails while the first holds the lock, and the error includes the lock information, such as the lock ID, who holds it and when it was taken. The -lock-timeout option changes only how long Terraform retries before giving up; it does not create an unlimited queue. The idea that both jobs run and the last writer wins describes exactly the corruption scenario locking exists to prevent; that only becomes possible if someone disables locking with -lock=false or uses a backend that cannot lock. Terraform has no mechanism that merges one run's plan into another run, because each plan is computed against a specific state snapshot. Indefinite queuing is a feature of an orchestrator such as HCP Terraform's run queue, not of the CLI lock itself. Exam caveat: locking prevents simultaneous writes but does not serialize plans, so a plan made before another apply can still become stale. Operational check: serialize applies per environment in the pipeline and set a modest -lock-timeout so short overlaps retry instead of failing.