In Terraform, what does marking an `output` block with `sensitive = true` actually hide, and what does it not protect?

## The one-line mental model `sensitive = true` on an output tells Terraform *do not render this value on my screen or in my logs*. It is a redaction flag on the presentation layer. Every conclusion below follows from taking that literally. ```hcl output "db_password" { value = random_password.db.result sensitive = true } ``` ## What it does hide **The plan and apply output.** Wherever Terraform would print the value — the diff for a changed output, the `Outputs:` block after apply — it prints `(sensitive value)` instead. This is the leak path that matters in practice, because plan and apply output is routinely pasted into pull requests and archived in CI job logs that are readable by everyone with access to the repository, often long after the secret was rotated. **Plain `terraform output`.** Reading outputs back from state renders sensitive ones as `<sensitive>` rather than the value. **Anything derived from it.** Sensitivity is *contagious* through expressions. If a sensitive value is interpolated into a string, put in a list, used as a map value, or passed through most functions, the result carries the sensitive mark too. This is what stops the naive workaround — building `"postgres://user:${var.password}@host"` and exporting that — from leaking anything. Terraform notices and, for an output, refuses to plan unless you mark the output sensitive as well. **Propagation across the module boundary.** If a child module's output is sensitive, the value stays sensitive in the caller that consumes it, so a parent cannot accidentally un-redact a child's secret by re-exporting it. ## What it does not do **It does not encrypt or omit anything from state.** The value is written to the state file in plain text with a flag saying it is sensitive. Anyone who can read the state can read the secret — which is why state protection (encryption at rest on the backend, tight bucket policy, no state file in git) is a separate and mandatory control. That is a topic of its own; the point here is simply that `sensitive = true` is not a substitute for it. **It does not stop deliberate retrieval.** `terraform output -json` and `terraform output -raw NAME` print sensitive values in clear text on purpose, because scripts need them. The JSON form marks the field with `"sensitive": true` next to the value — metadata, not redaction. So a CI step doing `terraform output -json > outputs.json` re-exposes everything the plan carefully hid. **It does not control providers or provisioners.** A provider that logs a request body, or a `local-exec` command that echoes an argument, prints whatever it was handed. `TF_LOG=DEBUG` likewise dumps request payloads. **It does not make the value safe to hold.** The secret still transits the machine running Terraform and lands in whatever the configuration writes it into. ## Where the mark comes from You do not always add it yourself. Providers mark inherently secret attributes sensitive in their schema — `random_password.result`, an RDS instance's `password` argument — and an input variable can be declared `sensitive = true`. Because sensitivity is contagious, those marks propagate outward through your configuration on their own, which is why an output you never thought of as secret can suddenly demand `sensitive = true`. ## Reading it in a review The useful review questions are: is the output redacted where it will be displayed; is the state backend encrypted and access-controlled; does any pipeline step run `terraform output -json`; and — the best answer — does this secret need to leave Terraform at all, or can the consumer read it from a secret store directly. Terraform 1.10 also added `ephemeral = true` for values that must not be persisted at all; an ephemeral output is never written to state and can only be consumed by a parent module, never at the root. ## The interview answer in one breath It redacts from Terraform's own display and propagates that redaction through derived expressions, so plan and apply logs stay clean. It is not encryption, not state protection, and not a barrier to `-json` or `-raw`.