I review plans for a living now, and I've stopped reading them top to bottom. The order I use:
Replacements first. Anything with -/+ is a resource being destroyed and recreated. Often fine, occasionally a database. I look at that list before anything else.
Then security group and IAM diffs, character by character. A single 0.0.0.0/0 or a widened action list is easy to miss in a wall of text and hard to undo quietly.
Then anything with a count or a for_each that grew. Three new replicas is a cost question, three hundred is an incident waiting to happen.
Finally deletions. A destroy on something that still has data is the only change I'll stop a deploy for.
The one rule I'd give anyone: if the plan is too long to review, that's the finding. Split the change. A two-hundred-line plan gets approved by scrolling, and scrolled-over plans are how prod gets interesting.
Nothing here is clever. It's just a reading order that stops me from approving what I didn't see.
Top comments (0)