A database resource sets its password through a write-only argument fed by an ephemeral value, with the companion version argument set to 1. Security rotates the password in Vault, but terraform plan reports no changes. How should the team push the new password to the database?
Select an answer to reveal the explanation.
Short Explanation
Terraform never keeps a copy of a write-only value, so it can't notice that the password changed; it's comparing against nothing. The version argument is your doorbell: bump it, and the provider knows to use the new password. Replacing the whole database to change a password is like moving house to change the locks.
Full Explanation
Terraform does not store write-only argument values in plan or state, so it has no previous value to compare against and cannot produce a diff when the secret changes. Providers pair each write-only argument with a version argument, such as password_wo_version, which is stored in state like any normal attribute. Changing that version, for example from 1 to 2, creates a planned update, and the provider uses the current write-only value during that apply. A refresh-only apply updates state from remote objects; it does not read Vault on the resource's behalf and has no write-only value in state to update, since none is ever stored. Forcing replacement would rebuild the database, which is destructive and unnecessary; write-only values are sent during operations, not only at creation, and the version argument exists to apply them in place. ignore_changes does not hold write-only values, so toggling it changes nothing about what is sent and still produces no diff. Exam caveat: version argument names and update behaviour are provider-specific, so check the resource documentation. Operational check: set the version to 2, confirm the plan shows an in-place update of the version, apply, and then verify the application can log in with the rotated password.