Immutable Infrastructure Check

The core check confirms that all compute instances are launched from a single, versioned, and cryptographically signed golden image (e.g., an AMI, container image, or VM template). This ensures:

• Deterministic builds: Every instance is an identical artifact from the same build pipeline.
• No in-place updates: The system prohibits SSH-based configuration changes or package updates on running hosts.
• Artifact integrity: The image hash is verified against a trusted registry before deployment.

This check validates the disposability of infrastructure. Servers are treated as cattle, not pets, and are replaced, not repaired. The verification ensures:

• Stateless application design: Persistent data is externalized to managed services (object storage, databases).
• Fast, automated replacement: The system can terminate and replace an instance within minutes, often using blue-green or canary deployment strategies.
• Ephemeral runtime: No long-term identity or unique state is stored on the host itself.

A key function is to detect any deviation from the declared image state. This acts as a canary for mutable changes. The check compares the live system against the baseline image, flagging:

• Unauthorized package installations or version changes.
• Modifications to critical system files (e.g., /etc/ configs).
• Changes to user accounts, permissions, or running processes. A failed check typically triggers an automated instance replacement.

The check is an enforcement mechanism for declarative infrastructure. It ensures the real-world state matches the state defined in code (IaC). This involves:

• Validating IaC tool output: Confirming that Terraform, Pulumi, or CloudFormation created the intended immutable resource.
• Rejecting imperative changes: The system's design prevents manual cloud console actions or CLI commands that would modify a live instance.
• Continuous reconciliation: In platforms like Kubernetes, this is enforced by controllers that constantly reconcile pod specs with actual running containers.

The check enables predictable and fast rollbacks. Because deployments use versioned images, recovery from a failed deployment is a matter of re-deploying the previous known-good image. The check validates that:

• Previous image versions remain accessible in the artifact registry.
• Deployment orchestration (e.g., Spinnaker, ArgoCD) can automatically trigger a rollback based on health check failures.
• State is preserved for stateful services via external volumes, ensuring rollback doesn't cause data loss.

Immutable infrastructure provides a strong security posture. This check verifies that every instance starts from a hardened, patched, and audited baseline. It ensures:

• Vulnerability scanning: The base image is scanned for CVEs before being promoted to production.
• Reduced attack surface: Unnecessary services, open ports, and default credentials are absent from the golden image.
• Audit trail: The provenance of every deployed instance is traceable back to a specific CI/CD build job and commit hash, aiding compliance.

The process of continuously comparing a system's observed, running state against its declared, desired state (e.g., defined in a Kubernetes manifest or Terraform configuration). It detects configuration drift, where a server is modified in-place, violating immutability. Automated operators (like Kubernetes controllers) reconcile drift by destroying and recreating the resource to match the declared spec.

A server management pattern where servers are created from a common image and are never modified after being placed into production. If a change is needed, a new image is built, deployed, and the old server is destroyed. This pattern, popularized by Martin Fowler, is the direct conceptual ancestor of modern immutable infrastructure, emphasizing total disposability and consistency.

A pre-flight validation that a system's resilience mechanisms are functional before intentionally injecting failures. For an immutable system, key readiness checks include:

• Verifying automated rollback triggers work.
• Ensuring new instances from the golden image can be launched rapidly.
• Confirming that state is externalized and persists independently of instance lifecycle. This validates that the immutable architecture can withstand real-world failures.