Terraform 1.10 introduced ephemeral values and 1.11 added write-only resource arguments. What problem do they solve that marking a value sensitive never could, and what constraint does a write-only argument place on your configuration?

## The gap these fill Before Terraform 1.10 there were two honest answers to "how do I keep this password out of state?" — don't put it in Terraform, or accept that it is in state and protect state accordingly. Sensitivity marking was never an answer: it governs rendering only. Ephemeral values and write-only arguments close that gap by adding a category of value that Terraform is *forbidden* from persisting. ## Ephemeral values (Terraform 1.10) Three things can be ephemeral: - **Ephemeral resources**, declared with the `ephemeral` block type. They are opened when needed during a run and closed at the end; nothing about them goes into state or the plan file. Providers implement them for exactly this shape of task — the AWS provider ships `ephemeral "aws_secretsmanager_secret_version"` for reading a secret at apply time. - **Ephemeral input variables**, declared with `ephemeral = true`. Terraform accepts the value for the run and refuses to write it anywhere durable. - **Ephemeral outputs**, which can pass such a value between modules within a run but not out into stored state. The rule Terraform enforces is that an ephemeral value may only flow into places that also do not persist: another ephemeral value, a provider configuration argument, or a write-only argument. Try to assign one to an ordinary resource argument and the configuration fails — which is the point. The prohibition is checked, not merely documented. ```hcl ephemeral "aws_secretsmanager_secret_version" "db" { secret_id = "prod/app/db" } ``` ## Write-only arguments (Terraform 1.11) A write-only argument is a managed-resource argument whose value is sent to the provider during apply and then discarded. It is never in state, never in the plan file, and never returned by a refresh. Providers name them with a `_wo` suffix, and the canonical example is RDS: `password_wo` alongside `password_wo_version` on `aws_db_instance`. ```hcl variable "db_password" { type = string ephemeral = true } resource "aws_db_instance" "main" { identifier = "app-prod" engine = "postgres" instance_class = "db.t4g.medium" allocated_storage = 20 username = "app" password_wo = var.db_password password_wo_version = 1 skip_final_snapshot = true } ``` ## The constraint, and why it is not a wart Terraform's entire model is *compare desired configuration to recorded state*. Remove the record and the comparison is impossible: Terraform genuinely cannot know whether the password you are supplying today differs from the one it sent last week. Rather than pretend, the design makes the trigger explicit. You bump `password_wo_version` to 2 and the plan shows an update that re-sends the value. Several consequences follow, and naming them is what separates a candidate who has read the release notes from one who has used the feature: - **Rotation becomes a declared change**, visible in a diff and reviewable in a pull request — arguably better than a silent value swap that shows as `(sensitive value) -> (sensitive value)`. - **Drift on that attribute is invisible.** If someone changes the password out of band, Terraform will not notice, because it has nothing to compare and the provider does not read it back. - **Not every argument supports it.** Write-only is opt-in per provider and per attribute; if the provider has not implemented it, the old rules apply. - **Only managed resources.** Data sources and outputs use the ephemeral mechanisms instead. ## Where they fit in the ladder Order the mitigations honestly. Best is not routing a secret through Terraform at all — for RDS, `manage_master_user_password = true` has AWS generate and hold the master password in Secrets Manager. Next best is write-only or ephemeral, where the value passes through the run and is never persisted. Below that sits everything about protecting the state that *does* contain the secret: backend access policy, encryption at rest, no state in Git. Sensitivity marking is not on this ladder at all; it belongs on a different one about not printing secrets into terminals and logs.