🏗️ Infrastructure as Code — Deep Dive

Idempotency means that running the same IaC configuration multiple times produces the same result — the infrastructure converges to the desired state regardless of how many times it is applied. In practice: running `terraform apply` twice on an unchanged configuration should result in zero changes on the second run. Idempotency is fundamental to IaC because it makes automation safe to re-run in CI/CD pipelines and after partial failures. Ansible is designed to be idempotent; CloudFormation and Terraform enforce it through state management.

Declarative IaC describes the desired end state of infrastructure, and the tool figures out how to get there. You say "I want 3 EC2 instances of this type" and Terraform creates, modifies, or destroys instances to reach that state. Imperative IaC specifies the exact commands to execute in order. Chef and Ansible (in procedural mode) are more imperative; Terraform and CloudFormation are declarative. In a design discussion: "We prefer declarative IaC because it's idempotent and self-documenting — the code is the state, not the steps."

Terraform state is a file (terraform.tfstate) that records the current known state of managed infrastructure. Terraform compares this state against the desired configuration to calculate what changes are needed. State drift occurs when the actual infrastructure diverges from the recorded state — for example, someone manually changed a security group rule in the AWS console. To detect drift you run `terraform plan` and look for unexpected changes. To resolve drift: either import the manual change into state or re-apply to overwrite it. In a review: "We have drift in production — someone added an ingress rule manually. We need to decide whether to codify it or remove it."

GitOps is an operational model where a Git repository is the single source of truth for both application and infrastructure configuration. Changes to infrastructure are made via pull requests, and an automated operator continuously reconciles the live environment to match what is in Git. Key GitOps vocabulary: reconciliation loop (the continuous process of comparing desired state in Git with actual cluster state), drift detection (identifying when live state diverges from Git), and pull-based deployment (the cluster pulls config from Git rather than a CI system pushing it). Tools: Flux and ArgoCD for Kubernetes; Atlantis for Terraform GitOps.

A Terraform workspace is an isolated instance of state within a single Terraform configuration. Workspaces allow the same configuration to manage multiple environments (dev, staging, production) with separate state files. In practice: "We use workspaces to deploy the same networking module to three environments. The workspace name is interpolated into resource names to avoid conflicts." The limitation is that workspaces share the same backend and code — for large organisations, separate directories or separate repositories per environment are often preferred over workspaces for stronger isolation.

Policy as code (PaC) expresses governance rules — security, compliance, cost — as code that is automatically evaluated against IaC plans before apply. It prevents non-compliant infrastructure from being provisioned. Tools: HashiCorp Sentinel (integrated with Terraform Cloud), Open Policy Agent (OPA) with Conftest, tfsec (Terraform security scanner), and Checkov (multi-framework IaC scanner). Example: "Our OPA policy blocks any EC2 instance type larger than t3.large in the dev environment and requires all S3 buckets to have server-side encryption enabled."

A Terraform plan shows the changes Terraform will make to reach the desired state: resources to be created (shown as +), destroyed (shown as -), or modified in-place (shown as ~). A destroy-then-recreate is shown as -/+. In a code review or standup: "The plan shows 3 resources being created, 1 being modified in-place, and — worryingly — a forced replacement of the RDS instance which means downtime. We should check whether the configuration change causing the replacement can be avoided." Always review the plan before apply in production.

A Terraform module is a reusable, composable unit of infrastructure configuration — a directory of .tf files that can be called from other configurations with input variables and output values. Good module design principles include: single responsibility (a module does one thing well), sensible defaults with variable validation, documented outputs, no hard-coded values, and semantic versioning via a module registry. In a design review: "This module has too many responsibilities — it's managing networking, compute, and IAM in one. We should split it into three modules and compose them at the root."

Terraform is a cloud-agnostic IaC tool by HashiCorp that manages resources across AWS, Azure, GCP, and hundreds of other providers using HCL (HashiCorp Configuration Language). CloudFormation is AWS-native, using JSON or YAML templates, with deep integration into the AWS ecosystem but no support for other clouds. Key trade-off language: "Terraform gives us multi-cloud portability and a large module ecosystem, but we carry the operational burden of managing remote state. CloudFormation is simpler to operate for pure AWS shops because AWS manages the state and offers native drift detection."

In older Terraform versions, `terraform taint` manually marked a resource as needing replacement on the next apply — even if its configuration had not changed. This was used to force recreation of a resource that was in a broken state. In Terraform 0.15.2+, the `taint` command was replaced by `terraform apply -replace="resource.name"`, which achieves the same effect more safely. In a troubleshooting conversation: "The EC2 instance is in a degraded state but Terraform doesn't know — I'm going to replace it with `-replace` to force recreation."