Terraform Workflow Explained — Why init/plan/apply Confusion Causes Exam Mistakes
You’ve run terraform init, plan, and apply hundreds of times. Yet when the exam asks what happens during each phase, the questions feel unexpectedly tricky. That’s because the exam tests command boundaries—what each command does and, critically, what it doesn’t do.
This isn’t about memorizing syntax. It’s about understanding that Terraform’s workflow is a strict pipeline where each phase has exactly one job. The exam exploits the gap between “I use these commands” and “I understand what each command actually does internally.”
The Real Terraform Workflow Model
Terraform operates through a deterministic pipeline. Every successful infrastructure change follows this exact sequence:
The Terraform Execution Pipeline
1. Write → Configuration files (.tf)
2. Init → Backend + Providers + Modules
3. Plan → Diff (Config vs State)
4. Apply → Execute Changes + Update State
What happens internally at each phase matters for the exam:
- Init — Downloads dependencies, configures backend, prepares working directory
- Plan — Reads state, compares to configuration, generates execution plan
- Apply — Executes plan, calls provider APIs, updates state file
Critical exam insight: Terraform never skips phases automatically. If you haven’t run init, you cannot run plan. If you haven’t initialized providers, Terraform cannot calculate changes.
terraform init — What It Actually Does
terraform init prepares the working directory. It does not provision infrastructure. This distinction is tested repeatedly.
What init actually does:
| Action | What Happens | Exam Relevance |
|---|---|---|
| Backend Initialization | Configures where state is stored | Required before any operations |
| Provider Download | Downloads provider plugins to .terraform/ | Providers must exist before plan |
| Module Download | Fetches remote modules | New modules require re-init |
| Lock File Creation | Creates .terraform.lock.hcl | Ensures version consistency |
What init does NOT do:
- Does not validate configuration syntax
- Does not create or modify infrastructure
- Does not read or modify state
- Does not communicate with cloud provider APIs (except to download plugins)
Exam Trap
Questions may ask: “What happens when you run terraform init?” Wrong answers often include “provisions resources” or “validates configuration.” Init only prepares the environment—nothing more.
terraform plan — What It Actually Calculates
terraform plan generates an execution plan by comparing your configuration to the current state. It never executes changes.
The plan calculation process:
- Read the current state file (local or remote)
- Parse all configuration files
- Optionally refresh state (unless -refresh=false)
- Calculate the diff between desired state and current state
- Display planned actions (create, update, destroy)
Key exam concept: Plan compares configuration to state, not configuration to real infrastructure. If your state says a resource exists but the resource was deleted manually, plan doesn’t know until the next refresh.
Why plan is safe:
- Read-only operation—no API calls that modify resources
- Can be run repeatedly without side effects
- Output shows exactly what would happen, not what is happening
Exam Signal
When a question asks “which command shows changes without modifying infrastructure?” the answer is always plan. Apply with -refresh-only only updates state—it doesn’t show a change preview.
terraform apply — Execution Reality
terraform apply is the only command that modifies infrastructure. Understanding its behavior is critical for exam success.
What apply actually does:
- Generates an execution plan (unless a saved plan is provided)
- Prompts for confirmation (unless -auto-approve is set)
- Executes the plan by calling provider APIs
- Updates the state file after each successful resource operation
- Reports results
Apply behavior variations:
| Command | Behavior |
|---|---|
| terraform apply | Generates plan, prompts for approval, then executes |
| terraform apply -auto-approve | Skips confirmation prompt |
| terraform apply plan.out | Executes a saved plan file (no re-calculation) |
| terraform apply -refresh-only | Only updates state to match real infrastructure |
Exam insight: Apply updates state incrementally. If apply fails partway through, the state reflects the resources that were successfully created before the failure.
Frequently Misunderstood Commands
These commands appear in exam questions but their behavior is often confused:
terraform refresh
Updates state to match real infrastructure. Does not modify resources. As of Terraform 0.15+, apply -refresh-only is the recommended approach.
Exam relevance: Refresh reads from providers but writes only to state.
terraform destroy
Removes all resources tracked in state. Creates a plan to delete everything, then executes it. Resources not in state are unaffected.
Exam relevance: Destroy only affects resources Terraform knows about.
terraform validate
Checks configuration syntax and internal consistency. Does not access remote state or provider APIs. Requires init to have been run (needs provider schemas).
Exam relevance: Validate is syntax-only—it doesn’t check if resources can be created.
terraform fmt
Formats configuration files to canonical style. Does not validate or execute anything.
Exam relevance: Fmt is purely cosmetic—has no operational impact.
Classic Terraform Workflow Exam Traps
The exam deliberately presents scenarios that exploit workflow misconceptions:
Trap 1: “Init provisions infrastructure”
Reality: Init only downloads providers and configures backends. No resources are created until apply.
Trap 2: “Plan modifies resources”
Reality: Plan is read-only. It calculates what would change but executes nothing.
Trap 3: “Validate replaces plan”
Reality: Validate checks syntax. Plan calculates actual changes based on state. They serve different purposes.
Trap 4: “Apply works without init”
Reality: Apply requires providers to be initialized. Without init, Terraform cannot communicate with cloud APIs.
Trap 5: “Refresh replaces plan”
Reality: Refresh updates state. Plan shows the diff between config and state. Different operations entirely.
If You See This in a Question, Think This
Use these mental shortcuts for workflow questions:
Workflow Decision Framework
→ “Prepare working directory” = init
→ “Download providers/modules” = init
→ “Show what would change” = plan
→ “Calculate diff” = plan
→ “Execute changes” = apply
→ “Modify infrastructure” = apply
→ “Update state from reality” = refresh / apply -refresh-only
→ “Remove all tracked resources” = destroy
→ “Check syntax” = validate (requires init first)
Frequently Asked Questions
Do I need to run terraform init every time?
No. You only need to run init when: (1) setting up a new working directory, (2) adding new providers, (3) adding new modules, or (4) changing backend configuration. Once initialized, you can run plan/apply repeatedly without re-initializing.
Does terraform plan change infrastructure?
No. Plan is completely read-only. It reads your configuration and state, calculates what would change, and displays the results. No provider APIs are called to modify resources. You can run plan as many times as you want safely.
Can terraform apply run without plan?
Yes, but apply generates a plan internally. When you run terraform apply without a saved plan file, Terraform first calculates the plan, shows it to you, and asks for confirmation before executing. The plan step is embedded in apply.
What happens if I skip terraform init?
Terraform will fail with an error. Without init, there are no provider plugins to execute operations. The error message will indicate that the working directory is not initialized and suggest running terraform init.
What’s the difference between refresh and plan?
Refresh updates the state file to match real infrastructure (reading from providers). Plan compares your configuration to the state and shows what would change. Refresh answers “what exists?” while plan answers “what should change?”
Reframe and Prepare
If workflow questions caused problems in your exam, the issue isn’t command knowledge—it’s command boundary knowledge. You use these commands daily, but the exam requires understanding exactly where one command’s responsibility ends and another’s begins.
The path forward is to stop thinking of init/plan/apply as a single workflow and start thinking of them as three distinct tools with specific, non-overlapping jobs.
Structured practice helps. Platforms like Certsqill present scenarios where you must identify which command handles which responsibility—training you to think in Terraform phases rather than memorized sequences.