What is the difference between infrastructure as code and configuration as code, and how does that difference show up in the kinds of tools a team ends up running?

## Two questions, not one - **Infrastructure as code** answers *what exists*. A virtual network with this address range. Six machines of this size. A managed database with this engine version. A load balancer in front of them. The unit of work is a cloud (or platform) resource, and the tool talks to a control-plane API. - **Configuration as code** answers *how an existing thing is set up*. This package at this version is installed. This file has these contents. This service is enabled and running. This kernel parameter has this value. The unit of work is the state of a system, and the tool typically connects into that system to assert conditions. Both are "declare it in a reviewed file in version control rather than doing it by hand". They differ in what they are declaring about. ## Why the split exists historically Configuration management came first, and it came from a world of long-lived servers. Someone racked a machine; the question was how to get a hundred of them into a consistent state, and to keep them there as packages and settings changed. That is a per-host, in-band problem. Cloud provisioning tools arrived when the machine itself became an API object. Suddenly the network, the firewall, the disk and the machine were all things you could create and destroy with a call, and the question shifted from "how do I configure this server" to "which servers, and what else, should exist at all". The two problems are genuinely different, and that is why the tooling ended up different: one authenticates to a cloud control plane and manages resource records, the other authenticates to a machine and manages its innards. ## How it shows up in practice A very common estate shape is: a provisioning tool creates the network, the machines and the managed services; a configuration-management tool then brings each machine to the required software state; and something in between — an instance's user-data, a bootstrap hook, or an inventory generated from the provisioner's outputs — passes the handoff. That handoff is where the interesting problems live. Which tool owns a value that both need? How does the configuration tool learn about a machine that the provisioner just created? What happens when the provisioner replaces a machine — does the configuration tool notice, or does it keep converging a host that no longer exists? ## The line blurs in two directions **Downward, via immutable delivery.** If host state is baked into an image before launch and running machines are never modified, then at run time there is no per-host configuration work left; the estate is pure provisioning, and the configuration-as-code work has moved into the image build pipeline. Many teams still use a configuration-management tool for exactly that — as the thing that configures the image being built, rather than the fleet in production. **Upward, into anything with an API.** "Configuration as code" is now applied well beyond servers: dashboards and alert rules, DNS zones, identity groups, feature-flag definitions, SaaS product settings. These are declared through provider APIs and are, mechanically, indistinguishable from infrastructure resources — which is why provisioning tools have absorbed a lot of this ground. If it has an API and you want it reviewed and reproducible, it can be declared. ## The distinction that actually matters in an interview Do not present this as a taxonomy quiz. The useful framing is: 1. **The unit differs** — resource records versus in-system state — and that determines what the tool must authenticate to and what it can observe. 2. **The lifecycle differs.** Provisioned resources are typically created and destroyed; configured state is typically converged repeatedly over the life of something long-running. 3. **Both need the same disciplines regardless** — version control, review, repeatable application, and a way to see what a change will do before it happens. A weak answer treats the two terms as marketing labels for the same thing, or claims one tool category has made the other obsolete. Containers, for instance, did not delete the configuration problem; they moved most of it into the image definition and left a residue — the host running the container runtime, and the platform configuration around it — that still has to be declared somewhere. ## The phrase's third meaning Be aware that "configuration as code" is also used, especially by application developers, to mean *application* configuration kept in version control and delivered by a pipeline rather than typed into a console. That is a legitimate third sense of the phrase. If it comes up ambiguously in an interview, it is entirely reasonable to ask which sense they mean rather than guessing.