Skip to main content
Welcome — in this lesson you’ll learn the core Terraform workflow for managing cloud infrastructure reliably and repeatably. Terraform (Infrastructure as Code) uses HashiCorp Configuration Language (HCL) to declare desired resource state, then reconciles real infrastructure to match that state. A concise, consistent workflow reduces drift, eases reviews, and enables safe automation with CI/CD. Core workflow steps (high level)
  • Write configuration: define resources and desired state in .tf files (HCL).
  • Initialize the workspace: download provider plugins and configure the backend.
  • Plan changes: generate an execution plan that previews changes.
  • Apply changes: execute the plan to change real infrastructure.
  • Destroy (optional): remove infrastructure created by Terraform.
Each step exists to make infrastructure changes deliberate and auditable. In practice you should also: manage state (local or remote), use version control for configurations, review plans before applying, and integrate Terraform into CI/CD.
Always review a terraform plan output (or plan file) before running terraform apply. Plans are your primary safety check to avoid unintended changes.
Common commands summary
# Initialize the working directory (downloads providers, sets up backend)
terraform init

# Create and show an execution plan (safe preview of changes)
terraform plan

# Apply the planned changes (prompts for approval by default)
terraform apply

# Tear down managed infrastructure
terraform destroy
Workflow details, commands, and best practices
  • Use version control (Git) for all Terraform code. Treat .tf files as the canonical source of truth.
  • Prefer remote state backends (e.g., S3 with DynamoDB locking, Terraform Cloud/Enterprise) for team collaboration and state locking.
  • Use terraform plan -out=plan.tfplan then terraform apply "plan.tfplan" to guarantee the apply exactly matches the reviewed plan.
  • Protect secrets: avoid committing plaintext secrets. Use environment variables, secret managers, or encrypted variables in CI/CD.
Step-by-step breakdown
  1. Write configuration
  • Create .tf files to declare providers, resources, variables, outputs, and modules.
  • Use modules to encapsulate reusable infrastructure patterns.
  • Keep environment-specific values out of code; pass them via variables, variable files (-var-file), or a workspace-specific backend.
  • Example:
provider "aws" {
  region = var.aws_region
}

resource "aws_s3_bucket" "app_bucket" {
  bucket = var.bucket_name
  acl    = "private"
}
  1. Initialize the workspace (terraform init)
  • Downloads provider plugins and modules.
  • Configures the backend (local or remote).
  • Useful flags:
    • -backend-config=FILE to supply backend configuration.
    • -reconfigure to ignore existing backend configuration and reinitialize.
  • Example:
terraform init -backend-config="bucket=my-terraform-state" -reconfigure
  1. Plan changes (terraform plan)
  • Produces an execution plan showing what will be created, changed, or destroyed.
  • Common flags:
    • -out=plan.tfplan to save the plan for later apply.
    • -var='key=value' or -var-file=prod.tfvars to inject variables.
    • -refresh=true|false to control state refresh.
  • Best practice: always run terraform plan and review the diff before applying.
  1. Apply changes (terraform apply)
  • Apply can accept a saved plan file or run a fresh plan interactively.
  • Typical usage:
# Apply from a previously-saved plan
terraform apply "plan.tfplan"

# or run and apply in one step (prompts for confirmation)
terraform apply

# Non-interactive (CI)
terraform apply -auto-approve
  • Prefer using saved plan files in automated pipelines to ensure reproducibility.
  1. Destroy (terraform destroy)
  • Safely tear down infrastructure that Terraform manages.
  • Use with caution; consider -target or manual safeguards if you only want to remove specific resources.
terraform destroy
terraform destroy -target=aws_instance.example
State management and locking
  • State is critical: it maps your Terraform configuration to real resources.
  • Use remote backends for team environments:
    • S3 + DynamoDB (AWS) for state storage + locking
    • Terraform Cloud or Terraform Enterprise for integrated state, locking, runs, and policy
  • Encrypt state at rest and limit access.
  • Avoid manual edits to state; use terraform state subcommands only when necessary.
Workspaces, environments, and branching
  • Use separate workspaces (or separate backends/states) per environment (dev, staging, prod).
  • Common pattern: separate IaC repos or directories for distinct lifecycles; or use variable files and CI/CD pipelines that target specific backends.
  • Prefer distinct state per environment rather than relying on a single workspace to hold multiple unrelated resources.
CI/CD integration
  • Create pipelines that:
    1. Run terraform fmt and terraform validate
    2. Run terraform plan -out=plan.tfplan and publish plan output for review
    3. On approval, run terraform apply plan.tfplan (non-interactive)
  • Store backend secrets and provider credentials in the CI secret store.
  • Lock and version provider/plugins by using the required_providers block and terraform lock file.
Common Commands and Useful Flags
CommandPurposeExample
terraform initInitialize directory, download providers, configure backendterraform init -backend-config="bucket=team-state"
terraform planPreview changes without applyingterraform plan -out=plan.tfplan -var-file=prod.tfvars
terraform applyApply changes to reach desired stateterraform apply "plan.tfplan"
terraform destroyRemove managed infrastructureterraform destroy -auto-approve
terraform fmtReformat HCL filesterraform fmt -recursive
terraform validateValidate configuration syntaxterraform validate
Security and operations callouts
Sensitive data can end up in Terraform state. Do not store secrets in plaintext variables that are committed to version control. Use secure secret management and encrypted backends.
Links and references Next steps
  • We’ll next walk through an example repository: initialize a backend, write a small module, run a plan, and apply safely in a CI pipeline. You’ll get hands-on practice with state locking, plan-review workflow, and best practices for team collaboration.

Watch Video