Infrastructure as Code
Infrastructure as Code (IaC) is the practice of provisioning and managing infrastructure using code rather than command-line tools or ClickOps GUIs. Beyond the mechanics of setting up systems, IaC is fundamentally about applying the principles, practices, and tools of software engineering to infrastructure — version control, code review, automated testing, and continuous delivery, all applied to the cloud.
Why Infrastructure as Code?
Section titled “Why Infrastructure as Code?”Before IaC, infrastructure was managed manually. Servers were configured by hand, environments were documented in wikis that fell out of date immediately, and the difference between staging and production was tribal knowledge. Reproducing a broken environment took days. Recovering from a failure took longer.
IaC solves this by collapsing that gap between what should exist and what does exist:
| Benefit | What it means in practice |
|---|---|
| Repeatability | The same code, run twice, produces identical infrastructure. No more snowflake servers or “it works on my machine” environments. |
| Reusability | Modular building blocks can be shared across teams. One team’s battle-tested VPC module becomes everyone’s VPC module. |
| Shareability | Code lives in Git — reviewable, forkable, versioned. Infrastructure decisions are documented by the commit that made them. |
| Auditability | Every infrastructure change has a commit, a PR, and a deployment record. Compliance questions become a git log. |
| Recovery speed | Environments can be recreated from scratch in minutes. Disaster recovery becomes a pipeline run, not a multi-day manual operation. |
The Three Core Practices
Section titled “The Three Core Practices”IaC rests on three practices that define whether a team is actually doing IaC or just using a IaC toola:
- Define everything as code
- Continually test and deliver all work in progress
- Build small, simple pieces that can change independently
These aren’t best practices — they’re the baseline. Full detail in IaC Principles.
The IaC Stack
Section titled “The IaC Stack”IaC is not one tool — it’s a stack of concerns, each layer handled by different tooling:
| Layer | What it manages | GCP / Common tools |
|---|---|---|
| Provisioning | Creating and maintaining cloud resources (VMs, networks, databases, IAM) | Terraform, Pulumi, Cloud Foundation Toolkit |
| Configuration management | What runs on existing servers after provisioning | Ansible, OS Config, Cloud Init |
| Container orchestration | Deploying workloads to clusters | GKE + Argo CD, Helm, Kustomize |
| CI/CD | Automating IaC changes through a delivery pipeline | Cloud Build, GitHub Actions, Atlantis |
| Policy enforcement | Validating that all resources meet security and compliance standards | Checkov, OPA/Conftest, GCP Org Policy |
| Observability | Detecting when real infrastructure drifts from its declared state | terraform plan -refresh-only, Security Command Center |
IaC and CI/CD
Section titled “IaC and CI/CD”IaC and CI/CD are the same discipline applied to different artifacts — the pipeline validates and deploys infrastructure code the same way it validates and deploys application code. The critical difference is that infrastructure artifacts are stateful and slow to provision, which shapes every decision from test strategy to deployment sequencing. See IaC & CI/CD for the full pipeline setup.