What does the plan file produced by `terraform plan -out=tfplan` actually contain, and why does that make it sensitive?

## What people assume, and what is true The assumption is that a plan file is a saved version of the pretty diff Terraform printed — a report. It is not. It is a binary archive that carries everything the apply phase needs to run without thinking again: - the configuration the plan was built from, - a snapshot of the **prior state**, - the variable values that were in effect, - the planned action and the planned attribute values for every affected object. That last item is the sting. Planned values are the concrete values that are about to be written — the database master password that came from a variable, a generated key, a token being injected into an environment variable. They sit in the file in the clear. ## `sensitive` is a display feature When you mark a variable or output `sensitive`, Terraform prints `(sensitive value)` instead of the content in the plan output and in `terraform output`. It is a shoulder-surfing and log-scraping control. It does not encrypt anything, and it does not omit anything from the state file or the plan file. Both still carry the real value, which is why the documentation says to treat state — and saved plans — as sensitive data. A candidate who says "we mark it sensitive so it is safe to publish the plan" has misunderstood the feature completely, and that is exactly the misconception this question is asked to surface. ## Binary is not encryption The format is opaque only in the sense of not being human-readable in a text editor. Terraform itself will render it for anyone who has it: ```bash terraform show tfplan # the human diff terraform show -json tfplan # everything, machine-readable ``` The JSON form deliberately exposes prior state, planned values and configuration, because that is what policy engines need to evaluate. Whoever can download the artefact gets that. ## Where it leaks in real pipelines The standard two-job pipeline — plan in one job, apply in another — has to move the file between them, and the obvious mechanism is the CI system's build-artefact store. That store is often readable by everyone in the organisation, retained for weeks by default, and sometimes readable without authentication for public repositories. The same mistake appears in a few other shapes: - posting the full `terraform show -json` output into a pull request comment, - running the plan job on pull requests from forks, where an attacker controls the code that runs with your credentials and can print or exfiltrate the plan, - keeping plan files in a shared scratch bucket with no lifecycle rule, - committing a `tfplan` to git because it was not in `.gitignore`. ## Handling it properly The controls follow from calling it what it is — a state snapshot plus secrets: 1. **Restrict who can download it.** Artefact access should match who is allowed to see state, not who can see the repository. 2. **Keep it short-lived.** Retention of hours, not the default weeks. A plan more than a few minutes old will usually be rejected as stale anyway, so long retention buys nothing but risk. 3. **Encrypt at rest and in transit**, wherever it is stored between jobs. 4. **Never expose it to untrusted triggers.** Plans run with credentials; fork pull requests must not get them. 5. **Publish the redacted human diff for review, not the raw file.** The `terraform show -no-color tfplan` output is what humans need in the review thread; the binary stays in restricted storage. ## The tradeoff to be able to argue The alternative is not saving a plan at all and re-planning inside the apply job behind an approval gate. That removes the artefact and therefore the exposure, but it also removes the guarantee that what was reviewed is what runs. Neither answer is universally right, and an interviewer at senior level is listening for you to name both sides: diff equality costs you a sensitive artefact to protect, and skipping the artefact costs you diff equality. What is not acceptable is holding the artefact while pretending it is harmless. ## A related habit The same reasoning applies to plan output in logs. CI logs are searchable, long-lived and widely readable, and a plan that dumps resource attributes into them is a slower version of the same leak. Redaction in the printed diff helps here — which is the one place `sensitive` genuinely earns its keep.