4.5.2. Managing Sensitive Data
💡 First Principle: The real question with any secret is "does this value get written to state or plan files?" — and the answer depends on which mechanism you use, because sensitive only hides values from display while ephemeral values and write-only arguments actually keep them out of persistence.
Terraform offers a layered approach to secrets, and 004 expects you to distinguish them:
| Mechanism | What it does | Stored in state? |
|---|---|---|
sensitive = true (var/output) | Hides value in CLI/plan output | Yes (still plaintext in state) |
sensitive() function | Marks a value sensitive inline | Yes |
| Ephemeral values (1.10+) | Exist only during a single operation; ephemeral variables, resources, outputs | No — never persisted |
| Write-only arguments (1.11+) | Resource arguments sent to the provider but not saved | No — not stored in state |
| Vault provider | Fetch secrets at runtime | Depends — data-source reads still land in state |
The crucial mental shift for 004: marking something sensitive does not protect state — the value remains in terraform.tfstate in plaintext. Ephemeral values and write-only arguments are the features that genuinely avoid persisting secrets. Because state can hold secrets regardless, protecting state itself (encryption, access control, remote backends) remains essential, and combining Terraform with a secrets manager like Vault is the recommended pattern for production.
⚠️ Exam Trap: Two facts collide here and are heavily tested. (1) sensitive only suppresses output display; the value still sits in state. (2) Even reading a secret via a Vault data source writes it into state. To truly avoid persistence, use ephemeral values / write-only arguments. Answers claiming sensitive "encrypts" or "removes from state" are wrong.
Reflection Question: A teammate marks a database password variable sensitive and assumes it's now safe. What's still exposed, and which 1.11-era feature would actually keep that password out of state?
