Infrastructure as Code - System Design Guide

Overview

Infrastructure as Code (IaC) defines servers, networks, databases, and permissions in version-controlled files instead of clicking in consoles. Tools read the code, compare it with the real infrastructure, and create, update, or delete resources to match. Declarative tools (Terraform, CloudFormation, Pulumi) describe the desired end state.

IaC makes infrastructure reproducible (identical staging and production), reviewable (pull requests), auditable (git history), and recoverable (rebuild after disaster). It is usually applied through CI/CD pipelines with plan previews, policy checks, and remote state with locking.

Architectural blueprints

Instead of telling builders what to do on site each day, you hand them blueprints. Anyone can build the same house again from the blueprints, and changes are reviewed on paper before construction.

When to use it

Any cloud infrastructure beyond experiments.
Multiple environments that must stay consistent.
Compliance and audit requirements.
Disaster recovery and region replication.

Where it shows up in interviews

Reproducible environments

Recognize it when: staging and production drift.

Design a platform for 50 microservices
Set up multi-region DR

Governed changes

Recognize it when: infrastructure changes need review and audit.

Design a compliant cloud landing zone

Where it is used in real software

Terraform

The most widely used multi-cloud IaC tool, with providers for AWS, Azure, GCP, Kubernetes, and SaaS.

AWS CloudFormation and CDK

AWS-native templates; CDK lets you write them in TypeScript, Python, or Java.

Pulumi

IaC in general-purpose languages with the same desired-state model.

Key terms

Declarative: Describe what you want; the tool figures out how.
State: Record of managed resources and their IDs (Terraform state).
Plan / apply: Preview changes / execute them.
Drift: Real infrastructure differing from code.
Module: Reusable group of resources.

How it works, step by step

1
Write resources as code
VPC, databases, IAM, in modules.
2
Store state remotely with locking
S3 + DynamoDB lock, or Terraform Cloud.
3
Open a pull request
CI runs fmt, validate, plan, and policy checks.
4
Review the plan
Watch for destroys and replacements.
5
Apply from CI
After approval; detect drift regularly.

Manual vs IaC

Managing infrastructure for three environments

Aspect	Console clicks	Infrastructure as Code
Consistency	Environments drift	Same modules, different variables
Review	None	Pull requests with plans
History	Hard to audit	Git history
Disaster recovery	Rebuild from memory	Re-apply code
Speed at scale	Slow and error prone	Fast, repeatable

NOWAspect: Consistency | Console clicks: Environments drift | Infrastructure as Code: Same modules, different variables

Treat infrastructure like application code: versioned, reviewed, tested, and deployed through pipelines.

Implementation

1terraform {2  backend "s3" {3    bucket         = "acme-tf-state"4    key            = "prod/network.tfstate"5    region         = "us-east-1"6    dynamodb_table = "tf-locks"   # prevents concurrent applies7    encrypt        = true8  }9}10 11module "vpc" {12  source  = "terraform-aws-modules/vpc/aws"13  version = "~> 5.0"14  name    = "prod"15  cidr    = "10.0.0.0/16"16  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]17  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]18  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]19  enable_nat_gateway = true20}21 22resource "aws_db_instance" "orders" {23  identifier          = "orders-prod"24  engine              = "postgres"25  engine_version      = "16"26  instance_class      = "db.r7g.large"27  multi_az            = true28  storage_encrypted   = true29  deletion_protection = true30  manage_master_user_password = true   # password in Secrets Manager, not in code31  db_subnet_group_name = aws_db_subnet_group.private.name32  allocated_storage    = 10033  username             = "app"34}

Complexity and performance

Plan timeSeconds to minutes

Grows with resources per state.

Blast radiusResources per state file

Split states by layer.

Trade-offs

Declarative vs imperative

Declarative tools handle ordering and diffs; imperative scripts are flexible but brittle.

Big vs small state files

Large states are slow and risky; many small states need cross-references.

Variants and related techniques

GitOps for Kubernetes

Argo CD applies manifests from Git continuously.

Policy as code

OPA, Sentinel, or Checkov block insecure changes.

Common mistakes

Secrets in IaC files or state.
Fix: Use secret managers; encrypt and restrict state access.
Manual console changes.
Fix: Cause drift; enforce changes through code and detect drift.
Applying without reviewing the plan.
Fix: Plans reveal destructive replacements; review and protect critical resources.

Interview questions

Why use Infrastructure as Code?

It makes infrastructure reproducible, reviewable, auditable, and recoverable; enables consistent environments; and lets infrastructure changes flow through the same CI/CD and review practices as code.

How do you manage Terraform state safely?

Store it remotely with encryption and locking (S3 + DynamoDB or Terraform Cloud), restrict access, split state by environment and layer, and never edit it manually except through state commands.

Practice problems

Problem	Difficulty	What it trains
Write Terraform for an S3 bucket with lifecycle rules	Easy	Basics.
Design IaC for dev, staging, prod across accounts	Medium	Modules and state.