Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files rather than physical hardware configuration or interactive configuration tools. IaC enables teams to version, test, and deploy infrastructure with the same rigor applied to application code, transforming infrastructure management from a manual, error-prone process into an automated, repeatable one. A key distinction in IaC is between declarative approaches (defining desired end state) and imperative approaches (defining step-by-step procedures)—understanding when to use each fundamentally shapes how infrastructure is designed, validated, and evolved over time.
What This Cheat Sheet Covers
This topic spans 13 focused tables and 124 indexed concepts, 119 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core IaC Concepts
Foundational IaC vocabulary — understanding the difference between declarative vs. imperative, mutable vs. immutable, and why state matters — shapes every architectural decision downstream.
| Concept | Example | Description | |
|---|---|---|---|
resource "aws_instance" "web" { ami = "ami-12345" instance_type = "t2.micro"} | • Specify desired end state • the IaC tool determines how to achieve it, handling resource creation, updates, and dependencies automatically | ||
- name: Install nginx apt: name: nginx state: present | • Define step-by-step instructions • the tool executes commands in sequence, giving precise control but requiring explicit dependency management | ||
terraform apply (run 10 times → same result) | • Running the same configuration multiple times produces the same result • prevents duplicate resources and ensures consistent infrastructure state | ||
ami_id = data.aws_ami.latest.id | • Servers are never modified after deployment • updates create entirely new instances, eliminating configuration drift and enabling reproducibility | ||
terraform { backend "s3" { bucket = "tfstate" }} | • Tracks the current state of infrastructure • essential for detecting drift, planning changes, and enabling team collaboration | ||
terraform plan -refresh-only | • Identifies discrepancies between actual infrastructure and code-defined state • crucial for maintaining compliance and catching manual changes | ||
Git commit → ArgoCD sync → deployment | • Git repository serves as the single source of truth • automated systems continuously reconcile infrastructure to match repository state | ||
deny[msg] { input.instance_type == "t3.large" msg = "Use t3.medium max"} | • Define governance rules in code (using OPA, Sentinel, Checkov) • automatically enforce security, compliance, and cost policies before deployment | ||
module "vpc" { source = "./modules/vpc" cidr = "10.0.0.0/16"} | • Reusable components that encapsulate infrastructure patterns • promote consistency, reduce duplication, and enable sharing across teams | ||
terraform workspace select prod | • Manage multiple environments (dev, staging, prod) from the same codebase • each workspace maintains separate state for isolation | ||
backend "azurerm" { storage_account_name = "tfstate" container_name = "state"} | • Store state files in centralized backends (S3, Azure Blob, GCS, Terraform Cloud) • enables team collaboration, state locking, and disaster recovery | ||
data "aws_ami" "ubuntu" { most_recent = true owners = ["099720109477"]} | • Query existing infrastructure managed outside current configuration • enables dynamic lookups and integration with external systems |