Coming from Terraform, which Pulumi CLI commands correspond to `terraform plan`, `terraform apply` and `terraform destroy`, and is there anything equivalent to `terraform init`?

## The everyday mapping | Terraform | Pulumi | What it does | | --- | --- | --- | | `terraform plan` | `pulumi preview` | Read-only. Reports what would be created, updated, replaced or deleted. | | `terraform apply` | `pulumi up` | Makes the changes. Interactively it previews first and asks for confirmation. | | `terraform destroy` | `pulumi destroy` | Deletes everything the stack manages. | | refresh-only apply | `pulumi refresh` | Re-reads live resources and updates the recorded state to match. | | `terraform init` | *(no direct equivalent)* | See below. | That table is the whole answer for a screening question; the interesting parts are the three places where the mapping is not one-to-one. ## `pulumi up` previews before it applies Run interactively, `pulumi up` performs a preview, prints the change summary, and waits for you to confirm before it touches anything. That makes the two-command habit (`plan`, read, `apply`) less necessary at a terminal — although for anything shared you still want the preview reviewed separately. In automation this prompt would hang the job, so pipelines pass `--yes` to auto-confirm. `--skip-preview` additionally suppresses the preview phase. The usual pipeline is `pulumi preview` on the pull request for review and `pulumi up --yes` on merge. ```bash pulumi preview --diff # on the pull request pulumi up --yes # on merge, non-interactive ``` ## There is no provider init step `terraform init` downloads providers and modules into the working directory and configures the backend before anything else can run. Pulumi has nothing corresponding to the provider half of that, because a provider SDK is an ordinary library dependency: you `npm install @pulumi/aws`, `pip install pulumi-aws` or `go get` it, exactly like any other package, and your existing dependency tooling handles versions and lockfiles. The provider *plugin* binary that goes with it is fetched automatically when a program that needs it runs, so there is no explicit download command in the normal flow. What you do instead, once per project, is scaffold it — `pulumi new` creates a project from a template — and select the stack you are operating on. Every command above runs against a currently-selected stack, so the practical daily rhythm is: select the stack, preview, up. ## `pulumi refresh` is a first-class command In Terraform, reconciling recorded state with the live cloud is folded into `plan` by default and is available as a refresh-only apply. In Pulumi it is a distinct command, `pulumi refresh`, and it is **not** implied by preview or up — you opt in with `--refresh` if you want it as part of a run. Knowing that early saves confusion later, because it means a Pulumi preview can report "no changes" while a resource has been edited in the console. ## Things that look like they should map, and don't - **Saved plans.** Terraform can write a plan to a file and apply exactly that file later. `pulumi up` by default re-runs the program and recomputes the diff rather than replaying a saved artifact, so the two-stage pipeline is shaped differently. - **Workspaces.** Terraform workspaces are multiple states behind one configuration; a Pulumi *stack* is the unit of deployment and carries its own configuration file as well as its own state, so it is a fuller concept than a workspace even though the CLI ergonomics feel similar. - **`terraform fmt` / `validate`.** These belong to HCL. In Pulumi the equivalents come from the language: a formatter and a compiler or type checker you already run, plus your usual linter. ## How to answer this in a screen Give the three-line mapping first — preview, up, destroy — then add the two facts that show you have actually used it: `up` previews and prompts unless you pass `--yes`, and there is no provider init because the SDK is a normal package dependency. That is a complete junior-level answer and it lands in under thirty seconds.