A configuration reads a database admin password from Vault's KV version 2 engine with a data source and passes it to a database resource's password argument, so the password appears in state. The Vault provider and the database resource both support Terraform's ephemeral and write-only features. Which pattern keeps the password out of state entirely?
Select an answer to reveal the explanation.
Short Explanation
Two leaks, two plugs. A data source writes what it reads into state, so you swap it for the ephemeral version, and a regular argument saves what you give it, so you swap that for the write-only one. Fix only one end and the secret still lands in state.
Full Explanation
Data source results are persisted in state, so a vault_kv_secret_v2 data source stores the secret's data there; a regular resource argument stores the password again in the resource's attributes. The Vault provider offers an ephemeral vault_kv_secret_v2 resource that reads the secret during the operation without recording anything in plan or state. Ephemeral values may only flow into ephemeral contexts, and a write-only argument on the database resource is one, so referencing the ephemeral result there delivers the password to the provider while Terraform discards it afterwards. Marking a variable sensitive leaves both copies in state; it only hides them in output. Feeding an ephemeral value to a regular argument is not silently dropped; Terraform reports an error because that argument would persist the value. ignore_changes stops Terraform from planning updates when the attribute differs, but the data source still stores the secret and the resource still records the original password. Exam caveat: write-only arguments require Terraform 1.11 or later and provider support, and changing the value needs the companion version argument. Operational check: after applying, inspect state and confirm no data source entry for the secret and no password attribute on the database resource.