To debug a failing connection, a developer adds output "db_password" { value = nonsensitive(var.db_password) } to a shared module, where var.db_password is declared with sensitive = true, and merges the change. What is the main risk?
Select an answer to reveal the explanation.
Short Explanation
nonsensitive() is you telling Terraform "trust me, this isn't secret." Point it at a real password and Terraform takes you at your word and prints it everywhere: CLI output, CI logs, the run UI. The function has legit uses, like a hash of a secret, but this isn't one.
Full Explanation
nonsensitive takes a sensitive value and returns a copy with the sensitive marking removed. Terraform then renders the value normally, so an output built from nonsensitive(var.db_password) shows the plaintext password in plan and apply output, in CI job logs that capture that output, and in the HCP Terraform run and outputs views. The documentation warns that the function should be used sparingly and only when the expression genuinely strips all sensitive content, for example a hash of a secret or a non-secret fragment of a larger value. Claiming the change newly puts the password into state misunderstands sensitivity: sensitive values were already stored in state, and the new exposure is in rendered output. The function does not distinguish derived from direct values; it unmarks whatever it receives. Terraform errors only when nonsensitive is called on a value that is not sensitive, calling it redundant; a sensitive argument is exactly its intended input. Exam caveat: output values from shared modules propagate to every caller, so one debugging change can leak in many workspaces. Operational check: revert the output, rotate the password, and scan recent run logs and outputs for the exposed value.