Infrastructure as Code (IaC) means describing servers, networks, databases and permissions in text files, and letting a tool create them. The files live in Git, like application code.
Without IaC ("ClickOps"), people click around the cloud console:
- Nobody knows exactly how production was built, so staging never quite matches it.
- Changes are not reviewed, and there is no history of who changed what.
- Rebuilding after a disaster means remembering hundreds of clicks.
- Every hand-built server is a slightly different snowflake.
With IaC:
| Benefit | What it means |
|---|---|
| Repeatable | Create dev, staging and prod from the same code |
| Reviewable | Changes go through pull requests |
| Traceable | Git history shows who changed what, and why |
| Recoverable | Rebuild an environment by running the code again |
| Automatable | Run it from a CI/CD pipeline |
Common tools
| Tool | Notes |
|---|---|
| Terraform / OpenTofu | Works with many clouds and services (via providers) |
| AWS CloudFormation | AWS-native, YAML/JSON templates |
| Azure Bicep / ARM templates | Azure-native |
| Pulumi | IaC in general-purpose languages (TypeScript, Python, Go) |
Provisioning vs configuration. Terraform creates infrastructure (VPC, VM, database). A configuration tool like Ansible sets up what runs on a server (packages, files, services). Teams often use both.
The trap: IaC only helps if people stop making manual changes. A quick fix in the console makes the code wrong (this is called drift).
In interviews: "Why IaC?" Give three words: repeatable, reviewable, recoverable.