IaC Concepts

Declarative code describes the end state you want and lets the tool work out the steps to reach it; imperative code lists the steps themselves. IaC tools are declarative so the same file can be applied repeatedly and still describe one known result.

Convergence means each run moves the system toward the declared state and stops when it matches, so a second run with no changes does nothing. A half-finished run is safe to repeat: the tool redoes only the work still outstanding.

Drift is divergence between what your infrastructure code declares and what actually exists at the provider. Common causes: console or emergency edits, autoscalers and other controllers changing fields, provider-applied defaults, and a second tool managing the same resource.

Mutable infrastructure is changed in place — you patch and reconfigure the servers you already run. Immutable infrastructure never edits a running server: you build a new image, launch replacements from it, and destroy the old instances.

Create adds a new object, update in place modifies an existing one, destroy removes it, and replace destroys the existing object and creates a new one because an attribute changed that the provider cannot alter after creation. Replace is destructive: data and identity do not survive it.

A state record maps each declared resource to the real object the tool created. Without it the tool cannot tell an update from a create, cannot know which real objects to delete when code is removed, and cannot order a destroy.

Define each piece of infrastructure once as a reusable component and vary only the inputs per environment. Give every environment its own thin top-level configuration, its own values file and its own isolated state and credentials, so an apply in dev cannot touch production.

Idempotency means applying the same configuration again leaves the same end state, so a run can be repeated or resumed safely. Scripts break it by using create-and-append operations that stack up on every execution instead of asserting a condition.

Three states, not two: desired state (your code), recorded state (the tool's snapshot of the objects it manages) and actual state (what the provider reports now). A run refreshes the record from reality, then diffs desired against it.

A preview runs in four phases: refresh, where the tool re-reads live infrastructure; diff, where it compares your declared configuration against that reality and lists proposed actions; approval, where a human or policy gate reviews them; and apply, which executes the approved actions in dependency order.

Evaluating the proposed change is preventive: the violation is judged before it exists, so the bad resource is never created. Scanning what is already running is detective — it finds violations only after they exist and after the exposure window has opened.

IaC testing layers, cheap to expensive: static checks on the files, assertions on the generated plan or diff, unit tests of modules against faked providers, then a real apply into a throwaway account. Each layer sees more reality at more cost.

First establish what was changed and why, and whether the change is still load-bearing. Then choose one of three honest outcomes: revert to the code, codify the change into the code and apply, or adopt an unmanaged resource into the tool's record. Never re-apply blindly.

Three levels are standard: advisory reports only, soft-mandatory fails but a named owner can override with the override recorded, and hard-mandatory cannot be overridden at all. Roll out advisory first to find false positives and the real violation rate, then promote rules one at a time.

Policy as code expresses organisational rules as machine-executable checks that run automatically on every proposed infrastructure change. Unlike a written standard, the rule is unambiguous, never forgotten by a reviewer, version-controlled like the code it governs, and leaves a pass/fail record.

Static checks read only the source, so they catch syntax and schema errors, unknown or misspelled attributes, style and naming violations, deprecated constructs, hardcoded secrets, and obviously risky settings. They cannot know what infrastructure exists or what a change would actually do.

Every flag doubles the number of code paths, and only the combinations your environments actually use are ever exercised — so the production path is the least tested one. Prefer parameterising values, pushing structural differences up into the caller, or accepting two explicit definitions.

Infrastructure as code declares the resources themselves — networks, machines, managed services. Configuration as code declares the state inside or on top of them, such as installed packages, files and services. The two overlap but answer different questions.

Detection re-reads each managed resource from the provider API and compares three things: the configuration you declared, the record of what the tool last created, and the observed live values. A difference between the record and the observation is drift.

A golden image is built once by a pipeline with the OS packages, runtime, agents and application already installed. Bake whatever is slow, version-sensitive or downloaded from the network; leave only per-instance and per-environment data to be injected at boot.

A convergence run only asserts what it currently declares. It does not remove what it stopped declaring, does not pin what was never pinned, and cannot undo manual edits, so hosts accumulate divergent history. Replacement discards that history on every change.

Source files are a template, not an outcome — variables, loops and module inputs are only resolved when the tool computes the change. The engine is given that resolved description so it judges the concrete resources and values that will exist, not the text that produces them.

The record stores every attribute the provider returned, and a generated password is just another attribute. Any recorded state therefore contains secrets in the clear, so its storage must be encrypted, tightly access-controlled and audited exactly like a secret store.

Cut along change cadence, ownership and consequence of failure: things that change together and are owned by the same people belong in one unit, and the seam goes where you want a mistake to stop. Keep cross-boundary dependencies few and pointing one way.

Publish the component as an immutable version, have every environment pin an exact version, and promote by bumping the pin one environment at a time — dev, then staging, then production — with each bump a reviewed change carrying its own preview of what will change.

Scripting still wins for one-shot actions rather than durable resources: operational tasks, bulk data work, bootstrapping the tooling itself, and anything with no resource model. Keep those scripts in the repository, reviewed, re-runnable and logged like any other change.

Continuous reconciliation shrinks the time infrastructure spends wrong from days to minutes and removes the human from the critical path. In exchange, a bad commit reaches production unreviewed, emergency console fixes get reverted automatically, and the loop itself becomes a system you must observe, rate-limit and be able to pause.

Give the field exactly one owner. Either your code stops managing that attribute and hands it to the other system, or you disable the other writer and keep it declared. Two writers on one field produce endless flapping and eventually ignored drift reports.

Rollback is cheap because the previous version still exists untouched as an addressable artifact, so you launch it rather than reverse a change. It restores compute and configuration only — not migrated data, consumed messages, external side effects or deleted infrastructure.