Walk through the phases an infrastructure-as-code tool goes through when it previews a change, from reading the current world to applying it. What happens in each?

## Why a preview exists at all Infrastructure code is pointed at systems where a mistake is expensive and often irreversible: a deleted database, a detached volume, a security group opened to the internet. An imperative script gives you no way to know what it will do except to run it. A declarative tool can do something better — compute the set of API calls it *would* make and show them to you without making any of them. That dry run is the single property that makes it reasonable to let a pipeline change production. The preview is not a simulation of the cloud. It is a diff between three things: what you declared, what the tool has recorded about the objects it manages, and what those objects actually look like right now. ## Phase 1 — refresh / read The tool takes its record of managed objects and queries the provider APIs for each one, reading current attributes. Nothing is written. The purpose is to make the diff a statement about reality rather than about a record that may be months out of date — someone may have resized an instance in the console, or an autoscaler may have moved a count. This phase costs API calls roughly proportional to the number of managed objects, so on a large estate it is the slow part, and it is the phase most likely to hit provider rate limits. Most tools let you skip or narrow it, accepting a stale baseline in exchange for speed. Stateless configuration-management tools do the equivalent by gathering facts and letting each resource check its own current condition on the host; a controller-style system does it by listing live objects. The phase is universal even when the record is not. ## Phase 2 — diff For each declared object the tool compares desired attributes against the refreshed actual attributes and emits an action: ``` + create network / app-vpc ~ update compute / api-server (size: small -> medium) +/- replace database / reports (engine version cannot change in place) - destroy storage / old-bucket ``` It also computes ordering: a subnet before the instance in it, the instance before the DNS record pointing at it. The diff is therefore both a list and a plan of execution. One real limitation belongs here. Some values do not exist until the provider assigns them — generated identifiers, allocated addresses, computed endpoints. The preview shows those as unknown, and every expression downstream of an unknown is also unknown. A preview containing a lot of unknowns is genuinely less informative, and no amount of reviewing recovers that. ## Phase 3 — approval The diff is handed to a decision-maker: a human reading it in a pull request or a terminal prompt, an automated rule set, or both. Two things make this phase real rather than ceremonial — the reviewer must be able to decline, and the artifact they reviewed must be the artifact that gets executed. Where the pipeline recomputes the diff after approval, the approval covered something that no longer exists. ## Phase 4 — apply The tool walks the graph, executing independent actions in parallel up to a concurrency limit, and updating its record as each call returns. Crucially, apply is usually **not** transactional: it issues many independent API calls, and if the tenth fails, the first nine already happened. The record is updated for what succeeded, so the next preview starts from a truthful, partially-applied world. Some server-side systems do attempt an automatic rollback on failure, which trades that truthfulness for a rollback that can itself get stuck. ## What the preview cannot tell you It cannot tell you the change is *correct* — only what will be attempted. It cannot resolve values the provider assigns at creation. It cannot show the effects of any script the change runs on a machine. It will not catch permission or quota failures that only surface on a write. And it describes the world as of the refresh, not as of the apply. ## Interview framing Say the four phases in order, name what each contacts, and finish on the honest limits: unknowns, non-transactional apply, and the time gap before execution. That last point is usually the follow-up the interviewer is steering toward.