Terraform Plan vs Apply: How to Review Infrastructure Changes Before Deployment

Imagine you are managing an application that runs on AWS. You need to change the size of a server, update a security group, or add a new database. Instead of making these changes manually in the cloud console, you use Terraform to manage your infrastructure through code.

You update a configuration file, run Terraform, and expect the changes to be applied. But what if Terraform plans to delete an existing database or replace a server that is running your production application?

This is why understanding terraform plan and terraform apply is important.

Terraform helps developers and DevOps engineers manage infrastructure using configuration files. You describe the resources you need, and Terraform works out how to create or update them. However, you should not apply every change without checking what Terraform intends to do.

The terraform plan command shows the changes Terraform proposes to make. The terraform apply command executes those changes.

In this article, we will explore how both commands work, how to review infrastructure changes, and how to use them safely in development and production environments.

What Is Terraform Plan?

The terraform plan command checks your Terraform configuration and compares it with the current infrastructure state. It then shows which resources Terraform intends to create, update, replace, or delete.

For example, suppose your application currently runs on an AWS EC2 instance with the t3.small instance type. Your application is growing, and you want to change the instance type to t3.medium.

You update your Terraform configuration and run:

terraform plan

Terraform examines the configuration and produces a proposed list of changes.

The output might show that the instance can be updated without replacing it. Depending on the resource and the provider, some other changes may require Terraform to destroy and recreate the resource.

The main benefit of running a plan is that you can review these changes before executing them.

You can use the plan command to answer questions such as:

Which resources will Terraform create?
Which existing resources will change?
Will any resources be deleted or replaced?
Are unexpected security or networking changes included?
Does the proposed plan match the change you intended to make?

The plan command does not execute the proposed resource changes. However, it may communicate with providers and refresh information about existing resources while preparing the plan.

What Is Terraform Apply?

The terraform apply command is used to execute infrastructure changes.

When you run the command without providing a saved plan file, Terraform normally creates a new plan and asks for approval before applying it interactively.

For example:

terraform apply

Terraform displays the proposed changes and asks you to confirm them.

In a typical interactive session, you must enter yes to continue.

After approval, Terraform calls the relevant provider APIs to create, update, replace, or delete resources.

For example, if you add an EC2 instance to your configuration, Terraform may create that instance. If you remove a resource from the configuration, Terraform may plan to destroy the corresponding managed resource, depending on the state and configuration.

This is why you should understand the proposed changes before approving them.

In automated deployment pipelines, Terraform can also apply a saved plan:

terraform apply tfplan

In this case, Terraform executes the actions recorded in the saved plan rather than generating a new plan for interactive approval.

This approach is useful when a team wants to review a plan first and apply that same plan after approval.

Terraform Plan vs Apply: What Is the Difference?

Both commands are part of the infrastructure deployment process, but they serve different purposes.

Feature	Terraform Plan	Terraform Apply
Main purpose	Shows proposed infrastructure changes	Executes infrastructure changes
Creates resources	No	Yes, when required by the plan
Updates resources	No	Yes, when required by the plan
Deletes resources	No	Yes, when required by the plan
Useful for code review	Yes	Not as a replacement for review
Can be used in CI/CD	Yes	Yes, with suitable controls
Can use a saved plan	Creates one with `-out`	Executes a saved plan
Main concern	Understanding the proposed changes	Preventing unintended infrastructure changes

A simple way to remember the difference is this: use plan to review what Terraform intends to do, and use apply to carry out the approved changes.

However, a successful plan does not guarantee that the apply operation will succeed. Cloud permissions, API failures, external changes, and resource dependencies can affect the result.

Step 1: Prepare Your Terraform Configuration

Before planning infrastructure changes, make sure your Terraform configuration is ready.

Consider the following example:

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = "t3.small"

  tags = {
    Name = "production-app"
  }
}

This configuration describes an AWS EC2 instance. The Amazon Machine Image identifier comes from a variable, and the instance uses the t3.small instance type.

Suppose you want to increase the server size. You change the configuration to:

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = "t3.medium"

  tags = {
    Name = "production-app"
  }
}

Before applying this change, prepare the working directory.

First, initialize Terraform:

terraform init

This command downloads the required providers, prepares modules, and configures the backend when necessary.

Next, check whether the configuration is valid:

terraform validate

This helps identify configuration problems, such as invalid arguments or incorrect references.

You can also format your Terraform files:

terraform fmt -recursive

Formatting makes the configuration easier to read and review.

Remember that validation checks the configuration's structure and consistency. It does not tell you whether a proposed infrastructure change is safe for production.

Step 2: Run Terraform Plan and Review the Output

Once the configuration is ready, run:

terraform plan

Terraform calculates the proposed changes and displays a summary.

You may see output similar to this:

Plan: 1 to add, 1 to change, 0 to destroy.

This means Terraform plans to create one resource and update another, without destroying any resources.

The numbers are useful, but they do not tell the whole story. You should also inspect the details of each resource change.

Terraform uses symbols to describe planned actions.

Symbol	Meaning	What to check
`+`	Create a resource	Check its configuration and cost
`~`	Update a resource in place	Check which settings will change
`-`	Destroy a resource	Confirm that deletion is expected
`-/+`	Destroy and then create a replacement	Check for downtime and data loss
`+/-`	Create a replacement before destroying the old resource, when supported	Check temporary capacity and resource dependencies

For example, a plan might show:

~ resource "aws_instance" "app" {
    ~ instance_type = "t3.small" -> "t3.medium"
  }

This indicates that Terraform plans to change the instance type.

The exact plan depends on the provider, the current resource, and the attributes being changed. Always review the output generated for your actual configuration.

Step 3: Pay Attention to Resource Replacement

Resource replacement is one of the most important things to check before applying a plan.

Some infrastructure settings can be changed without replacing a resource. Other settings require Terraform to destroy the existing resource and create a new one.

For example, replacing an application server might cause temporary downtime if the application does not have other healthy instances available.

Replacing a database can be much more serious if the process affects stored data or application availability.

When Terraform shows that a resource will be replaced, ask the following questions:

Why does the provider require replacement?
Will the application experience downtime?
Could the replacement affect stored data?
Is a backup available?
Are other resources dependent on the resource being replaced?
Is there a migration or recovery plan?

Do not assume that a replacement is always wrong. Sometimes it is necessary. The important thing is to understand why it is happening and whether the application can safely handle it.

For critical resources, review the provider documentation and test the change in a non-production environment first.

Step 4: Save the Plan Before Applying It

There is an important difference between reviewing a plan and applying a saved plan.

Suppose you run:

terraform plan

You review the output and approve the change. Later, you run:

terraform apply

Terraform normally calculates a new plan before asking for approval. The new plan may differ from the one you reviewed because the configuration, state, or infrastructure has changed.

To avoid this problem, save the plan to a file:

terraform plan -out=tfplan

Terraform stores the proposed operations in the tfplan file.

You can then review the saved plan in a readable format:

terraform show tfplan

After the review and approval process is complete, apply that plan:

terraform apply tfplan

This allows Terraform to execute the saved plan rather than generating a new plan for that apply operation.

Keep in mind that a saved plan is not a permanent deployment instruction. Terraform may reject it if the state has changed or the plan is no longer valid.

If the plan becomes stale, generate a new one and review it again.

Also, treat saved plan files as sensitive artifacts. They can contain infrastructure details and sensitive values. Store them in restricted locations and avoid committing them to a public repository.

Step 5: Use Plan and Apply in a CI/CD Pipeline

When several developers manage the same infrastructure, reviewing changes manually on individual machines can lead to inconsistent deployment practices.

A CI/CD pipeline can make the process more reliable.

For example, a team might use the following workflow:

Developer updates Terraform files
              |
              v
Pull request is created
              |
              v
Run formatting and validation
              |
              v
Generate a Terraform plan
              |
              v
Review proposed changes
              |
              v
Approve the production deployment
              |
              v
Apply the approved saved plan
              |
              v
Verify the infrastructure

This workflow gives reviewers an opportunity to catch unexpected changes before they reach production.

For example, a developer may intend to update an application server but accidentally change a database identifier. A detailed plan review can reveal the proposed replacement before it is applied.

For production environments, the pipeline should use restricted credentials and appropriate approval rules. Development, testing, and production should have clearly separated state and access controls.

A pipeline should also make sure that the saved plan being applied belongs to the intended environment and configuration revision.

Do not assume that running terraform plan successfully means the infrastructure is ready for deployment. The plan still needs review, and the apply operation still needs monitoring.

Step 6: Handle Common Problems

Even with a careful workflow, Terraform deployments can encounter problems.

The Plan Shows Unexpected Changes

If Terraform proposes changes you did not expect, do not immediately apply them.

Check which configuration values changed, whether the state matches the real infrastructure, and whether another person or process modified the resources outside Terraform.

You should also review provider and module changes. A provider upgrade may change how certain resource attributes are interpreted.

If the plan is unclear, test the configuration in a separate environment and investigate the relevant resource behavior before continuing.

Terraform Wants to Delete a Resource

First, determine why the resource is marked for deletion.

It may have been removed from the configuration, renamed, or affected by a change in resource dependencies. The state may also need investigation if someone modified infrastructure outside Terraform.

Do not remove resources from the configuration simply to make the plan look cleaner. Understand the intended infrastructure state before proceeding.

For important resources, review backup and recovery options before approving deletion.

Terraform Apply Fails

An apply operation may fail because of insufficient permissions, cloud service problems, API limits, or resource dependencies.

Read the error message carefully and determine which operation failed.

Terraform may have completed some actions before another action failed. Therefore, do not assume that a failed apply means no infrastructure changes occurred.

Inspect the current state and infrastructure, resolve the underlying issue, and generate a fresh plan before continuing.

The Saved Plan Is No Longer Valid

If Terraform reports that a saved plan cannot be applied because the state has changed, do not try to force the old plan through.

Generate a new plan, review the updated changes, and repeat the approval process.

This protects the team from applying changes based on an outdated view of the infrastructure.

Best Practices for Safe Terraform Deployments

A few consistent practices can reduce the risk of infrastructure mistakes.

Run terraform fmt and terraform validate before generating a plan.
Review individual resource changes instead of relying only on the plan summary.
Investigate unexpected deletions and replacements before approving a deployment.
Save the plan when a separate review and approval process is required.
Apply the approved saved plan instead of recalculating changes at deployment time.
Protect plan files and state files because they may contain sensitive information.
Use least-privilege credentials for planning and deployment.
Keep development, testing, and production environments separate.
Use remote state and locking where supported by the selected backend.
Keep backups and recovery procedures for important stateful resources.

For production deployments, teams should also define who can approve changes, how emergency changes are handled, and how the results of an apply operation are verified.

Advantages and Limitations

The plan-and-apply workflow makes infrastructure changes easier to understand before they are executed. It helps teams identify unexpected replacements, review security changes, and introduce approval steps into their deployment process.

It also improves collaboration because developers and reviewers can inspect the same proposed changes before deployment.

However, Terraform planning does not remove every risk. Cloud services can fail, permissions can change, and infrastructure may be modified outside Terraform. Some resource operations can also cause downtime even when the plan is correct.

A plan is therefore one part of a safe deployment process. Testing, monitoring, backups, access controls, and recovery procedures remain important.

Summary

Terraform plan and apply serve different purposes. The terraform plan command shows the infrastructure changes Terraform intends to make, while terraform apply executes those changes.

Before deploying to production, initialize and validate the configuration, generate a plan, and carefully review every important resource change. Pay particular attention to resource replacements, deletions, security settings, and changes that could affect application availability.

For a controlled deployment, save the plan, review and approve it, and apply that same saved plan. If the plan becomes stale or the deployment fails, investigate the current infrastructure and create a fresh plan before continuing.

This approach helps developers and DevOps teams manage infrastructure changes with fewer surprises and a clearer understanding of what each deployment will do.