A configuration uses an ephemeral random_password block and passes its result to a resource's write-only password argument. After apply, an engineer runs terraform state list and terraform show and finds no entry for the ephemeral block, and wonders whether state is broken. What explains this?
Select an answer to reveal the explanation.
Short Explanation
Ephemeral means exactly what it sounds like: it exists for the run and then it's gone, by design. You won't find it in state or the plan, and that's the whole point. The trap is treating a missing entry as corruption when it's the security feature working.
Full Explanation
Ephemeral resources, declared with the ephemeral block, have a distinct lifecycle: Terraform opens them during an operation, uses their values, and does not store any information about them in state or plan files. Write-only arguments on managed resources are their counterpart; they accept values, including ephemeral ones, for the current operation only, and Terraform discards those values without saving them in plan or state. Together they let a configuration generate a temporary password and hand it to a resource without the secret ever being persisted, which is why neither terraform state list nor terraform show reports the ephemeral block. Refresh-only applies update recorded attributes of managed resources; they never add ephemeral resources to state. Ephemeral entries are not hidden by state list, so querying one by address with state show fails, because there is nothing at that address in state. Terraform does not prune blocks based on how their values are used; the absence comes from the ephemeral lifecycle itself. Exam caveat: because the write-only value is not stored, Terraform cannot detect when it changes, so providers pair the argument with a version argument that must be changed to send a new value. Operational check: confirm the managed resource appears in state with its version argument recorded and no password value, which is the expected result.