Before you let Terraform touch your infrastructure, you want to know exactly what it's going to do. That’s where the Terraform plan command earns its keep.
Think of it as a “dry run” that shows what Terraform would change—without actually changing anything. If you’ve ever accidentally deleted a resource in production, you already understand why this matters.
What the Terraform Plan Command Actually Does
At its core, terraform plan compares three things:
- Your current state (what exists in your infrastructure)
- Your configuration files (what you declared)
- The last known state file
From this comparison, Terraform builds an execution plan that answers:
- What will be created
- What will be updated
- What will be destroyed
No API calls are made to modify resources. It’s purely a preview.
Quick Example
Here’s a simple Terraform configuration:
1resource "aws_s3_bucket" "app_bucket" {
2 bucket = "my-app-bucket-123"
3 acl = "private"
4}
5Running:
1terraform planYou might see output like:
1+ resource "aws_s3_bucket" "app_bucket" {
2 bucket = "my-app-bucket-123"
3 acl = "private"
4 }
5The + indicates a resource will be created.
Reading Terraform Plan Output Without Guesswork
The symbols in the output are easy to overlook but extremely important:
- + → Resource will be created
- ~ → Resource will be updated in-place
- - → Resource will be destroyed
- -/+ → Resource will be replaced (destroy + create)
Here’s where things get interesting: a small configuration change can trigger a full replacement.
For example:
1~ instance_type = "t2.micro" -> "t3.micro"Sometimes this is safe. Other times, Terraform may decide the resource must be recreated entirely.
Using terraform plan with Output Files
You can save the plan to a file and apply it later. This is especially useful in CI/CD pipelines.
1terraform plan -out=tfplanThen apply exactly that plan:
1terraform apply tfplanThis guarantees that what you reviewed is exactly what gets executed—no surprises.
Filtering and Targeting Changes
Sometimes you don’t want to plan everything. You can target specific resources:
1terraform plan -target=aws_s3_bucket.app_bucketThis is helpful for debugging, but relying on -target in regular workflows can lead to inconsistent state. Use it sparingly.
Variable Overrides in Plan
You can test different configurations without editing files:
1terraform plan -var="instance_type=t3.micro"Or with a variables file:
1terraform plan -var-file="prod.tfvars"This is a common pattern in multi-environment setups.
Why terraform plan Is Critical in CI/CD
In real-world pipelines, terraform plan is often run automatically before approval.
A typical flow:
- Developer pushes code
- CI runs
terraform plan - Plan output is reviewed
- Manual approval triggers
terraform apply
This prevents accidental infrastructure changes and makes deployments auditable.
A Common Mistake Developers Make
Skipping the plan step locally.
Running terraform apply directly might seem faster, but you lose visibility. Even a small typo can result in:
- Unexpected resource deletion
- Cost spikes
- Downtime
Running terraform plan takes seconds and can save hours of recovery work.
Plan vs Apply: The Real Difference
| Command | What It Does |
|---|---|
| terraform plan | Previews changes without applying |
| terraform apply | Executes the changes |
The key idea: plan is safe, apply is not.
Handling Sensitive Data in Plan Output
Terraform may hide sensitive values:
1(sensitive value)This prevents secrets from leaking into logs, especially in shared CI environments.
Performance Considerations
For large infrastructures, terraform plan can take time because it:
- Queries provider APIs
- Refreshes state
- Calculates diffs
To speed things up (with caution):
1terraform plan -refresh=falseThis skips state refresh, but may produce inaccurate plans if infrastructure has drifted.
When Plan Output Looks Wrong
If Terraform plans unexpected changes, it’s usually due to:
- Manual changes outside Terraform (drift)
- Provider behavior differences
- Computed or default values
In these cases, reviewing the plan carefully is your best debugging tool.
Final Thoughts
The Terraform plan command isn’t just a preview—it’s your safety net. It gives you a chance to catch mistakes, understand impact, and maintain control over your infrastructure.
If you build the habit of always running and reviewing terraform plan, you’ll avoid most of the painful surprises that come with infrastructure as code.
And in DevOps, fewer surprises is always a win.