LEARN. PRACTICE. GROW.Build observable contention
The workshop prepares two working directories with a local backend pointing to the same absolute state path. A terraform_data resource is replaced only in the temporary environment. During creation, a local Python helper writes a marker and waits for explicit release, with a maximum deadline. That marker establishes when the first run is active. Only then does the coordinator start competing commands. Contention therefore does not depend on accidentally hitting a short timing window. The provisioner serves solely to control the experiment; it is not a recommendation to configure production through scripts.
Identify the holder before intervening
While the first apply is active, lock information contains an identifier, version and operation type. The second directory attempts plan and receives an acquisition error; the reported identifier matches the observed lock. State bytes remain identical between the beginning and end of that rejected attempt. In a fictional incident, associate these facts with the runner and change owner. A disconnected terminal or unavailable person does not establish that the process ended. The experiment directly checks the process and marker; production evidence must come from the actual runner.
The deadline belongs to the waiter
A new attempt uses a one-second lock-timeout and ends without acquiring the lock. The script verifies that the first process remains active and that nobody requested its release. The timeout bounds the second command’s wait; it neither cancels holder work nor automatically makes the lock orphaned. When managing a short window, distinguish three decisions: wait within the permitted limit, defer the operation or investigate a run that appears stalled. Choosing among them requires context about the current change. Timing on this computer does not constitute a remote backend latency commitment.
Wait and observe state again
The coordinator starts another plan with a longer wait and confirms the lock-acquisition message while both processes remain active. It then creates the release marker. The first apply finishes and the waiting plan proceeds. The resulting plan contains no-op because it reads configuration already satisfied by the holder. This sequence is not a complete operational queue: it tests neither fairness among multiple contenders nor change priorities. It establishes only that this command waited and planned after release. The team should interpret the new result rather than assume earlier intent still requires a change.
Reading a file is not obtaining a final view
While apply is paused in the helper, the coordinator can directly read the state file using the same operating-system identity. At that controlled replacement point, the recorded resource list is empty although the process remains active. This does not establish that the operation ended or that no effects are in progress. It also shows that the observed lock does not prevent arbitrary byte reads by a process with file access. Permissions and confidentiality require their own controls. The experiment tests no other user, ACLs, remote service or snapshot guarantee during a write.
Close the investigation without forcing concurrency
After release, both directories read the same resource identifier and completed value. Temporary lock information disappears and owned processes exit. These are concrete workshop closure criteria, not cloud-service health evidence. In an actual incident, add functional reconciliation and record who may start the next operation. Documentation limits force-unlock to one’s own lock when automatic release failed; it is not the normal response to an active run. The exercise uses neither force-unlock nor lock=false and simulates neither abrupt death nor power loss.
# Run the isolated workshop with the exact supported CLI.
python3 content/labs/terraform-coordination/run.py /absolute/terraform /tmp/new-coordination-evidence.json
# The workshop coordinates its own processes; do not improvise on shared state.
# A competing plan uses a bounded acquisition wait:
terraform plan -input=false -lock-timeout=15s
# Inspect the holder and current target before choosing a retry.
Two directories point to the same state; the second plan is blocked while the first apply remains active.
Common pitfalls
Treating a timeout as holder cancellation; confusing a directory with separate state; using a lock as confidentiality evidence.
Related topics: Saved plans and approval · Recovery after partial execution
A lock coordinates operations on one state. Operational decisions require knowing the holder, target and work still in progress.
Reference: State locking and force-unlock boundaries · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed