Why You Should Plan Infrastructure Changes Before Applying Them

You're reviewing a pull request that changes one line in a firewall configuration file. The change opens port 443 for public traffic. Simple enough, right?

But that single line could have consequences you didn't anticipate. Maybe another rule conflicts with it. Maybe that port was intentionally closed for security reasons six months ago, and nobody remembers why. Maybe opening it will break a database connection that's been routing through a different port. You won't know any of this until after the change is applied and something stops working.

This is the exact situation that the plan-review-apply workflow is designed to prevent.

The Problem with Direct Application

When you apply infrastructure changes directly, you're working blind. You might have the code in front of you, but code alone doesn't show you what will actually happen when it runs against your live environment. The real state of your infrastructure could be different from what your code assumes. Someone might have made a manual change last week. A previous deployment might have left things in an unexpected state. Your code says "add this rule," but the system might interpret that as "replace all existing rules with this one."

Direct application turns every change into a gamble. You only find out if you lost when things break.

How Plan-Review-Apply Works

The workflow has three stages, and each one serves a specific purpose.

The diagram below illustrates the flow:

flowchart TD A[Start: Code Change] --> B[Plan: Generate Diff] B --> C[Review: Human Checks Plan] C -->|Approved| D[Apply: Execute Changes] C -->|Rejected| B D --> E[End]

Plan generates a detailed comparison between your current infrastructure state and the state your code wants to create. It shows exactly what will be added, modified, or deleted. This isn't a summary or a guess. It's a precise, machine-generated diff of your infrastructure.

Review is where humans examine that plan. You check for surprises. You verify that the plan matches the intent of the change. You catch things like "this security group deletion will affect production servers" before anyone hits apply.

Apply executes the planned changes. Because the plan was already verified, the apply step has a much lower risk of unexpected outcomes. You're not guessing anymore. You're executing a known set of changes.

What a Plan Actually Looks Like

A plan isn't a vague description. It's a concrete list of operations. For example, a plan might show:

  • Add a new security group rule for port 443
  • Modify an existing load balancer listener to use a new certificate
  • Delete a database subnet group that's no longer referenced

Each operation includes the resource identifier, the current value, and the new value. This level of detail lets you spot problems before they happen. You might see that the plan wants to delete a resource you thought was unused, or modify a setting that another team depends on.

Making Plan a Hard Requirement

The most effective teams treat the plan as a non-negotiable step. Their pipeline is configured to stop if no plan has been generated, or if the plan hasn't been reviewed and approved. This is the infrastructure equivalent of requiring code review before merging a pull request. You wouldn't merge unreviewed code into production. Why would you apply unreviewed infrastructure changes?

This guardrail prevents the most common failure pattern: someone making a small change, assuming it's safe, and applying it without checking. The pipeline forces them to generate a plan first, which often reveals something they didn't expect.

Plans as Audit Trails

Plans serve a second purpose that becomes critical when things go wrong. Every plan can be saved as an artifact in your pipeline. This creates a historical record of every infrastructure change: what changed, when it changed, and who approved it.

When a production incident happens, that record is invaluable. Instead of asking around to find out who changed what, you look at the plan artifacts. You can see the exact diff that was applied right before the problem started. This turns incident investigation from guesswork into evidence-based analysis.

Without saved plans, you're left with manual logs, chat messages, and memory. None of those are reliable when you're trying to debug a production outage at 2 AM.

Handling Concurrent Changes

Teams working on the same infrastructure face another challenge: conflicting changes. Two people modify network configuration files at the same time. Both changes look fine in isolation. But when combined, they create a conflict that could break connectivity.

The plan step catches this. When the second person generates a plan, it will show the conflict before any changes are applied. The team can resolve the conflict in code, not in production. This is far safer than applying both changes and hoping they don't interact badly.

What Plan Doesn't Solve

Plan-review-apply is powerful, but it has limits. It can only compare what your code says against what your infrastructure currently reports. If someone makes a manual change outside of your pipeline, the plan might not catch every inconsistency. If your infrastructure provider has a bug or an unexpected behavior, the plan might show something different from what actually executes.

These edge cases don't invalidate the workflow. They just mean you need additional practices alongside it, like drift detection and regular reconciliation between your code and your live infrastructure.

Practical Checklist

Before you implement plan-review-apply in your pipeline, consider these points:

  • Generate plans automatically after every merged pull request, not just on demand
  • Save every plan as a pipeline artifact with timestamps and approval metadata
  • Block apply if no plan exists or if the plan hasn't been reviewed
  • Review plans for surprises before approving, not just for correctness
  • Use plans during incident investigation as your first source of truth for recent changes

The Core Idea

Plan-review-apply turns infrastructure changes from blind gambles into calculated, verified operations. The plan shows you what will happen before it happens. The review catches problems before they reach production. The apply executes only what was verified. This workflow doesn't eliminate all risk, but it eliminates the risk of applying changes without knowing their full impact.

If your team is still applying infrastructure changes directly, start with one simple rule: generate a plan first, read it, and only then decide whether to apply. That single habit will prevent more production issues than most monitoring tools ever will.