A module generates a database password with the random_password resource and passes its result to a resource's write-only password argument, yet the password still appears in state. The random provider version in use supports ephemeral resources. What change keeps the generated password out of state?
Select an answer to reveal the explanation.
Short Explanation
You plugged the leak at the database end, but the password generator is a managed resource, and managed resources save their results in state. Switch the generator to the ephemeral random_password and nothing's written down anywhere. Wrapping or hiding the old resource doesn't change the fact that it's stored.
Full Explanation
A managed random_password resource stores its result attribute in state, because Terraform keeps every managed resource's attributes so the value stays stable across runs. Using a write-only argument downstream prevents a second copy on the database resource, but the generator itself still holds the password. The random provider offers an ephemeral random_password resource that generates a value during the operation and never records it in plan or state; referencing ephemeral.random_password.name.result in the write-only argument leaves no stored copy. The sensitive() function marks a value for redaction in output but does not affect what is written to state. ignore_changes controls whether configuration changes trigger updates; it has no influence on persistence, and the managed resource's result remains in state. Moving the resource into a child module changes its address but not where it is stored: child module resources are part of the same state, and an ephemeral output does not remove the resource's attributes. Exam caveat: an ephemeral password is regenerated on each run, so the companion version argument decides when the database actually receives a new one, and the value must be saved elsewhere if humans need it. Operational check: apply and confirm no random_password resource remains in terraform state list.