The Plan-Apply Loop and Why It Exists

Why this matters

Someone applies a configuration change directly, and a database the team thought was managed elsewhere is replaced. The tool did exactly what the code said; nobody read what the code said first. Every infrastructure incident of this class shares one skipped step: the plan was generated and ignored, or never generated at all. The plan is the whole safety story in one screen: additions, changes, destructions, named before they happen. Reading it is not bureaucracy, it is the job.

Concepts

The workflow has three motions. Write declares the desired infrastructure in configuration files. Plan compares desired against actual (via state plus a live refresh) and prints the difference set: what will be created, changed or destroyed, and in what order. Apply executes the accepted plan. The discipline is that plan and apply can be separate steps run by different people or gates: plan on every change for review, apply only from the reviewed plan. Pipelines that plan on pull requests and apply on merge make the loop structural instead of voluntary.

Plan output has a grammar worth learning cold. Plus means create, tilde means modify in place, minus means destroy, minus-plus means replace (destroy then create, with downtime and data implications). A plan that replaces a database to change an immutable field is telling you the cost of that edit; the correct response is usually to change the approach, not to accept the replacement.

Reproducibility closes the loop. Pinned provider versions, committed lock files and variable files per environment mean the plan you reviewed is the plan that applies. Unpinned providers drift: the same code plans differently six months later, and the difference arrives as a surprise inside an unrelated change.

Worked example

A local fixture configuration manages a file and a container. The learner runs plan (two creations), applies, edits one attribute, runs plan again (one in-place change) and applies. Then a deliberately destructive edit stages a replacement; the plan names it, the learner refuses it and rewrites the edit. The refused plan is kept as evidence that reading works.

Common wrong move

Auto-applying on every commit without a reviewed plan. Speed feels good until the first replacement nobody read. Plan is cheap, infrastructure is not; the review gate belongs between them permanently.