Why the workflow matters in Terraform - Why It Works This Way

Overview - Why the workflow matters

What is it?

A workflow in Terraform is the set of steps you follow to create, change, and manage your cloud infrastructure safely and predictably. It guides how you write your code, check it, apply changes, and keep track of what exists. This process helps avoid mistakes and keeps your infrastructure organized. Without a good workflow, managing cloud resources can become confusing and error-prone.

Why it matters

Without a proper workflow, changes to cloud infrastructure can cause unexpected outages, lost data, or security risks. A good workflow ensures that updates are tested and reviewed before applying, reducing downtime and mistakes. It also helps teams work together smoothly, avoiding conflicts and confusion. This means your cloud systems stay reliable and safe, which is critical for any business or project.

Where it fits

Before learning about workflows, you should understand basic Terraform concepts like configuration files, providers, and resources. After mastering workflows, you can explore advanced topics like modules, state management, and automation with CI/CD pipelines. Workflows connect the basics of writing infrastructure code to the real-world practice of managing cloud environments safely.

Mental Model

Core Idea

A Terraform workflow is like a recipe that ensures every change to your cloud infrastructure is made carefully, tested, and tracked to avoid surprises.

Think of it like...

Imagine baking a cake: you follow a recipe step-by-step, checking ingredients and timing to make sure the cake turns out right. Skipping steps or guessing can ruin the cake. Similarly, a Terraform workflow guides you through safe steps to build and change your cloud setup.

┌───────────────┐
│ Write Config  │
└──────┬────────┘
       │
┌──────▼────────┐
│ terraform fmt │
│ (format code) │
└──────┬────────┘
       │
┌──────▼────────┐
│ terraform plan│
│ (preview)     │
└──────┬────────┘
       │
┌──────▼────────┐
│ terraform apply│
│ (make changes) │
└──────┬────────┘
       │
┌──────▼────────┐
│ terraform state│
│ (track state)  │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Terraform Configuration Basics

Concept: Learn what Terraform configuration files are and how they describe cloud resources.

Terraform uses simple text files to describe what cloud resources you want, like servers or databases. These files use a clear language to say what you want, not how to do it. This is the starting point for any workflow.

Result

You can write a basic Terraform file that defines a resource, like a virtual machine.

Knowing how to write configuration files is the foundation for managing infrastructure with Terraform.

2

Foundation

Introducing Terraform State Management

Concept: Understand how Terraform keeps track of your real cloud resources using state files.

Terraform saves information about your cloud resources in a state file. This file helps Terraform know what exists and what needs to change when you update your configuration. Without state, Terraform wouldn't know the difference between new and existing resources.

Result

Terraform can compare your desired setup with the actual cloud setup and plan changes accordingly.

State management is crucial because it connects your code to the real world, enabling safe updates.

3

Intermediate

The Role of terraform plan in Workflow

🤔Before reading on: do you think terraform plan changes your cloud resources or just shows what would change? Commit to your answer.

Concept: Learn how terraform plan previews changes without applying them.

The terraform plan command looks at your current state and configuration files, then shows what changes would happen if you applied them. It does not change anything yet. This step helps you catch mistakes before they affect your cloud.

Result

You get a clear list of planned changes, helping you decide if they are safe to apply.

Using terraform plan prevents surprises by letting you review changes before making them.

4

Intermediate

Applying Changes Safely with terraform apply

🤔Before reading on: do you think terraform apply always makes changes immediately or can it be paused for review? Commit to your answer.

Concept: Understand how terraform apply executes the planned changes to your cloud.

After reviewing the plan, terraform apply carries out the changes to your cloud resources. It updates the state file to reflect the new reality. This step must be done carefully to avoid unintended disruptions.

Result

Your cloud infrastructure matches your configuration files, and state is updated.

Applying changes only after planning ensures controlled and predictable infrastructure updates.

5

Intermediate

Formatting and Validating Code with terraform fmt and validate

Concept: Learn how to keep your code clean and error-free before planning or applying.

terraform fmt automatically formats your configuration files to a standard style, making them easier to read and share. terraform validate checks your files for syntax errors and basic mistakes before you run plan or apply.

Result

Your code is clean, consistent, and free of simple errors, reducing risks during deployment.

Maintaining clean and valid code is a simple step that prevents many common errors in workflows.

6

Advanced

Managing State Remotely for Team Collaboration

🤔Before reading on: do you think storing state locally is safe for teams or does it cause problems? Commit to your answer.

Concept: Explore how remote state storage enables multiple people to work together safely.

When multiple people work on the same infrastructure, storing state files on a shared remote backend (like AWS S3 or Terraform Cloud) prevents conflicts and overwrites. It also enables locking so only one person changes infrastructure at a time.

Result

Teams can collaborate without accidentally breaking infrastructure or losing track of changes.

Remote state management is key to scaling Terraform workflows beyond solo projects.

7

Expert

Automating Workflows with CI/CD Pipelines

🤔Before reading on: do you think manual terraform apply is enough for production or automation adds value? Commit to your answer.

Concept: Learn how to integrate Terraform commands into automated pipelines for safer, faster deployments.

CI/CD pipelines run terraform fmt, validate, plan, and apply automatically when code changes. They can require approvals before applying and keep logs of all changes. This automation reduces human error and speeds up infrastructure updates.

Result

Infrastructure changes happen reliably and consistently, with audit trails and team controls.

Automation transforms Terraform workflows from manual tasks into robust, repeatable processes essential for production.

Under the Hood

Terraform reads your configuration files and compares them to the current state stored in a state file. The plan step calculates a difference (called a 'diff') between desired and actual resources. When you apply, Terraform uses cloud provider APIs to create, update, or delete resources to match the desired state. The state file is updated after changes to keep track of the real infrastructure. Remote state backends add locking and versioning to prevent conflicts.

Why designed this way?

Terraform was designed to treat infrastructure as code, enabling repeatable and predictable changes. The workflow separates planning from applying to avoid surprises. State files track real resources because cloud APIs do not provide a simple way to get full infrastructure snapshots. Remote state and automation evolved to support team collaboration and production reliability.

┌───────────────┐       ┌───────────────┐
│ Configuration │──────▶│ terraform fmt │
└──────┬────────┘       └──────┬────────┘
       │                       │
       │                       ▼
       │               ┌───────────────┐
       │               │ terraform validate│
       │               └──────┬────────┘
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ terraform plan│──────▶│ terraform apply│
└──────┬────────┘       └──────┬────────┘
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ State file    │◀──────│ Cloud Provider│
│ (local/remote)│       │ APIs          │
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does terraform plan change your cloud resources? Commit to yes or no.

Common Belief: terraform plan actually makes changes to your cloud infrastructure.

Reality: terraform plan only shows what changes would happen; it does not change anything.

Why it matters: Believing plan changes resources can cause people to skip the apply step or misunderstand the workflow, leading to confusion and errors.

Quick: Is it safe for multiple people to edit Terraform state files stored locally? Commit to yes or no.

Common Belief: Storing state files locally is fine for teams working together.

Reality: Local state files cause conflicts and overwrites when multiple people work together; remote state with locking is needed.

Why it matters: Ignoring remote state leads to lost changes, infrastructure drift, and potential outages in team environments.

Quick: Does terraform apply always require manual approval? Commit to yes or no.

Common Belief: terraform apply must always be run manually to avoid mistakes.

Reality: terraform apply can be automated safely in CI/CD pipelines with proper controls and approvals.

Why it matters: Thinking manual apply is the only safe way limits automation benefits and slows down infrastructure delivery.

Quick: Does terraform fmt change how your infrastructure behaves? Commit to yes or no.

Common Belief: terraform fmt can change the actual cloud resources by modifying configuration files.

Reality: terraform fmt only formats code style; it does not affect infrastructure behavior or resources.

Why it matters: Misunderstanding this can cause unnecessary fear or skipping of code formatting, leading to messy and error-prone configurations.

Expert Zone

1

State locking is critical in team environments to prevent simultaneous conflicting changes, but not all backends support it equally.

2

Terraform's plan output can be saved and reviewed or used in automation to ensure the exact changes applied match the reviewed plan.

3

Drift detection is not automatic; teams must run terraform plan regularly to detect changes made outside Terraform.

When NOT to use

Manual workflows are not suitable for large teams or frequent changes; instead, use automated CI/CD pipelines with remote state. For very simple or one-off tasks, manual apply might be enough, but it risks human error.

Production Patterns

Teams use branching strategies in version control to manage infrastructure changes, with pull requests triggering terraform plan and reviews. Approved changes trigger automated terraform apply in pipelines. Remote state backends with locking and versioning ensure safe collaboration.

Connections

Version Control Systems (e.g., Git)

Terraform workflows build on version control to track infrastructure code changes.

Understanding version control helps grasp how infrastructure changes are proposed, reviewed, and tracked before applying.

Continuous Integration/Continuous Deployment (CI/CD)

Terraform workflows integrate with CI/CD pipelines to automate infrastructure delivery.

Knowing CI/CD concepts clarifies how Terraform commands can be automated for safer, faster cloud updates.

Project Management and Change Control

Terraform workflows align with change control processes to ensure safe infrastructure updates.

Understanding change control helps appreciate why planning, reviewing, and approval steps in Terraform workflows are essential.

Common Pitfalls

#1 Applying changes without reviewing the plan first.

Wrong approach:

terraform apply

Correct approach:

terraform plan
# Review output
terraform apply

Root cause:

Skipping the plan step leads to unexpected changes and potential outages.

#2 Storing state files locally when working in a team.

Wrong approach:

terraform init
# default local state
terraform apply

Correct approach:

terraform init -backend-config="bucket=my-remote-state"
terraform apply

Root cause:

Not configuring remote state causes conflicts and lost updates in team environments.

#3 Not formatting or validating code before applying.

Wrong approach:

terraform apply

Correct approach:

terraform fmt
terraform validate
terraform plan
terraform apply

Root cause:

Skipping code checks increases risk of syntax errors and inconsistent configurations.

Key Takeaways

A Terraform workflow is essential to manage cloud infrastructure safely and predictably.

Separating planning and applying steps prevents unexpected changes and outages.

State files track real resources and must be managed carefully, especially in teams.

Automation and remote state enable collaboration and faster, reliable infrastructure updates.

Skipping workflow steps or misunderstandings can cause serious errors and downtime.

Practice

1. Why is it important to run terraform plan before terraform apply?

easy

A. It shows the changes Terraform will make before applying them

B. It automatically applies changes without confirmation

C. It deletes all existing resources immediately

D. It skips validation of the configuration files

Solution

1. Step 1: Understand the purpose of terraform plan

   This command previews the changes Terraform will make to your infrastructure without applying them.

2. Step 2: Compare with terraform apply

   terraform apply actually makes the changes, so planning first helps avoid mistakes.

3. Final Answer:

   It shows the changes Terraform will make before applying them -> Option A

4. Quick Check:

   Plan previews changes = D [OK]

Hint: Plan first to preview changes, avoid surprises [OK]

Common Mistakes:

• Skipping plan and applying directly
• Thinking plan applies changes
• Confusing plan with destroy

2. Which command correctly initializes a Terraform working directory before planning or applying?

easy

A. terraform init

B. terraform start

C. terraform deploy

D. terraform configure

Solution

1. Step 1: Identify the initialization command

   terraform init sets up the working directory by downloading providers and preparing backend.

2. Step 2: Check other options

   Commands like terraform start, deploy, or configure do not exist in Terraform.

3. Final Answer:

   terraform init -> Option A

4. Quick Check:

   Initialize with init = B [OK]

Hint: Init first to prepare your workspace [OK]

Common Mistakes:

• Using non-existent commands
• Trying to apply before init
• Confusing init with plan

3. Given this Terraform workflow:

terraform init
tf plan
tf apply

What will happen if you run terraform apply without running terraform plan first?

medium

A. Terraform will apply changes immediately without preview

B. Terraform will show an error and stop

C. Terraform will automatically run plan before apply

D. Terraform will delete all resources

Solution

1. Step 1: Understand terraform apply behavior

   Terraform always performs an internal plan, shows the execution plan (preview of changes), and prompts for confirmation before applying.

2. Step 2: Check if plan is mandatory

   Running terraform plan first is recommended for detailed review and saving plans, but terraform apply automatically runs the plan step.

3. Final Answer:

   Terraform will automatically run plan before apply -> Option C

4. Quick Check:

   Apply auto-runs plan [OK]

Hint: Apply always plans first internally [OK]

Common Mistakes:

• Assuming apply always errors without plan
• Thinking apply auto-runs plan silently
• Believing apply deletes resources by default

4. You ran terraform apply but noticed unexpected resource deletions. What is the most likely cause related to workflow?

medium

A. Running terraform init twice

B. Skipping terraform plan and not reviewing changes

C. Using an outdated Terraform version

D. Not setting environment variables

Solution

1. Step 1: Identify workflow mistake

   Skipping terraform plan means you miss previewing changes, leading to surprises like deletions.

2. Step 2: Evaluate other options

   Running init twice, outdated version, or missing env vars usually cause errors, not unexpected deletions.

3. Final Answer:

   Skipping terraform plan and not reviewing changes -> Option B

4. Quick Check:

   Skip plan = risk of unwanted deletions [OK]

Hint: Always plan and review before applying [OK]

Common Mistakes:

• Ignoring plan output
• Blaming init for deletions
• Assuming version causes deletions

5. You want to safely update your cloud infrastructure with Terraform. Which workflow sequence best prevents downtime and mistakes?

hard

A. terraform plan -> terraform apply -> terraform init

B. terraform apply -> terraform plan -> terraform init

C. terraform apply -> terraform init -> terraform plan

D. terraform init -> terraform plan -> review plan -> terraform apply

Solution

1. Step 1: Understand the correct workflow order

   First, terraform init prepares the workspace, then terraform plan previews changes, followed by reviewing the plan carefully.

2. Step 2: Apply changes only after review

   Applying changes after review ensures safety and avoids downtime or mistakes.

3. Final Answer:

   terraform init -> terraform plan -> review plan -> terraform apply -> Option D

4. Quick Check:

   Init, plan, review, apply = C [OK]

Hint: Init, plan, review, then apply for safe updates [OK]

Common Mistakes:

• Applying before planning
• Skipping plan review
• Running commands in wrong order