Terraform

Terraform is an infrastructure-as-code (IaC) tool that lets you define cloud and on-prem resources in declarative configuration files, version them in Git, and apply changes predictably. Instead of clicking through a console, you describe the infrastructure you want and Terraform makes the API calls to create it.

Its superpower is being provider-agnostic and declarative: one workflow (plan → apply) works across AWS, Azure, GCP, and a thousand other providers. You declare the end state; Terraform figures out the diff and how to get there.

TL;DR

• Define infrastructure declaratively in HCL; version it like code.
• plan previews changes; apply executes them.
• State is Terraform's record of reality — protect it (remote backend + locking).
• Terraform provisions; use Ansible/scripts to configure what's inside.

Quick Example

Declare a resource, preview, then apply — the diff is computed for you:

Core Concepts

• Provider — plugin that talks to an API (AWS, GCP, Azure, Cloudflare…).
• Resource — an infrastructure object (an S3 bucket, a VM).
• Module — a reusable bundle of resources.
• State — Terraform's mapping of config to real resources.
• Plan / Apply — preview then execute changes.

⚠️ The state file is critical. Lose it and Terraform no longer knows what it manages; it may try to recreate everything. Store it in a remote backend with locking.

State Management

State is the heart of Terraform — and its biggest footgun:

• Use a remote backend (S3 + DynamoDB lock, Terraform Cloud, GCS) so the team shares one state.
• Locking prevents two people applying at once and corrupting state.
• Never hand-edit state; use terraform state commands.
• Treat state as sensitive — it can contain secrets.

Best Practices

• Keep state remote with locking; one backend per environment.
• Always plan before apply and review the diff.
• Factor reusable infrastructure into modules; keep them small and composable.
• Separate environments (dev/staging/prod) with workspaces or directories.
• Pin provider versions for reproducible runs.

Comparison

See Pulumi and CloudFormation.

Common Mistakes

Local state on a team

Manual changes causing drift

FAQ

What is infrastructure as code?

Managing infrastructure (servers, networks, databases) through versioned configuration files instead of manual console clicks. It makes infrastructure reproducible, reviewable, and auditable — you can recreate an entire environment from code and track every change in Git.

Why is the Terraform state file so important?

State maps your configuration to the real resources Terraform created. It's how Terraform knows what already exists and what to change. Lose or corrupt it and Terraform can't reconcile reality — which is why production state lives in a locked, remote backend.

Terraform or Pulumi or CloudFormation?

Terraform for multi-cloud with a mature ecosystem and declarative HCL. CloudFormation if you're all-in on AWS and want AWS-managed state. Pulumi if you'd rather define infrastructure in a general-purpose language (TypeScript, Python). All do IaC well; choose by cloud scope and language preference.

Does Terraform configure servers too?

No — Terraform provisions infrastructure (creates the VM), but it doesn't configure what runs inside it. Use configuration management (Ansible, Chef) or container images for that. Keep provisioning and configuration as separate concerns.

Related Topics

• Infrastructure as Code — The broader practice
• Pulumi — IaC in general-purpose languages
• CloudFormation — AWS-native IaC
• Ansible — Configuration management
• Kubernetes — Often provisioned by Terraform

References

• Terraform — Documentation
• Terraform — State
• Terraform — Modules
• Terraform — Best practices