A guard that exists is not a guard that works
A guard against a specific hazard is often built once, in one place, and assumed to now cover everything that has the hazard. That assumption fails in a specific and recurring way: a fix written into a shared piece of code protects only the things that actually use that shared piece. Anything that duplicates the same logic instead of referencing it sits outside the fix entirely, unless someone goes back and updates every duplicate by hand.
The failure gets worse when an older version of the guard was already present before the fix. A guard that used to cover one thing, and now needs to cover three, still looks like a guard after the update: same keyword, same shape, sitting in exactly the place a reviewer expects to find it. A visual check confirms a guard block exists and stops there. It cannot tell an old, partial copy from the current, complete one without reading what’s actually inside it. Presence is not protection. Contents are.
What a guard actually needs to show
This shows up hardest in systems where a specific class of setting is tied to an instance’s identity rather than to its current configuration: it runs once for that identity, and there’s no route to update it in place afterward. A change to it doesn’t read as ordinary drift to reconcile. It reads as “this thing must be replaced,” because destroying and recreating the thing is the only route back to agreement the tool has. The instinct that works everywhere else, apply the plan and make it clean, is exactly backward here: applying is what does the damage. The correct response is to tell the tool to stop tracking that setting at all, so a future change to it no longer looks like a reason to destroy anything.
A concrete, invented illustration of what “looks protected but isn’t” means in practice: imagine a guard that reads
ignore changes to: image_id
sitting next to the current version, which reads
ignore changes to: image_id, network_config, boot_script
Both are, in the loosest sense, “a guard block is present.” Only the second one is complete. A reviewer scanning for the pattern, the keyword, the shape, will pass both. A check that scans for the same pattern will pass both too. Only a check that knows what a given piece of infrastructure actually sets, and confirms every one of those specific things is listed, catches the first block for what it is: real syntax, wrong contents, no protection.
The fix, and three things still worth checking
That’s the fix that actually closes this particular gap. Not “does a guard block exist,” but “does the guard, for this specific piece of infrastructure, list everything this specific piece of infrastructure needs it to list.” Derived per case, from what’s actually declared, rather than from a single rule someone has to remember to apply everywhere by hand.
Closing the gap this way still leaves three things worth checking, and they’re general to the pattern, not particular to this one fix. Don’t take a guard’s existence on faith: re-run the plan and confirm the specific resource that was going to be destroyed has actually dropped out of it, not just that a guard block is present somewhere in the configuration. If a rebuild really is wanted, a deliberate one and never a side effect of cleaning up an unrelated plan, confirm a restore point exists before doing anything else; a guard being in place says nothing about whether the current state is safe to throw away. And before rebuilding anything that carries a public address, check whether that address is referenced anywhere outside the infrastructure tool itself. The tool only knows what it manages; it has no way to tell you who else is pointing at the thing it’s about to change.
Two more gaps a correct fix can still leave
Two more general ways a correct fix still leaves a gap, visible in the same story: a fix scoped to the one thing that just broke rather than to the whole category it belongs to, so the next instance of the same category is still unguarded the day the fix ships. And a fix documented wherever the person happened to be working when they found it, rather than wherever someone would look for it later, so the record of the hazard is technically written down and still functionally lost.
The night this was learned on, in full, is told as it happened, with nothing smoothed over: Act 22, The guard that did not propagate.