Why You Should Always See the Plan Before Running Terraform

You just finished writing a Terraform configuration for a new server and database. The file looks correct. You run terraform apply and wait. A few seconds later, you realize the server is twice as large as needed, and the database is in the wrong region. Now you have to tear everything down and start over.

This scenario plays out constantly in teams that are new to Infrastructure as Code. The impulse to skip ahead and apply changes directly is strong. But there is a step that saves time, money, and frustration: seeing the plan before executing it.

What Happens When You Skip the Plan

When you run terraform apply directly, Terraform immediately starts creating, modifying, or deleting resources based on your configuration. If something is wrong, you only find out after the changes have been made. Rolling back might be simple for some resources, but for others it can involve manual cleanup, support tickets with cloud providers, or downtime for users.

The problem is not just about mistakes in configuration. Even when your configuration is technically correct, the changes might have side effects you did not anticipate. A network configuration change could break connectivity between services. A storage size reduction could cause data loss. A security group update could accidentally expose internal resources to the internet.

You need a way to preview what Terraform will do before it does it.

How Terraform Plan Works

The terraform plan command generates what is called an execution plan. It reads your configuration files and compares them against the current state of your infrastructure, which is stored in the Terraform state file. The output shows exactly what resources will be created, modified, or deleted, along with the details of each change.

The critical difference is that terraform plan does not actually make any changes. It only reads and compares. No resources are created, updated, or destroyed. You can run it as many times as you want without affecting your infrastructure.

Here is what happens when you run it:

terraform plan

Terraform connects to your provider, reads your configuration, checks the current state, and prints a summary of planned actions. For the server and database configuration from earlier, the output might look like this:

  • One virtual server will be created with 2 CPU cores and 8 GB RAM
  • One database will be created with 100 GB storage
  • Both resources will be connected through an internal network

If you already have a server running and you change its configuration, the plan will show that the existing server will be updated in place, not destroyed and recreated. This distinction matters because in-place updates are usually safer and faster than replacement.

Why the Plan Matters for Your Workflow

The execution plan gives you three things that are hard to get otherwise.

First, you can verify that your changes match what you intended. Before you commit to applying changes, you have a chance to review the details. Did you accidentally set the wrong instance type? Is the database engine version correct? The plan shows these details clearly.

Second, you can catch side effects you did not think about. Maybe you changed a variable that affects multiple resources. Maybe a small configuration tweak triggers a resource replacement instead of an update. The plan surfaces these hidden dependencies.

Third, you can share the plan with other people. In a team setting, not everyone needs to understand the Terraform syntax. But most engineers can read a plan output and spot potential issues. A database administrator can verify that the storage configuration is appropriate. A security engineer can check that network rules are not too permissive.

Using the Plan in CI/CD Pipelines

In team environments, terraform plan is typically automated in the CI/CD pipeline. When someone opens a pull request that changes infrastructure configuration, the pipeline runs terraform plan automatically and posts the result as a comment on the pull request.

This workflow means the entire team can review what will change before the code is merged. The discussion happens around the plan output, not around abstract descriptions of what the code might do. Questions like "Why is this resource being replaced?" or "Should this security group be open to the internet?" get answered before any changes are applied.

The following flowchart illustrates the typical plan-review-apply cycle used in CI/CD pipelines:

flowchart TD A[Code Change] --> B[Terraform Plan] B --> C{Review Plan} C -->|Approved| D[Terraform Apply] C -->|Not Approved| E[Fix Code] E --> A D --> F[Infrastructure Updated]

Some teams take this further by requiring approval on the plan output before the apply step can proceed. The plan becomes a checkpoint that gates changes to production infrastructure.

A Common Mistake: Stale Plans

There is one important limitation to understand. The execution plan is a snapshot of what Terraform would do at the moment you ran the command. If someone else changes the infrastructure between when you run terraform plan and when you run terraform apply, the plan might no longer be accurate.

For example, suppose you run terraform plan and see that one server will be created. Before you run terraform apply, a teammate creates that same server manually through the cloud console. When you run terraform apply, Terraform will detect the conflict and fail, or worse, it might create a duplicate resource depending on how your configuration is written.

This is why good workflows keep the plan and apply steps close together. In CI/CD pipelines, the same pipeline run typically does both steps sequentially. For local development, you should run plan immediately before apply, not hours or days earlier.

Some teams also use state locking to prevent concurrent modifications. When one person or pipeline is running a plan or apply, others are blocked from making changes until the operation completes.

Practical Checklist for Using Terraform Plan

  • Run terraform plan before every terraform apply, even for small changes
  • Review the plan output for unexpected resource replacements or deletions
  • Check that the number of resources being created matches your expectations
  • Look for changes to security groups, network rules, and IAM policies
  • Share the plan output with relevant team members for review
  • In CI/CD, post the plan as a comment on pull requests
  • Keep plan and apply steps close together in time
  • Use state locking to prevent conflicts in team environments

What You Gain From This Habit

The habit of running terraform plan before every change shifts your workflow from reactive to deliberate. Instead of discovering problems after resources are created, you catch them while they are still just text on a screen. The cost of fixing a mistake in a plan is zero. The cost of fixing it after apply can be hours of debugging, manual cleanup, and coordination with your team.

Next time you write a Terraform configuration, run the plan first. Read the output carefully. Then decide whether to apply. That one extra step separates teams who manage infrastructure confidently from teams who are constantly cleaning up after themselves.