Configuration management versus image baking: where idempotence and drift decide

What it is

Configuration management tools such as Puppet, Salt and Ansible describe a system's desired state declaratively and converge the actual system toward it each time they run. Puppet's own documentation names this property directly: "A key feature of Puppet is idempotency — the ability to repeatedly apply code to guarantee a desired state on a system, with the assurance that you will get the same result every time." Salt's glossary defines an idempotent action the same way: one that "ensures the system is in a well-known state regardless of the system's state before the action is applied," so that "applying the action multiple times results in no changes to the system" once it is already converged. Ansible's own documentation notes that its tasks "achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state."

Image baking (Packer and similar tools) takes a different approach: software and configuration are installed once, at build time, and the result is captured as an immutable artifact. A booted instance of that image does not re-run the configuration logic; it simply is the state that was baked in.

Why it matters

Idempotent configuration management can run continuously (on a schedule, or on every boot) and correct drift — a file that got modified out of band, a service that got disabled — by re-applying the same declaration. Image baking cannot correct drift after boot at all: once an instance diverges from its image (a manual change, an ad-hoc fix), nothing brings it back except replacing the instance with a fresh one from the image. Baking trades the ability to self-correct for a faster, more predictable boot (no configuration run needed) and a smaller window in which misconfiguration or a failed idempotent step can leave a host half-converged.

How to apply

• Bake into the image what rarely changes and must be present from the first second of boot: the base OS, security patches as of build time, agents that must already be running.
• Configure at boot (or continuously) what changes per-environment or per-instance: hostnames, secrets fetched from a vault, feature flags — anything that must reflect current desired state, not the state at the last image build.
• Combine both deliberately: a "golden image" that still runs a configuration management tool at first boot for the last, environment-specific mile, with an explicit record of which layer owns which setting.
• Treat non-idempotent steps (an exec-style resource, a raw shell provisioner) as a liability in either approach, and make them idempotent explicitly (check a marker first) rather than assuming a single run is safe.

Pitfalls

• Relying on "it worked last time" as evidence of idempotence; a resource can appear idempotent in testing and still change a system in a different starting state.
• Re-baking an image on every deploy instead of when its baked-in content actually changes, turning a fast-boot strategy into a slow one without the drift-correction benefit either approach is meant to provide.
• Mixing bake-time and boot-time ownership of the same setting, so two systems fight over it on every convergence run.