Terraform Overview
Terraform is an open-source Infrastructure as Code (IaC) tool by HashiCorp. You describe your infrastructure in configuration files, and Terraform creates, updates, and deletes real resources (VMs, networks, databases, DNS records, etc.) to match.
Why Infrastructure as Code?
Section titled “Why Infrastructure as Code?”- Repeatable — Spin up identical environments (dev, staging, prod) from the same config.
- Version-controlled — Infrastructure changes go through the same Git workflow as application code: branches, pull requests, reviews.
- Self-documenting — The config files are the documentation of what’s deployed.
- Auditable — Every change is tracked in Git history and in Terraform’s state.
Why Terraform?
Section titled “Why Terraform?”- Cloud-agnostic — One tool for AWS, Azure, GCP, Kubernetes, Cloudflare, Datadog, GitHub, and hundreds more. Each cloud is supported through a provider.
- Declarative — You describe what you want (e.g. “an S3 bucket with versioning enabled”), not how to create it. Terraform figures out the steps.
- Plan before apply —
terraform planshows exactly what will change before anything happens. No surprises. - Dependency graph — Terraform understands resource dependencies and creates/destroys in the correct order automatically.
- State tracking — Terraform keeps a record of what it manages, so it knows the difference between “create new” and “update existing.”
Declarative vs Imperative
Section titled “Declarative vs Imperative”| Approach | Example | How It Works |
|---|---|---|
| Imperative | Shell scripts, CLI commands | ”Create a VPC, then create a subnet, then create an instance…” — you specify every step |
| Declarative | Terraform, CloudFormation | ”I want a VPC, a subnet, and an instance” — the tool figures out the order and steps |
Terraform is declarative. You describe the end state; Terraform computes the diff and applies it.
Terraform vs Alternatives
Section titled “Terraform vs Alternatives”| Tool | Approach | Scope |
|---|---|---|
| Terraform | Declarative, HCL | Multi-cloud, multi-service |
| CloudFormation | Declarative, JSON/YAML | AWS only |
| Pulumi | Declarative, general-purpose languages (Python, TypeScript, Go) | Multi-cloud |
| Ansible | Imperative (with declarative modules) | Configuration management + some provisioning |
| CDK (AWS) | Declarative via code, compiles to CloudFormation | AWS only |
Terraform’s strength is its provider ecosystem and its plan/apply workflow. It handles provisioning (creating infrastructure), while tools like Ansible handle configuration (setting up what’s on the machines).
Key Terminology
Section titled “Key Terminology”- Provider — A plugin that lets Terraform talk to a specific service (e.g.
aws,azurerm,google,kubernetes). - Resource — A single piece of infrastructure (e.g.
aws_instance,azurerm_resource_group,google_dns_record_set). - Data source — A read-only query to fetch existing infrastructure info (e.g. look up an AMI ID, get the current account ID).
- State — A JSON file that maps your config to real-world resources. Terraform uses it to know what exists.
- Module — A reusable group of resources packaged together (e.g. a “VPC module” that creates a VPC + subnets + route tables).
- Plan — A preview of what Terraform will do (create, update, destroy).
- Apply — Execute the plan and make real changes.
Topics in This Section
Section titled “Topics in This Section”Start with HCL syntax and the core workflow, then learn how Terraform tracks state. Modules and best practices build on that foundation.
- HCL Basics — Resources, variables, locals, data sources, expressions, type constraints, lifecycle meta-arguments, and dependencies.
- Core Workflow —
init,plan,apply,destroy, drift detection, and refresh-only mode. - AWS Provider — How Terraform gets AWS credentials (env vars, shared credentials, IAM roles) and what IAM permissions it needs.
- Azure Provider — How Terraform gets Azure credentials (env vars, Azure CLI, managed identity) and what RBAC permissions it needs.
- Google Cloud Provider — How Terraform gets GCP credentials (ADC, service account, Workload Identity) and what IAM permissions it needs.
- State — Remote backends, locking, state commands,
moved/removedblocks,terraform_remote_state, and import. - Modules — Reusable infrastructure packages, the Terraform Registry, and versioning.
- Provisioners and Functions — Built-in functions, provisioners, and when to avoid them.
- Best Practices — Directory layout, naming conventions, workspaces, CI/CD integration, and testing.