Infrastructure as Code (IaC)

A production server that had been running for three years crashed and could not be recovered. It had been set up manually: someone clicked through the AWS console, installed packages via SSH, configured services by hand. Nobody documented the steps. Nobody could reproduce the environment. Rebuilding it took an engineer 4 days of detective work, reading shell history files, comparing packages with other servers, and guessing configurations.

Infrastructure as Code (IaC) means defining your entire infrastructure in code files. Servers, databases, load balancers, DNS records, IAM roles, VPCs. All of it. Terraform, Pulumi, AWS CDK, or CloudFormation describe the desired state. The tool creates, updates, or destroys resources to match. Rebuilding any environment is terraform apply. Minutes, not days.

HashiCorp reports that organizations using Terraform provision infrastructure 33% faster and experience 50% fewer misconfigurations compared to manual provisioning. Netflix manages thousands of AWS resources through IaC. Shopify provisions new regions by running their Terraform modules against a new AWS account.

Declarative vs imperative:

Declarative is preferred because it is idempotent. Running terraform apply twice produces the same result. Running a bash script twice might create duplicate resources.

State management is the hardest part. Terraform tracks every resource it manages in a state file. This JSON file maps your code to real cloud resources. If the state file is lost or corrupted, Terraform loses track of what exists and may try to recreate everything.

Store state remotely (S3 bucket with versioning + DynamoDB locking) so that:

• Multiple engineers can run Terraform without conflicts
• State is backed up automatically
• Locking prevents two people from applying simultaneously