The Plan/Apply Lifecycle

Every change Terraform makes goes through the same three phases: refresh reads the current real-world state, plan diffs your configuration against that state, and apply executes the diff. The single fact that makes this safe is that plan is read-only and apply is the only phase that touches anything. That separation is what lets you review an infrastructure change the way you review a pull request — look at the diff first, then approve it.

Most production incidents that trace back to Terraform are not bugs in the tool. They are someone applying a plan they did not read, where a buried -/+ line quietly destroyed and recreated a database. Reading the plan is the skill; the rest is mechanics.

Refresh

Before computing anything, Terraform queries the provider for the current state of every resource it tracks, so the plan reflects reality rather than a stale snapshot in the state file. If someone resized an instance in the console, refresh is where Terraform notices. You can run this phase alone with terraform plan -refresh-only, which shows what drifted in the real world without proposing any configuration-driven changes — the clean way to reconcile state with reality when you suspect drift.

Plan

Plan compares the refreshed state to your configuration and computes one of four actions for every resource: create, update in place, destroy, or destroy-and-recreate. It prints each with a symbol — + create, ~ update in place, - destroy, and -/+ replace. Nothing changes during a plan; it is a proposal. The example below changes a tag (an in-place update) but also changes the AMI, which AWS cannot alter on a running instance, forcing a replacement.

# aws_instance.web must be replaced
-/+ resource "aws_instance" "web" {
    ~ ami           = "ami-0aaaaa" -> "ami-0bbbbb" # forces replacement
    ~ instance_type = "t3.micro" -> "t3.small"
    ~ tags          = {
        ~ "Name" = "web" -> "web-1"
      }
  }

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

The # forces replacement annotation on the ami line is the most important text in that output. It tells you exactly which argument triggered the destroy-and-recreate. The summary line — 1 to add, 0 to change, 1 to destroy — is the count, but the annotation is the explanation, and on a stateful resource it is the difference between a no-downtime tweak and an outage.

Apply

Apply walks the dependency graph and executes the planned actions in order, calling the AWS APIs and updating state after each resource succeeds. Independent resources run in parallel; dependent ones wait. If apply is interrupted, the state file still records everything that completed, so the next run picks up from a consistent point rather than redoing finished work. Run without a saved plan, apply re-plans first and asks for confirmation, showing you the same diff one more time before it commits.

Saved Plans

In any pipeline, you freeze the plan and apply that exact file. terraform plan -out=tfplan writes the computed diff to disk; terraform apply tfplan executes it without re-planning. This is what makes a reviewer's approval meaningful: apply does exactly what was reviewed, even if config or reality changed in the meantime.

# in CI: produce a reviewable artifact
terraform plan -out=tfplan

# after approval: apply the frozen diff, no re-plan
terraform apply tfplan

The flip side is the part that surprises people: a saved plan applies the diff it was built from, not a fresh diff against current reality. If the world changed between plan and apply, apply still executes the old plan. That is the intended behavior — you reviewed that diff — but it means you keep the window between plan and apply short so the frozen diff has not gone stale.

Reading Plan Output

The one distinction worth internalizing is ~ versus -/+. A ~ changes a mutable attribute in place with no disruption — an instance tag, an autoscaling group's desired count. A -/+ destroys the resource and builds a new one because the changed argument is immutable on the cloud side, and for a database or an EBS volume that means data loss or downtime unless you have planned for it. Scan every plan for -/+ on stateful resources before you approve, and read the # forces replacement annotation to know which argument is responsible.