A root variable carrying a database password appears in clear text in plan output in CI logs. The team wants it hidden from CLI output today and needs to understand what risk remains afterwards. Which statement describes the right change and its limits?
Select an answer to reveal the explanation.
Short Explanation
sensitive is a pair of sunglasses for your terminal, not a safe for your state file. You stop the password showing up in logs, but anyone who can read state can still read it. The trap is assuming redaction means encryption.
Full Explanation
Marking a variable sensitive tells Terraform to redact the value, and anything derived from it, wherever it would appear in plan or apply output, so the CI logs stop showing the password immediately. The value is still needed to configure the resource, and Terraform records it in state like any other argument value; the documentation warns that anyone with access to state data can read sensitive values. The remaining risk is therefore state access, which must be controlled through backend permissions and encryption at rest. Terraform itself does not encrypt individual values in state, so the claim that sensitive encrypts the value for the backend is wrong. An ephemeral variable is different: Terraform omits ephemeral values from state and plan files, and it can only be referenced in ephemeral contexts such as write-only arguments, so it neither stores the plain value nor works as a drop-in replacement on an ordinary argument. nonsensitive() does the reverse of what is wanted; it strips the sensitive marking and causes the value to be displayed. Exam caveat: keeping a secret out of state entirely requires ephemeral values and write-only arguments, not the sensitive flag. Operational check: run terraform plan and confirm the password shows as sensitive, then inspect state access permissions on the backend.