Why would a team run `terraform plan -out=tfplan` and later `terraform apply tfplan` instead of just running `terraform apply`?

## The problem being solved The dangerous gap in an infrastructure change is between *approval* and *execution*. Someone reads a diff, agrees it is safe, and clicks approve. Minutes or hours later the change runs. If the tool re-derives what to do at that later moment, the approval was for a different thing than the one that happened. A bare `terraform apply` has exactly that gap. It runs its own planning phase, prints the result, and asks for confirmation. Even the operator standing at the terminal is approving a freshly computed diff — and in a pipeline with `-auto-approve` nobody sees it at all. ## What `-out` actually saves ```bash terraform plan -out=tfplan terraform apply tfplan ``` The file produced by `-out` is not a text report. It is an opaque binary artefact containing the planned action for each resource, the configuration, a snapshot of the state the plan was computed against, and the variable values that were in effect. Everything the apply phase needs to proceed without deciding anything again. Applying it changes Terraform's behaviour in several specific ways: - **No re-planning.** The recorded actions are executed as recorded. - **No approval prompt.** The plan file is itself the approval, so `-auto-approve` is unnecessary. - **No variable input.** Values are baked in. Passing `-var` or `-var-file` alongside a saved plan is an error, not an override — Terraform tells you it cannot set variables when applying a saved plan. This closes a real hole: you cannot review a plan built with one set of inputs and then apply it with different ones by changing a flag. ## The staleness check The plan records which state it was built from. If the state has moved on — another engineer applied, an automated job ran, a rollback happened — Terraform refuses the plan rather than executing it, reporting that the saved plan is stale because the state was changed by another operation after the plan was created. The fix is always the same: re-plan, re-review, re-apply. This is worth stating carefully, because it is not a general-purpose guarantee. Terraform detects that *the recorded state changed*. It does not detect that someone edited the resource in the cloud console without touching Terraform state — the plan file cannot know about that. Saved plans make the review honest; they do not make the world stand still. ## Where this shows up in practice The canonical pipeline shape is one job that runs `terraform plan -out=tfplan` and publishes the human-readable diff for review, then a second job — after merge or after a manual approval — that takes the same file and runs `terraform apply tfplan`. The alternative, re-planning in the apply job, is simpler to operate but gives up the guarantee entirely. That convenience comes with a real obligation: the plan file contains the prior state and every planned attribute value, sensitive ones included, so it has to be handled as secret material rather than as an ordinary build artefact. ## Reading a saved plan Because the file is binary, you inspect it through Terraform: ```bash terraform show tfplan # the same human-readable diff terraform show -json tfplan # machine-readable, for policy tooling ``` The JSON form is how automated checks consume a plan: a policy engine or scanner evaluates what is *about to happen* rather than guessing from the source files. That is a much stronger check, because it sees the resolved values after variables, locals and data sources have been evaluated. ## Limits to acknowledge A plan file is tied to the configuration and the Terraform version that produced it; a different version will refuse to read it. It must be applied from an initialised working directory with the same providers available. And it is short-lived by design — the older it gets, the more likely the staleness check will reject it, which is a feature and not an inconvenience. ## What a strong answer sounds like "Because apply otherwise re-plans, so the reviewed diff and the applied diff are two different computations. Saving the plan makes them one artefact, pins the variables, and gives me a stale-plan error instead of a surprise if the state moved. The cost is that the file holds sensitive values and has to be protected like state."