Cormac Byrne

The plan is the only safety mechanism this tool has, and treating it as a formality removes it. That is convenient and it is where the surprising behaviour lives: a count on an unknown value produces an unknown plan, and a reference to a resource that is being replaced can resolve differently at apply time than at plan time. The state file records what exists, and that record is the tool's memory. It has to be shared by everyone applying the same configuration, it has to be locked when it is written, and it has to be treated as the authoritative record rather than as something to regenerate. Losing it means the tool no longer knows what it manages. Formatting has one convention and one rule: one argument per line. Anything else produces diffs that bury the change. Validation happens in stages, and a plan that passes validation can still fail at apply. That is not a defect; it is what happens when something outside the configuration changed in between. The problems that surface months later are nearly all state problems. A resource replaced outside the tool, a state entry removed by hand, an import that did not cover the existing object. I keep a section on each of them because the symptom appears nowhere near the cause. I keep a short list of the state commands on every page, because knowing which one you want before you are in a hurry matters more than knowing all of them. A plan run against a state file that has drifted will produce a plan describing changes you did not ask for, and that is the first thing to check when a plan surprises you.