Infrastructure as Code
Beginner 13 min read Infrastructure as Code

IaC Principles

Stop molding cloud; start shipping it

IaC treats infrastructure as reviewable, repeatable, reversible artifacts: code in git, applied by pipelines, diffed against reality, and audited. The core win is reproducibility and blast-radius control, not just 'scripts for cloud'.

IaCreproducibilityimmutabledeclarativeterraformcloudformationpulumi
Before we start

What you will learn

  • Articulate why configuration is code, not a script
  • List IaC benefits: review, drift, rollback, audit
  • Place Terraform vs CloudFormation vs Pulumi vs solution-specific tools
In 60 seconds

Write what the infra should be; a tool figures out diffs and applies them. Code review gates changes, CI applies them, state/change records give rollback + audit. Push-button rebuild of an environment becomes a real option.

Introduction

What is this?

Tenets: declarative (desired state) vs imperative (steps); versioned in git; PR-driven; environments via same code + variables; drift detection vs manual tunnel-vision edits; idempotency (apply twice = same state); infrastructure rarely hand-touched as an exception. Tool spectrum: Terraform/OpenTofu (declarative, stateful), Pulumi (declarative with real languages), CloudFormation/SAM (AWS-native, stacks), CDK (AWS, TypeScript/Python), CDKTF, bicep (Azure), Deployment Manager (GCP), plus Helm (K8s charting), Ansible (config mgmt, procedural-configured). All share: source of truth → engine → real world.

Motivation

Why do you need it?

  • Repeatable rebuilds: stage/QA/prod from one tree, not a wiki page of clicks.
  • Review before change: pull requests gate infra edits like code edits.
  • Drift alarms replace 'who changed the security group at 2am?' archaeology.
  • Disaster recovery starts from code: rebuild a region from git, not from memory.
Think about it

Mental model

Imagine

An architect's blueprints vs a handyman improvising on site

Think of

IaC vs manual console clicking

Blueprints are reviewed, copied to any building site, and diffable against what was built; improvising works until it's 3 different buildings claiming to be the same.

Mechanics

How it works

  • You declare resources (VPC, SG, instance, role) with desired attributes.
  • The engine builds an execution plan comparing desired vs current (state).
  • Apply creates/destroys/reconfigures only what changed.
  • State (or the provider's picture) records reality for the next plan.
  • Pipelines run plan+apply on merge, with drift checks scheduled.

IaC loop.

Code
Plan
Review
Apply
State
Drift
Hands-on

Examples

Terraform's three verbs

Terraform's three verbs
terraform init # providers + modules
terraform plan # show diffs, no changes
terraform apply -auto-approve # converge
terraform destroy # teardown (blueprints taken down)
# plan output: plan: 3 to add, 1 to change

Plan shoulders the mental load; apply does only the delta; state keeps reality honest.

Real world

In production

  • Every environment bootstrapped from the same repo with per-env tfvars.
  • PR with CI plan: reviewers see an explicit add/change/delete list.
  • Scheduled drift scans; any out-of-band console change is an alert.
Guidelines

Best practices

  • Treat state as gold: remote-lock it, never edit by hand.
  • Small, cohesive modules/resources; one concern per PR.
  • Environments differ by variables, never by forking the tree.
  • Apply from pipelines with audited identities, not engineer laptops.
  • Destroy ephemeral environments on merge; recreate them on demand.
Watch out

Common mistakes

  • Terraform-in-the-console between PRs → the state reality gap.
  • Copy-pasting infrastructure between envs instead of variableizing.
  • Running apply past midnight with no review because 'it's just infra'.
  • State in git or a shared bucket without lock → concurrent clobbers.
When things break

Debugging tips

  • A resource you 'removed' still exists → check the state for the changed identity.
  • Plans that repeatedly recreate → immutable attributes or forces-new resource; rename to fix.
  • Review plan errors as diffs, not logs: read they are the 'what will change' signal.
  • Compare apply logs against the PR plan to catch environment-vars drift.
Interviews

Interview checkpoint

Practice

Hands-on lab

Provision a Tiny Stack Idempotently
40 min · beginner
In progress
Objectives
  • Write a small Terraform/OpenTofu config
  • Run plan/apply and observe idempotency
  • Apply, destroy, re-apply in a loop

Provision a Tiny Stack Idempotently

40 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which verb compares desired vs current without changing anything?

2

Drift means:

Go deeper

Official documentation