Operational Rule
Never treat terraform apply like a harmless command. It can create cost, delete resources, or change live networking. The plan step is where safe teams slow down on purpose.
Terraform Core Workflow
Learn the operational loop that every Terraform user needs: write configuration, initialize providers, inspect plans, apply safely, and destroy intentionally.
🧒 Simple Explanation (ELI5)
Terraform works like planning a house renovation before touching the building. First you gather tools, then review the blueprint, then execute the approved changes. The core workflow exists so you do not make blind infrastructure changes.
🤔 Why Do We Need It?
Infrastructure changes are expensive to undo. Terraform’s workflow forces deliberate steps so teams can see what will happen before resources are created, changed, or destroyed.
🔧 Technical Explanation
The Terraform CLI workflow is usually init → fmt → validate → plan → apply. In mature teams, destroy is used carefully and often only in temporary environments.
bash
terraform init terraform fmt terraform validate terraform plan terraform apply
| Command | Purpose | Notes |
|---|---|---|
terraform init | Downloads providers and initializes the working directory | Required before planning or applying |
terraform fmt | Formats configuration files | Keeps code consistent |
terraform validate | Checks syntax and internal consistency | Does not contact the cloud |
terraform plan | Shows proposed infrastructure changes | Critical review step |
terraform apply | Executes the approved changes | Should follow plan review |
terraform destroy | Deletes managed resources | Use carefully |
Terraform Execution Loop
Write .tf Files
→
Init
→
Plan
→
Apply
⚡
🌍 Real-World Use Case
A team provisioning Azure networking and AKS foundation would run plan in CI on every pull request, review the diff, then apply through an approved pipeline. That combines Terraform’s workflow with Azure DevOps or GitHub Actions release governance.
🛠️ Hands-on
Create Your First Terraform Directory
hcl
terraform {
required_version = ">= 1.6.0"
}
provider "azurerm" {
features {}
}Run the Core Commands
bash
terraform init terraform fmt terraform validate terraform plan
- Create a folder and save a minimal Terraform file.
- Run
terraform initto initialize the working directory. - Run
terraform fmtandterraform validate. - Run
terraform planto confirm the configuration is syntactically sound.
Try It Yourself
- Run
terraform fmt -checkto simulate CI formatting enforcement. - Compare validate and plan. Which one actually understands provider-backed infrastructure intent?
- Think about where an approval gate should exist before apply.
🐛 Debugging Scenario
Problem: terraform init fails before you even reach plan.
- Check Terraform version compatibility with the configuration.
- Verify internet or registry access for provider download.
- Check provider source names and syntax in the configuration.
⚠️
Common Mistake
New users sometimes skip plan and go straight to apply. That removes the most valuable safety mechanism Terraform provides.
📋 Interview Questions
Beginner
What does terraform init do?
It initializes the working directory, downloads required providers and modules, and prepares Terraform to run.
Why is terraform plan important?
It shows the exact changes Terraform wants to make so the team can review them before execution.
What is the difference between validate and plan?
Validate checks configuration correctness locally, while plan evaluates proposed infrastructure changes with provider context.
When would you use terraform destroy?
Usually for disposable environments, labs, or intentional teardown workflows, not casually against production.
Why run terraform fmt?
To keep configuration formatting consistent and review-friendly across a team.
Intermediate
How does the core workflow fit into CI/CD?
CI usually runs fmt, validate, and plan, while controlled release workflows handle approved applies.
Why should apply usually happen in automation for shared environments?
Automation improves auditability, approvals, consistency, and reduces the chance of local machine context causing risky changes.
What is a safe way to handle destroy in teams?
Restrict it to disposable environments, guard it with approvals, and avoid mixing it into normal production delivery workflows.
Why save a plan file in some pipelines?
So the exact reviewed plan can be applied later, reducing the chance that the infrastructure intent changed between review and execution.
How does this workflow reduce outages?
By forcing reviewable change visibility before infrastructure mutation and by encouraging safe operational discipline.
Scenario-Based
A teammate wants to apply directly from their laptop to production. What is your response?
I prefer production applies to run through controlled automation with reviewed plans, shared state access, and auditability rather than one-off laptop execution.
Plan shows a resource replacement you did not expect. What do you do?
I stop and investigate the reason before applying. Unexpected replacements can mean provider behavior, immutable fields, drift, or misconfigured lifecycle rules.
How do you explain the workflow to a junior engineer simply?
Prepare the toolchain, check the code, preview the change, then execute only after you understand what will happen.
A plan looks empty but you expected changes. What could be wrong?
You may be in the wrong directory or workspace, variables may differ from expectations, or the resources may not be represented in the current configuration.
Why is plan review especially important for networking and AKS resources?
Because changes to clusters, subnets, or dependencies can have broad production impact and may trigger replacements or downtime if misunderstood.
🧾 Summary
The Terraform core workflow is the safety rail that turns infrastructure code into safe infrastructure operations. Learn it well, because every advanced Terraform practice builds on this loop.