Infrastructure as Code (IaC)

IaC tools operate on two primary paradigms. Declarative (or functional) IaC defines the desired end state of the infrastructure (e.g., 'ensure 5 web servers exist'), and the tool's engine determines the sequence of operations to achieve it. Examples include Terraform, AWS CloudFormation, and Pulumi (in declarative mode). Imperative IaC specifies the exact sequence of commands to execute to reach the state (e.g., 'run this API call, then that one'). Tools like Ansible (playbooks) and shell scripts often use this approach. Declarative IaC is generally preferred for its idempotency and focus on outcome over process.

A fundamental property where applying the same IaC configuration multiple times results in the same infrastructure state, regardless of the starting point. This ensures safety and predictability. If a configuration declares 3 instances, running it once creates 3 instances; running it a second time does nothing, as the desired state is already met. This prevents configuration drift and allows for safe, repeated execution as part of Continuous Integration/Continuous Deployment (CI/CD) pipelines. Non-idempotent scripts can create duplicate resources or cause errors on re-runs.

IaC definition files are treated as source code, stored and versioned in systems like Git. This enables:

• Full Audit Trail: Every change to infrastructure is tracked with a commit history, showing who changed what and why.
• Code Review: Infrastructure changes undergo peer review via pull requests, improving quality and knowledge sharing.
• Branching & Merging: Teams can work on infrastructure changes in isolation (e.g., feature branches) and merge them systematically.
• Rollback Capability: Reverting to a previous, known-good infrastructure state is as simple as reverting a Git commit and re-applying the configuration.

The practice of replacing entire infrastructure components (e.g., servers, containers) with new, versioned instances rather than modifying existing ones in-place. Instead of patching or updating a live server, a new server image (AMI, Docker container) is built from the IaC definitions, deployed, and the old one is terminated. This eliminates configuration drift, ensures consistency between environments (dev, staging, prod), and simplifies rollback (deploy the previous image). It is a core pattern enabled by IaC and is central to modern cloud and container-based deployments.

IaC enables the full automation of infrastructure provisioning and management. Code changes trigger automated pipelines that:

1. Validate syntax and configuration.
2. Plan/Preview changes in a sandbox (e.g., terraform plan).
3. Apply changes to environments automatically or with approval gates. This integration is the foundation of GitOps, where the Git repository state is the single source of truth, and automated operators continuously reconcile the live infrastructure to match. It reduces manual error, accelerates deployment frequency, and enforces consistent governance.

IaC promotes the creation of reusable, parameterized modules or templates that abstract complex infrastructure patterns. For example, a 'web cluster' module could encapsulate an auto-scaling group, load balancer, and security groups. This module can then be reused across multiple projects or environments (dev, prod) with different input variables (instance size, min/max nodes). This DRY (Don't Repeat Yourself) principle reduces code duplication, standardizes architecture, and makes large-scale infrastructure manageable. Public and private registries (like the Terraform Registry) facilitate sharing these modules across teams and organizations.

IaC tools operate on two primary paradigms. Declarative IaC (e.g., Terraform, AWS CloudFormation) defines the desired end state of the infrastructure, and the tool's engine determines the sequence of API calls to achieve it. Imperative IaC (e.g., Ansible, Chef, Puppet) defines the specific commands or steps needed to configure the infrastructure. Declarative approaches are generally preferred for provisioning cloud resources due to their idempotency and focus on outcome, while imperative tools excel at configuration management on existing servers.

GitOps is an operational framework that extends IaC principles. It uses Git repositories as the single source of truth for both application code and declarative infrastructure definitions. Automated operators (like Flux or ArgoCD) continuously monitor the Git repo and reconcile the state of the live system (e.g., a Kubernetes cluster) with the committed definitions. This creates a closed-loop system where all changes are versioned, auditable, and applied automatically, enforcing rigorous change management and rollback capabilities.

Configuration drift occurs when the actual, running state of infrastructure diverges from the state defined in the IaC source files. This is a major risk that IaC aims to prevent. Drift can be introduced by:

• Manual, ad-hoc changes made directly in the cloud console.
• External processes or scripts not managed by IaC.
• Resource failures and manual recovery procedures. IaC tools like Terraform can detect drift by comparing its state file to the live cloud environment. Mitigation involves either re-applying the IaC to enforce the defined state or importing the drifted resource back under IaC management.

This is a deployment model where infrastructure components are never modified after deployment. Instead of patching or updating a live server (mutable infrastructure), a new, updated component is provisioned from a base image defined in code, and the old one is destroyed. This approach, central to containerized and serverless architectures, guarantees consistency, simplifies rollback (by redeploying the previous image), and eliminates configuration drift. IaC is essential for automating the provisioning of these immutable artifacts.