terraform init, plan, and apply

Analogy categoryAnalogies

The heart of using Terraform day to day is a three-command cycle: terraform init, terraform plan, and terraform apply. This sequence separates preparation, preview, and execution into distinct, deliberate steps, which is one of Terraform's biggest safety advantages over ad-hoc scripting — nothing changes in real infrastructure until you explicitly approve an apply after reviewing exactly what will happen.

🏏

Cricket analogy: The init-plan-apply cycle is like nets, a team meeting reviewing the game plan, and then walking out to bat: nothing changes on the scoreboard until the captain deliberately commits to the plan after reviewing it.

terraform init

terraform init prepares a working directory for use. It downloads and installs the provider plugins declared in required_providers, initializes any configured backend (where state will be stored), and downloads any external modules referenced by module blocks. It must be run at least once in a new working directory, and again whenever you add a new provider, module, or change the backend configuration. Init is idempotent and safe to re-run; it will simply verify everything is already in place if nothing has changed.

🏏

Cricket analogy: terraform init preparing a working directory is like a groundstaff crew setting up the pitch, checking the equipment shed, and confirming the scoreboard system before a match — done once per venue, and again only if something new is added.

terraform plan

terraform plan is a read-only, non-destructive operation. It refreshes Terraform's understanding of real-world resource state (unless -refresh=false is passed), compares that against the configuration files, and produces a detailed execution plan showing exactly which resources will be created (+), updated in place (~), replaced (-/+), or destroyed (-). Reviewing this output before applying is the single most important safety habit in Terraform usage — it catches unintended deletions, unexpected replacements, and configuration mistakes before they touch real infrastructure.

🏏

Cricket analogy: terraform plan is like DRS reviewing a decision without changing the scoreboard yet: it checks the real situation against the appeal and shows exactly what would change, catching a wrongly given dismissal before it becomes final.

terraform apply

terraform apply executes an execution plan. Run without arguments, it will compute a fresh plan (identical to terraform plan) and then prompt for interactive confirmation (yes) before proceeding. In automated pipelines, it is common practice to save a plan to a file with terraform plan -out=tfplan and then run terraform apply tfplan, guaranteeing the exact reviewed plan is what gets executed, with no risk of the underlying infrastructure or configuration changing between review and execution.

🏏

Cricket analogy: terraform apply executing a saved plan is like a captain committing to the exact batting order agreed in the team meeting, with no last-minute swaps allowed between the toss and walking out to bat.

Saving a plan file and applying that exact file (terraform plan -out=tfplan then terraform apply tfplan) closes a subtle race condition: without it, there's a gap between when a human reviews a plan and when apply runs, during which the real infrastructure could drift, causing apply to behave differently than what was reviewed.

A plan showing -/+ (replace) for a resource, rather than ~ (update in place), means Terraform will destroy and recreate that resource -- which can cause downtime or data loss for stateful resources like databases. Always read plan output carefully for replacement operations, not just counts.

bash

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Installing hashicorp/aws v5.52.0...
Terraform has been successfully initialized!

$ terraform plan -out=tfplan
Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t3.micro"
    }

  # aws_security_group.web_sg will be updated in-place
  ~ resource "aws_security_group" "web_sg" {
      ~ description = "old sg" -> "web tier security group"
    }

Plan: 1 to add, 1 to change, 0 to destroy.
Saved the plan to: tfplan

$ terraform apply tfplan
aws_security_group.web_sg: Modifying...
aws_instance.web: Creating...
aws_instance.web: Creation complete after 32s [id=i-0abcd1234ef567890]

Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

terraform init downloads providers/modules and initializes the backend; run first and after config changes.
terraform plan is a read-only preview showing additions (+), updates (~), replacements (-/+), and deletions (-).
terraform apply executes a plan, prompting for confirmation unless a saved plan file is supplied.
Saving and applying an exact plan file (plan -out then apply tfplan) avoids drift between review and execution.
Replacement operations (-/+) destroy and recreate a resource -- always review these carefully.
This init -> plan -> apply cycle is Terraform's core safety mechanism against unintended infrastructure changes.

Practice what you learned

1. What is the correct order of Terraform's core workflow commands?

2. Is `terraform plan` a destructive operation?

3. In Terraform plan output, what does the `-/+` symbol indicate for a resource?

4. Why is it a best practice to run `terraform plan -out=tfplan` followed by `terraform apply tfplan` in automated pipelines?

5. When must `terraform init` be re-run in an existing working directory?

Was this page helpful?

Providers Explained

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#HCL#TerraformInfrastructureAsCodeStudyNotes#DevOps#TerraformInitPlanAndApply#Terraform#Init#Plan#Apply#StudyNotes#SkillVeris

terraform init, plan, and apply