Infrastructure as Code Landscape Cheat Sheet

Infrastructure as Code, usually shortened to IaC, is the practice of defining infrastructure in versioned files rather than building it manually through a console. The point is not simply automation. It is repeatability, reviewability, and the ability to reason about infrastructure changes with the same discipline used for application code.

The main split: declarative versus imperative

IaC tools differ first in how they express intent. Declarative tools describe the desired end state. You define a network, a cluster, or an access policy, and the tool calculates how to converge the real environment towards that state. Imperative tools describe the steps: create this resource, then configure that instance, then install these packages.

Declarative approaches are usually easier to review because the configuration expresses what should exist, not how to reach it. Imperative approaches can be more flexible for edge cases and procedural setup. In practice, many teams mix them: declarative provisioning for core resources, then imperative scripts or configuration management for fine-grained host setup.

Provisioning, configuration, and packaging are different jobs

The IaC landscape is easier to understand when you separate concerns.

• Provisioning tools create cloud resources such as VPCs, load balancers, databases, and IAM policies.
• Configuration management tools install packages, edit files, and enforce machine state on servers.
• Image builders produce machine images or container artefacts ahead of deployment.
• Templating and packaging tools help distribute application manifests and environment-specific settings.

Confusion often comes from asking one tool to solve every layer. A provisioning engine is rarely the best place to encode complex application boot logic, and shell-heavy configuration systems can become hard to reason about at cloud scale.

State, drift, and policy matter as much as syntax

Most infrastructure bugs are not caused by indentation. They come from unmanaged state. If a tool keeps state, that state must be secured, versioned where appropriate, and protected from concurrent modification. If operators can change resources manually, drift detection matters because the declared world and the real world will diverge over time.

Policy is the other half of maintainability. Teams need a way to enforce rules about encryption, network exposure, tagging, or allowed instance types. Without policy checks, IaC merely automates unsafe patterns faster.

Choose by operating model, not by popularity

The right tool depends on what you run and how your team works. Cloud-native teams often want provider support, composable modules, and strong planning output. Platform teams may care more about policy integration and multi-environment promotion. Smaller teams may favour a simpler toolchain that is easier to debug under pressure.

What good IaC practice looks like

Good IaC keeps modules narrow, separates reusable platform definitions from environment data, and routes all changes through review. It treats secrets carefully, validates plans before apply, and makes rollback or forward-fix procedures explicit.

The real value of IaC is operational clarity. When infrastructure is declared, reviewed, and reproducible, scaling the platform stops depending on memory and heroics. It becomes a controlled engineering process.