# terraform / core / workflow

The Six Commands: Terraform Core Workflow

Terraform manages infrastructure as code through a small, disciplined set of commands. Each one has a single job — formatting, validating, planning, or applying — and together they form the loop every Terraform project runs on, from a first init to a final destroy.

$ terraform plan
"init"Downloads providers
"plan"Previews changes
"apply"Executes changes
6
Core Commands
2
Change State
# mental model

Read Before You Write

Terraform never touches your infrastructure blindly. Every change passes through a preview stage first — that's the core discipline the workflow enforces: describe, then preview, then apply, never skip straight to the last step.

non-destructive

init · fmt · validate · plan

These four commands read your configuration and, at most, your provider APIs. None of them create, modify, or delete a single real resource.

destructive

apply · destroy

Only these two commands change actual infrastructure — and both stop to ask for typed confirmation before doing so, unless you pass -auto-approve.

# reference

The Six Commands

01 / SETUP

terraform init

Initializes a project: downloads provider plugins, pulls in modules, creates the .terraform/ directory, and configures the backend.

  • run when

    First use, after changing providers/backend, or after cloning a repo.

$ terraform initOUTPUT
1 2 3
Initializing provider plugins...
- Finding hashicorp/aws...
Terraform has been successfully initialized!
02 / PREVIEW

terraform plan

Compares current infrastructure against your configuration and shows exactly what would be created, modified, or destroyed. Nothing is changed.

  • mental model

    "Here's what I'm going to do. Is it okay?"

$ terraform planOUTPUT
1 2 3
+ aws_instance.web

Plan: 1 to add, 0 to change, 0 to destroy.
03 / EXECUTE — CHANGES INFRASTRUCTURE

terraform apply

Reads the configuration, generates a plan, asks for confirmation, then executes the changes for real.

  • CI/CD

    Skip the prompt with terraform apply -auto-approve.

$ terraform applyPROMPT
1 2 3
Do you want to perform these actions?

Enter a value: yes
04 / TEARDOWN — CHANGES INFRASTRUCTURE

terraform destroy

Deletes every resource Terraform manages for this configuration. Asks for confirmation the same way apply does.

  • caution

    Use carefully, especially in production. -auto-approve skips the prompt.

$ terraform destroyOUTPUT
1 2
Destroy complete!
Resources: 5 destroyed.
05 / STYLE

terraform fmt

Automatically rewrites your .tf files to Terraform's standard style — consistent spacing, aligned = signs, cleaner reviews.

main.tfBEFORE → AFTER
1 2 3 4
resource "aws_instance" "web" {
  ami           = "ami-123"
  instance_type = "t2.micro"
}
06 / CHECK

terraform validate

Checks that your configuration is syntactically valid — required arguments, block structure, and references. It never contacts your cloud provider.

  • tip

    Run this before plan to catch mistakes early.

$ terraform validateOUTPUT
1 2
Success! The configuration is valid.
Error: Missing required argument
# sequence

The Typical Workflow

Write Terraform code
terraform fmt
terraform validate
terraform init
terraform plan
terraform apply
Infrastructure Created
terraform destroy (when no longer needed)
STEP 1–3

Format, then validate, then initialize. Cheap checks run before anything that touches a provider API.

STEP 4

Plan shows the diff between desired and actual state — your last chance to catch a mistake before it's real.

STEP 5–6

Apply executes the plan. Destroy, run only when the environment is truly done, tears it back down.

terminalEND TO END
$ terraform fmt && terraform validate
$ terraform init
$ terraform plan
$ terraform apply
# at a glance

Quick Summary

CommandPurposeChanges Infrastructure?
terraform initInitialize project, download providers/modulesNo
terraform fmtFormat Terraform codeNo
terraform validateValidate configuration syntaxNo
terraform planPreview proposed changesNo
terraform applyCreate or update infrastructureYes
terraform destroyDelete managed infrastructureYes