People describe `pulumi preview` as the equivalent of `terraform plan`. Where does that comparison break down?

## The mapping that does hold `pulumi preview` is read-only and tells you what `pulumi up` intends to do; `terraform plan` is read-only and tells you what `terraform apply` intends to do. Both classify changes into create, update, replace and delete, both need provider credentials and network access to do their job, and both are the thing you put in front of a human before production changes. If the interviewer only wants the mapping, that is the answer. The question is usually asking for the seams. ## Leak 1 — a preview runs your code Terraform evaluates a configuration document. Pulumi *executes a program*. Everything in that program runs during a preview: loops, helper functions, and anything the author put in there that touches the outside world. If the program fetches a list of tenants over HTTP, that HTTP call happens on every preview. If it writes a file, generates a value from the clock, or increments a counter in some external system, that happens during the "read-only" step too. The consequences are real: a preview in CI needs whatever credentials those side effects require, a preview can fail for reasons unrelated to infrastructure, and a non-deterministic program can produce a preview that does not match the `up` that follows minutes later. The mitigation is a rule, not a flag — keep the program pure, with all external reads expressed as provider data lookups rather than ad-hoc calls. ## Leak 2 — refresh is opt-in `terraform plan` refreshes: before diffing, it re-reads the managed resources from the provider so the plan is computed against reality, unless you disable it. `pulumi preview` and `pulumi up` do **not** refresh by default; they diff your program against the recorded state as it stands. Pulumi exposes refresh as a separate `pulumi refresh` command and as a `--refresh` flag on preview and up. The operational consequence is the one that bites: if someone changed a resource in the console, a default Pulumi preview may show "no changes" because the recorded state still matches the program — the drift is invisible until something else forces a read. Teams that care run with refresh enabled, and accept the extra API calls and time that costs on a large stack. ## Leak 3 — unknowns can hide whole resources Both tools have values that cannot be known until create time — an assigned ARN, a generated ID. Terraform renders these as `(known after apply)`, but the *resource* still appears in the plan, because the graph comes from a static configuration. In Pulumi, such a value is an output that is unknown during preview, and a callback registered on an unknown output is not executed at preview time. So if a resource is constructed *inside* one of those callbacks, the preview does not know it exists and does not list it. You get a preview showing five resources and an `up` that creates eight. Terraform's static graph makes this failure mode structurally impossible; Pulumi's dynamic one does not. The mitigation is stylistic: register resources at the top level and pass outputs into their arguments, rather than constructing resources inside a callback on a value that does not exist yet. ```typescript // Hazard: this resource is invisible at preview time when db.address is unknown. db.address.apply(addr => new aws.ssm.Parameter("db-addr", { type: "String", value: addr })); // Better: register at the top level and let the engine resolve the input. new aws.ssm.Parameter("db-addr", { type: "String", value: db.address }); ``` ## Leak 4 — the CI shape The two-stage pipeline most teams want is: produce a diff on the pull request, have a human approve *that* diff, then apply exactly what was approved. Terraform's saved plan file is built for that — plan on the PR, store the artifact, apply the artifact on merge. Pulumi's default flow is different: `pulumi up` runs the program again, previews, and asks for confirmation interactively (`--yes` or `--skip-preview` in automation). So the common pipeline is "preview on the PR for review, then up on merge", where the applied diff is recomputed rather than replayed. In practice the window is small and teams live with it, but you should be able to say plainly that the approval gate is weaker than replaying a saved artifact, and that anything which changed in between — someone else's apply, a drifted resource, a moved input — is inside that window. ## How to say it Lead with "same intent, different mechanics", then name the seams: it runs code, it does not refresh by default, unknowns can hide resources, and the approved diff is recomputed rather than replayed. That is a senior answer because each seam has an operational consequence, not just a definitional one.