A Terraform configuration generates a database password with the random_password resource and passes it to an RDS instance. After apply, where does that password exist in plaintext, and why does marking the corresponding output sensitive = true not change that?

## Why the secret is in state at all Terraform state is the record that lets Terraform answer "what do I already manage, and what does it currently look like?". For each resource address it stores the provider that owns it, the real object's identifier, and a cached copy of the resource's attributes — both the arguments you configured and the values the provider computed. That cache is what the next plan diffs your configuration against. There is no filtering step in that write. If a resource has an attribute whose value is a secret, the secret is what gets cached. `random_password` computes its generated string into `result`; `aws_db_instance` persists the `password` argument you gave it. Both land in the JSON as ordinary strings: ```json "attributes": { "length": 32, "result": "Qk3vT8sZr..." } ``` This is documented behaviour, not a bug: HashiCorp states plainly that Terraform stores state values in plain text and that anyone with access to state must be treated as having access to the secrets in it. ## What the sensitive marker actually does `sensitive = true` on a variable or output — and the automatic sensitivity that some provider attributes carry — is about *rendering*. Its effects are: - plan and apply diffs show `(sensitive value)` instead of the string; - `terraform output <name>` prints `<sensitive>`, and you must ask for `-raw` to get the value; - sensitivity propagates through expressions, so a value derived from a sensitive one is also redacted. Its non-effects are the ones that matter here: it does not encrypt anything, does not omit anything from state, and does not stop `terraform output -json` from including the value (it merely tags it). Treating the marker as a storage control is the single most common misconception on this topic. ## Every place the plaintext copy ends up Thinking of "the state file" as one object under-counts the exposure: - `terraform.tfstate` and the automatically written `terraform.tfstate.backup` when running with local state; - the object in the remote backend — and, if the bucket has versioning enabled, *every previous version* of that object; - a saved plan file from `terraform plan -out=tfplan`, which embeds the prior state plus planned attribute values and is not encrypted; - anything derived from those: `terraform show -json`, `terraform state pull`, CI job artifacts, a developer's working directory; - provider debug logs, since `TF_LOG=trace` can record request and response bodies. Rotating the credential later does not retroactively clean any of these copies. ## What actually protects it Three layers, in increasing order of strength. **Contain it.** Never commit state or plan files. Use a remote backend with encryption at rest and a tight access policy, so the set of identities that can read state is the set you would trust with production credentials. Prefer short-lived pipeline credentials over static keys. **Reduce what is in there.** Do not pass secrets through Terraform when the platform can generate and hold them itself. For RDS, `manage_master_user_password = true` has AWS create and store the master password in Secrets Manager, so no password value ever traverses your configuration or state. **Keep it out of state structurally.** Terraform 1.10 added ephemeral values and 1.11 added write-only resource arguments, which accept a value for the duration of a single apply and are never persisted to state or to a plan file. Where a provider implements them, this is the only mechanism that makes the plaintext genuinely absent rather than merely protected. It is also worth knowing the ecosystem contrast: OpenTofu added client-side state encryption in 1.7, so its state can be encrypted before it leaves the machine. Terraform has no equivalent — its at-rest protection is entirely whatever the backend provides. ## The interview answer Say where the value lives (state, backup, saved plan, every prior object version), say what the marker does (redaction, not storage), and then name the mitigation ladder: access control on the backend, no state in version control, provider-managed secrets, and ephemeral or write-only arguments where available. A candidate who says "we mark it sensitive so it is safe" has answered the display question and missed the storage question entirely.