Infrastructure as code (IaC) means you define servers, databases, networks, and permissions in text files instead of manual clicks. Terraform is the most common tool for this across AWS, Azure, and Google Cloud. You write what you want, run `terraform plan` to preview changes, and `terraform apply` to make them real.
Why bother? Repeatability is the big win. Staging should look like production — same firewall rules, same instance types, same tags. When everything lives in Git, you can see who changed what, roll back mistakes, and spin up a new environment in minutes instead of days of tribal knowledge.
A basic Terraform project has provider blocks (which cloud you use), resource blocks (what to create), and variables (sizes, names, regions). Teams often split files by concern — network.tf, database.tf, compute.tf — and use modules to reuse patterns. "Standard web app stack" becomes a module you call with a few inputs.
The workflow mirrors normal software. Open a branch, edit Terraform, open a pull request, let CI run `plan` and post the diff, merge, then apply in a controlled pipeline. No more "only Sarah knows how prod networking works." That alone prevents a lot of 2 a.m. panic.
Terraform is not the only option. AWS CloudFormation is AWS-only. Pulumi lets you use Python or TypeScript. Ansible handles configuration after machines exist. Many teams use Terraform for cloud resources and something else for app deploys. The principle matters more than the brand: automate, version, review.
Start small. Pick one non-critical resource — a test bucket, a dev database, a single VM — and manage it with Terraform. Break things in a sandbox, read the error messages, and learn `state` and `import` before you touch production. IaC pays off fast once your cloud footprint grows beyond what one person can remember.