A colleague says an infrastructure-as-code tool "just compares my code to what exists in the cloud". Which three distinct states does a reconciliation run actually involve, and which comparisons does the tool make between them?

## Why "code versus cloud" is the wrong mental model The two-state model — code on one side, the real world on the other — is the most common misunderstanding in infrastructure-as-code interviews, and almost every confusing behaviour a newcomer hits comes from it. A stateful tool works with three states, and knowing which pair is being compared at each moment explains create-versus-update, explains deletion, explains why a hand-made resource is ignored, and explains why losing the record is a catastrophe rather than an inconvenience. ## The three states **Desired state** is the declaration: the files a human wrote and reviewed, plus the input values supplied for this run. It says what should exist, not how to get there. **Recorded state** is the tool's own bookkeeping. For each object it manages, it holds the provider-side identifier and the attribute values it saw last time. This record is the only thing that ties the abstract name in the configuration to the concrete object in the provider — without it, a tool re-running the same configuration has no way to know whether the object it should create already exists. **Actual state** is ground truth: what the provider's API reports at this instant. It changes without the tool's involvement — someone edits the console, an autoscaler adjusts a capacity, a service applies a default the tool never asked for. ## The loop A reconciliation run is two comparisons, in order. First, **refresh**: for every object in the record, read the live object and update the record's view. This changes the tool's beliefs, not the infrastructure. It is also where the tool discovers an object that has been deleted out from under it and marks it as gone. Second, **diff**: compare the desired configuration against the refreshed record and derive the actions that close the gap. Roughly: - in desired, not in the record → create - in both, attributes differ → update in place, or replace if the attribute cannot be changed on a live object - in the record, not in desired → destroy - in both and identical → no action Then the actions execute against the provider, and the record is written back so the next run starts from an accurate baseline. Note that nothing in this loop scans the account for objects the tool never created — the fourth quadrant, *exists in reality but not in the record*, is deliberately outside the tool's field of view. That is what makes it possible for a hundred teams to run a hundred configurations against one account without each one trying to delete the others' work. ## Why deletion is the interesting case Create and update can be derived from desired plus actual alone: look at what should exist, look at what does, make up the difference. Deletion cannot. If you remove a block from your configuration, the desired state no longer mentions the object at all — there is nothing left to compare against reality. Only the record remembers "I made this, and it is no longer wanted". This single fact is the cleanest one-sentence answer to "why does the tool keep a state file at all", and it is why deleting the record does not delete infrastructure: it orphans it. The objects keep running, the tool forgets them, and the next run tries to create a second set. ## Stateless tools Not every tool keeps a record. A configuration-management run against a host reads the host's current condition — installed packages, file contents, running services — and compares that directly to the declaration. Two states, re-derived every time, nothing persisted between runs. The trade is exact: no state file to store, lock, corrupt or leak, but also no memory of what it created, so removing a declaration from the code means the previously configured thing simply stops being managed rather than being removed. Practitioners work around this by declaring removal explicitly — stating that a package should be *absent* rather than deleting the line that said it should be present. A control-plane service that owns the record on the server side is a third arrangement: the same three states, with the recorded one living in the provider's own database instead of a file you store. And a cluster controller sits somewhere between — the desired object and the observed status both live in the same API, so the record and the desired state are stored together while actual state is read from the world. ## Interview traps The candidate who says the record is "just a cache" gets pushed on deletion and usually fails. The candidate who says refresh "fixes" drift is confusing updating the tool's beliefs with changing infrastructure — refresh only makes the record honest; the following diff decides whether reality gets corrected.