State, Locking and Drift

Why this matters

Two engineers apply at once from laptops with local state files. Each state knows only its own run; resources get duplicated, adopted or orphaned, and the next plan proposes to destroy things people use. The cleanup takes days because nobody can say which state is true. Shared, locked, remote state exists so this story never starts. The teams that treat state as a casual local file relearn this on a schedule.

Concepts

State maps configuration to real objects: which resource IDs correspond to which blocks, what attributes were last applied. Without it the tool cannot plan, because planning is desired-minus-actual and actual comes from state refreshed against the provider. Committing state files to version control leaks secrets (state often holds credentials in plain text) and invites concurrent-write corruption; state belongs in locked remote storage with versioning and access control.

Locking serializes writers. Apply takes the lock; a second apply waits or fails instead of interleaving. Stuck locks happen when a run dies mid-apply; the recovery is to verify no runner is alive, then release the lock with the recorded lock ID, never deleting state to clear a lock. Deleting state does not delete infrastructure: it orphans it, and the next plan proposes to recreate everything while the old objects keep running and billing.

Drift is hand change: someone edits outside the tool, and reality stops matching state. Detection is a plan or refresh that surfaces unexpected diffs; the L35 lab rehearses this. Reconciliation is a decision, not a reflex: adopt the change into code when it was correct, revert it by applying when it was not. Importing existing objects into state follows the same honesty: import records reality, it does not validate it, so review imported configuration before trusting it.

Worked example

A local fixture resource is edited outside the tool (file contents changed by hand). The next plan shows an unexpected diff; the learner quotes it, decides the hand edit was wrong, applies to restore the coded state, and the following plan is empty. Then a correct hand change is adopted into code instead, showing both branches of the decision.

Common wrong move

Deleting and rebuilding state to fix confusion. That orphans every managed object and turns one muddled file into untracked infrastructure. Repair state with locks, imports and targeted moves; never with deletion.