A team wants the database credentials Terraform uses during each run to be created on demand and to expire automatically shortly after the run, so no credential outlives the run that used it. They already operate Vault. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
Static secrets are like a spare key you leave under the mat; dynamic secrets are a hotel key card that stops working at checkout. Vault's database secrets engine mints a fresh credential per request with a lease that expires on its own. Read it through an ephemeral resource and it never lands in state either.
Full Explanation
Vault dynamic secrets engines, such as the database engine, generate a unique credential for each request and attach a lease with a time to live; when the lease expires or is revoked, Vault deletes the credential from the target system. Terraform can request such credentials through the Vault provider's ephemeral resources, for example an ephemeral database secret, so the credential exists only for the run, is never written to plan or state, and is cleaned up by Vault afterwards. A KV secret is static: it stores whatever value was written, shared by every consumer, and an hourly overwrite still leaves a credential valid well beyond any single run. A random_password managed resource generates a value that is stored in state and has no expiry; keepers only control when a new value is generated. A long-lived workspace variable with manual revocation depends on people remembering, and the credential persists between change windows. Exam caveat: lease TTLs must be long enough to cover the slowest run, including apply, or operations fail mid-run. Operational check: run a plan, confirm a new lease appears in Vault for the run, and verify the generated database user disappears after the TTL.