Ephemeral Resources and Write-Only Arguments

For most of Terraform's life, any secret it touched ended up in state in plaintext — a database password it generated, a credential it fetched, a token it read. The sensitive flag hid those values from the console, but the bytes still sat on disk in the state file. Ephemeral resources (Terraform 1.10) and write-only arguments (1.11) are the direct fix: a way for values to flow through a run without ever being written to state.

These are recent additions, and provider support is still expanding — not every resource exposes write-only arguments yet. But they change the answer to "how do I keep secrets out of state" from "you can't, mitigate the blast radius" to "use the feature built for it, where the provider supports it."

The Secrets-in-State Problem

State records resource attributes so Terraform can diff against them, and that recording is indiscriminate. When you set an RDS instance's password, it lands in state. When random_password generates a credential, the generated value lands in state. A fetched secret, a private key, an access token — all plaintext, all on disk. Marking the value sensitive changes none of that; it only stops the value from printing in plan and apply output. The real exposure has always been the state file itself, which is why the earlier advice was to encrypt the backend and lock it down.

Ephemeral Resources

An ephemeral resource produces a value that exists only for the duration of a run and is never persisted to state. You declare it with the ephemeral block, and Terraform opens it when needed, hands the value to whatever consumes it, and closes it when the run ends. The classic use is fetching a short-lived credential or a secret to pass into another resource — the value is used in flight and then gone.

# fetch a secret at run time; its value is never written to state
ephemeral "aws_secretsmanager_secret_version" "db" {
  secret_id = aws_secretsmanager_secret.db.id
}

The result is referenced like any other resource, but it cannot be stored — you can use it within the same apply, pass it to a write-only argument, or surface it through an ephemeral output, and that is all. Terraform enforces that an ephemeral value never crosses into state.

Write-Only Arguments

A write-only argument is an argument a provider sends to its API but deliberately does not save to state. A database password is the canonical example: the provider needs the value to create or update the instance, but there is no reason to keep it on disk afterward. Because the value is not in state, Terraform can't compare it across runs to decide whether it changed — so a write-only argument is paired with a version argument that you bump to signal "the secret changed, send it again."

resource "aws_db_instance" "main" {
  engine   = "postgres"
  username = "app"

  # the value is sent to the API but never stored in state
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db.secret_string
  # bump this when the secret rotates so the provider re-sends it
  password_wo_version = 2
}

Without the version argument the provider has no way to know an out-of-band rotation happened, because it can't see the old value to compare. Incrementing password_wo_version is the explicit "update it now" signal. Pair an ephemeral resource with a write-only argument and a secret can travel from a secrets store to an API without ever touching state.

Ephemeral Values in Variables and Outputs

The ephemeral property extends to the configuration's edges. An input variable can be marked ephemeral = true so a secret passed in at run time is never persisted, and an output can be marked ephemeral so it can carry a value between modules within a run without landing in state. This lets a secret flow end to end — in through a variable, through the modules, out to an argument — without a single plaintext copy on disk.

Adoption and Provider Support

Ephemeral resources require Terraform 1.10 and write-only arguments require 1.11, so neither exists on older versions. More limiting in practice is provider coverage: a provider has to explicitly add a write-only variant of an argument, and that rollout is ongoing rather than complete. Before you design around these features, check the resource's Registry documentation for the write-only argument or ephemeral resource you intend to use — and have the state-encryption-and-lockdown approach ready as the fallback where support hasn't landed yet.