Intro to the Terraform Workflow

Terraform’s official workflow, as documented by HashiCorp, is intentionally simple and consistent. Whether you’re provisioning a single VM or orchestrating resources across multiple clouds, you’ll follow the same high-level pattern. Core stages:

Write — declare the desired end state in configuration files using HCL.
Initialize (init) — prepare the working directory and download required provider plugins and modules.
Plan — preview the changes Terraform will make by comparing configuration to the current real-world state.
Apply — execute the changes to make the real infrastructure match your configuration.

Practically, the common day-to-day sequence is: write → init → plan → apply

A purple slide titled "Terraform Workflow" showing a four-step flow: Write Configuration (HCL) → Initialize → Plan → Apply. Each step is depicted with a square icon (document/pencil, gears, checklist, crane) connected by arrows.

This lesson explains each step so you understand what Terraform is doing at each point in the lifecycle. Summary of commands

Stage	Command	Purpose
Initialize	`terraform init`	Install provider plugins, download modules, and configure the backend (required before plan/apply).
Plan	`terraform plan` or `terraform plan -out=plan.tfplan`	Show proposed changes (create/update/destroy) without making them. Optionally save plan to a file.
Apply	`terraform apply` or `terraform apply plan.tfplan`	Execute API calls to create/update/delete resources to match the configuration.
Write (develop)	n/a	Author `.tf` files using HCL to declare desired infrastructure state.

Initialize (init) Terraform init prepares a working directory for use with Terraform. It:

Reads your configuration to determine required provider plugins and modules.
Downloads those providers and modules into the local cache.
Configures the backend (where Terraform stores state) so Terraform can read and update state.

Run terraform init at the start of a project, after cloning a repository, or whenever you add/change providers or modules. Initialization typically completes in seconds but is required before running terraform plan or terraform apply.

Always run terraform init after cloning a repository or when adding/changing providers or modules. Terraform will prompt you if initialization is needed.

Plan Terraform plan is your preflight check. It:

Compares your HCL configuration to the current state tracked in the state file and to the provider APIs.
Calculates an execution plan and prints what will be created, updated, or destroyed.
Lets you inspect changes and catch mistakes before any API calls are made.

Common usage:

Preview changes: terraform plan
Save a plan to apply later: terraform plan -out=plan.tfplan

Review the plan output carefully, especially any resource deletions or large-scale changes. Apply Terraform apply executes the prepared plan and makes the API calls necessary to reconcile real infrastructure with your configuration. You can:

Apply interactively: terraform apply (Terraform will compute a plan and prompt before applying).
Apply a saved plan: terraform apply plan.tfplan (replays the exact saved plan).

Terraform evaluates the dependency graph and applies changes in the correct order (for example, creating network resources before instances). Use saved plan files (-out) when you want a reviewed, reproducible operation, or when running automated pipelines. Write — developing your configuration The write stage is where you author one or more Terraform configuration files (the .tf files) using HCL (HashiCorp Configuration Language). Key principles:

Declare the desired state, not the exact procedural steps. Describe resources and their attributes (e.g., VM size, region, tags).
Let Terraform compute the actions needed to reach that state.
Iterate: start small and expand your configuration (networks, security groups, load balancers, etc.) over time.
After changes, run terraform init if you added/changed providers or modules, then terraform plan and terraform apply.

Example minimal HCL

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "envs/prod/terraform.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami           = "ami-0123456789abcdef0"
  instance_type = "t3.micro"
  tags = {
    Name = "example-instance"
  }
}

Best practices while writing:

Keep configurations modular: use module blocks to reuse and encapsulate logic.
Use remote/state backends (e.g., S3, Terraform Cloud) for team collaboration.
Store sensitive values securely (use environment variables, Vault, or remote state encryption).
Version providers and modules explicitly to avoid unexpected upgrades.

A purple slide titled "Developing Terraform Configuration" that explains "What Does 'Develop Configuration' Mean?" and describes writing configuration files to define your desired infrastructure state. The slide features a cloud graphic, a binary icon, and notes that Terraform configurations are iterative and can be refined incrementally.

Repeat the cycle (init if required) → plan → apply as you evolve your infrastructure. Links and references

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Intro to the Terraform Workflow

Watch Video