A team needs a database administrator password to be supplied at apply time and never written to the plan file or to state. The provider's database resource offers a write-only password argument. Which configuration meets the requirement?
Select an answer to reveal the explanation.
Short Explanation
An ephemeral value is like a visitor badge that gets shredded at the end of the day: it works while you're there and leaves no record. Pair it with a write-only argument and the password never lands in plan or state. The trap is reaching for sensitive, which only hides the value on screen.
Full Explanation
Ephemeral input variables are available during a run but Terraform omits them from state and plan files. Write-only arguments, added in Terraform 1.11, are the matching resource-side mechanism: the provider receives the value to configure the resource and Terraform discards it without persisting it. On aws_db_instance the write-only argument is password_wo, with a companion password_wo_version argument that the operator increments to signal a new password, because Terraform cannot detect a change in a value it never stores. A sensitive variable passed to the regular password argument is redacted in output but still written to state, which fails the requirement. Returning the password from an output and reading it through terraform_remote_state stores it in two state files instead of none. terraform_data stores its input argument in state and exposes it as the output attribute, so routing the secret through it persists the value rather than hiding it. Exam caveat: a write-only argument also accepts non-ephemeral values, but only an ephemeral source keeps the secret out of every artifact, including the variable's own plan entry. Operational check: after apply, run terraform show on the state and confirm the password attribute appears as null while the version attribute holds its current value.