Terraform Ephemeral Values for the Terraform Associate (004) Exam: Ephemeral Resources, Ephemeral Variables & Outputs, Write-Only Arguments and Keeping Secrets Out of State

For most of Terraform’s life there was an uncomfortable truth that every practitioner eventually discovered: sensitive = true hides a value from your terminal and from nothing else. The database password you carefully marked sensitive still landed in terraform.tfstate as plain text, and in every saved plan file, and in every state snapshot your backend kept. The only real defences were to encrypt the state at rest, lock down who could read it, and hope.

Terraform 1.10 changed the model. Ephemeral values are values that Terraform uses during an operation and then throws away. They never reach the plan file and never reach the state file, because the language itself refuses to let them flow anywhere that would be persisted. Terraform 1.11 completed the picture with write-only arguments, so that a password can be sent to a provider without ever being stored by Terraform.

The HashiCorp Terraform Associate (004) exam lists “Ephemeral values and write-only arguments” as one of its four new topics, filed under objective 4h, “Understand best practices for managing sensitive data, including secrets management with Vault”, and the exam tests against Terraform 1.12, where both features are fully available. The existing guide to variables, outputs and locals covers sensitive in depth, and the state management guide explains why state is a secret-bearing artifact. This article is the piece in between: what ephemeral values are, exactly where they may and may not be used, how the lifecycle works, and how the exam frames the difference between hidden and never stored.

Why sensitive Was Never Enough

Start with what sensitive actually does, because the exam loves to test the gap between what people assume and what the documentation says.

Marking a variable or output as sensitive = true tells Terraform to redact the value in CLI output. Plan and apply logs show (sensitive value) instead of the real string. That is the whole feature. The HashiCorp documentation is blunt about the rest: Terraform “still records sensitive values in state”, so “anyone who can access your state data can access your sensitive values”. Worse, terraform output -json and terraform output -raw print sensitive outputs in plain text on purpose, because those flags exist for automation.

There is a structural reason Terraform kept storing the value. State is how Terraform detects drift: to decide whether a password changed, it has to remember what the password was. A value that must be compared across runs must be persisted. The sensitive-variables tutorial that objective 4h points to says it directly: marking variables as sensitive “is not sufficient to secure them”.

That leaves three layers of mitigation that were the standard advice before 1.10, and which remain correct today:

Layer	What it does	What it does not do
sensitive = true	Redacts CLI output	Does nothing for state or plan files
Remote backend with encryption at rest and access control (HCP Terraform, S3 with SSE and a tight bucket policy)	Protects the state file	The secret is still inside the file for anyone with read access
Secrets manager (Vault, AWS Secrets Manager, Azure Key Vault) as the source of truth	Keeps the long-lived secret out of your repository and tfvars	A data source that reads the secret still copies it into state

The last row is the one that bit people hardest. Reading a secret through a classic data "vault_generic_secret" or data "aws_secretsmanager_secret_version" block puts the secret in state, because data source results are stored like everything else. You moved the secret out of Git and straight into the state file.

Ephemeral values exist to close that loop.

What an Ephemeral Value Is

An ephemeral value is a value that Terraform guarantees it will not persist to the plan file or the state file. The 1.10 changelog phrases the guarantee precisely: ephemeral values “may only be used in certain contexts in Terraform configuration” and “are not persisted to the plan or state files”.

That second clause is enforced by the first. Terraform does not try to scrub ephemeral values out of files after the fact. Instead, the language only lets an ephemeral value flow into places that are never written to disk, and raises a planning error if you try to use one anywhere else. Ephemerality is also contagious: any expression that references an ephemeral value becomes ephemeral itself, which is how a locals entry built from an ephemeral resource stays out of state too.

There are four sources of ephemeral values, and one function and one symbol that interact with them:

Feature	Introduced	What it is
ephemeral resource blocks	Terraform 1.10	A resource-like block whose result exists only during the operation
ephemeral = true on input variables	Terraform 1.10	A variable whose value is omitted from plan and state
ephemeral = true on child-module outputs	Terraform 1.10	An output that passes ephemeral data between modules
Write-only arguments (*_wo)	Terraform 1.11	Resource arguments the provider accepts but Terraform never stores
terraform.applying	Terraform 1.10	An ephemeral boolean that is true only during apply
ephemeralasnull()	Terraform 1.10	Replaces ephemeral parts of a value with null so the rest can be persisted

The 004 exam tests on Terraform 1.12, so all six are in scope.

The Seven Ephemeral Contexts

This is the list to memorise. An ephemeral value may be referenced in exactly these places, and nowhere else:

1. A write-only argument on a managed resource.
2. Another ephemeral block.
3. A locals block (the local becomes ephemeral).
4. A variable block declared with ephemeral = true.
5. A child module output block declared with ephemeral = true.
6. A provider block, to configure a provider.
7. A provisioner or provisioner connection configuration.

What is not on the list matters just as much:

• A normal (non-write-only) argument on a resource. Resource arguments are stored in state, so the reference is rejected.
• A data source argument. Data source results are stored in state.
• A root module output. Root outputs are stored in state, so the documentation states flatly: “You cannot add the ephemeral argument to output blocks in the root module.”
• count, for_each or any other meta-argument that shapes the plan.

The documentation’s one-line rule: if you use an ephemeral value outside these contexts, “Terraform throws an error when it plans your changes”. The error happens at plan time, before anything is written, which is exactly the point.

Ephemeral Resources

Syntax

An ephemeral resource looks like a resource or data source with a different block keyword and a different reference prefix:

ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

# referenced as ephemeral.<TYPE>.<NAME>
# ephemeral.random_password.db_password.result

The provider decides which types are available as ephemeral resources. The AWS provider offers aws_secretsmanager_secret_version and aws_ssm_parameter ephemerally, the Random provider offers random_password, and the Vault provider offers ephemeral resources for dynamic secrets such as vault_kv_secret_v2 and database credentials. The Terraform Registry lists them in a separate “Ephemeral Resources” section of each provider’s documentation.

The Open, Renew, Close Lifecycle

This is the part of ephemeral resources that is genuinely new, and the part the exam can ask about directly. Managed resources are created, read, updated and deleted. Data sources are read. Ephemeral resources have a three-step lifecycle of their own:

1. Open. “Terraform opens an ephemeral resource if it needs access to the resource’s result.” Nothing is opened speculatively; the open happens when a dependent needs the value.
2. Renew. If Terraform needs the value for longer than the remote system allows, “Terraform asks the ephemeral resource’s provider to periodically renew access.” This is designed for Vault leases and short-lived cloud credentials that expire mid-apply.
3. Close. “Terraform closes the ephemeral resource after the providers that depend on that resource complete their work.” For a Vault dynamic secret, close means the lease is revoked and the credentials stop working immediately.

The practical consequence is that an ephemeral resource is read anew during each phase. It is opened during plan if the plan needs it (for example to configure a provider) and opened again during apply, because the plan file carried nothing over. The 1.10 changelog describes ephemeral resources as “read anew during each phase of Terraform evaluation, and cannot be persisted to state storage”.

Two consequences follow for exam scenarios:

• The result can legitimately differ between plan and apply. A random_password ephemeral resource generates a different password at apply time than it did at plan time. That is fine for a write-only argument (the provider receives whatever the apply-time value is) but it is why you cannot feed the value into an ordinary argument that must be planned.
• If an ephemeral resource depends on a value only known after apply, “Terraform defers executing that resource until the apply stage.”

Meta-Arguments on Ephemeral Blocks

Ephemeral blocks support a familiar subset of meta-arguments:

Meta-argument	Supported?	Notes
count	Yes	Mutually exclusive with for_each
for_each	Yes	Map or set of strings, as with resources
depends_on	Yes	Sequences upstream work before the open
provider	Yes	provider = aws.secondary style aliases
lifecycle	Partially	Only precondition and postcondition blocks
provisioner	No	Provisioners attach to managed resources

The lifecycle row is a trap worth noting. create_before_destroy, prevent_destroy, ignore_changes and replace_triggered_by do not make sense for something that is never stored, so only the two custom condition blocks are allowed. Preconditions are evaluated before the resource is opened; postconditions after.

Ephemeral Resource vs Data Source

The exam will almost certainly put a data block and an ephemeral block side by side and ask which one to use. The decision rule:

	data source	ephemeral resource
When read	During plan (or apply if deferred)	Opened when needed, in every phase
Stored in plan file	Yes	No
Stored in state	Yes	No
Can feed any resource argument	Yes	Only write-only arguments and other ephemeral contexts
Can configure a provider	Yes	Yes
Lifecycle	Read	Open, renew, close
Right for	Looking up IDs, AMIs, VPCs, anything non-secret	Credentials, tokens, passwords, anything you must not persist

If the scenario says “the secret must not appear in state” the answer is an ephemeral resource. If it says “look up the latest AMI ID”, a plain data source, as covered in the data sources guide, is correct and an ephemeral block would be wrong because the AMI ID is needed in a normal resource argument.

Ephemeral Input Variables

Add ephemeral = true to a variable block and Terraform “omits ephemeral values from state and plan files”. The canonical example is short-lived cloud credentials used to configure a provider:

variable "access_key" {
  description = "AWS access key"
  type        = string
  ephemeral   = true
}

variable "secret_key" {
  description = "AWS secret key"
  type        = string
  ephemeral   = true
  sensitive   = true
}

variable "session_token" {
  description = "AWS session token"
  type        = string
  ephemeral   = true
  sensitive   = true
}

provider "aws" {
  access_key = var.access_key
  secret_key = var.secret_key
  token      = var.session_token
}

Three points to carry into the exam:

• ephemeral and sensitive are independent and combinable. sensitive controls CLI redaction; ephemeral controls persistence. A credential you never want printed and never want stored gets both. The example above sets sensitive only on the two values that would be damaging if echoed, which is the pattern in the official reference.
• Ephemeral variables can only flow into ephemeral contexts. The documentation describes this as adding “restrictions to the values you can assign that variable”. Put var.access_key into a normal resource argument and the plan fails.
• Saved plan files do not carry the value. Because the plan file omits ephemeral variables, a two-step terraform plan -out=tfplan followed by terraform apply tfplan must be given the ephemeral values again at apply time. Terraform 1.10 relaxed the saved-plan rule so that -var and -var-file are accepted alongside a plan file for exactly this purpose. Non-ephemeral variables still cannot be changed at apply time, because they are baked into the plan.

Values can be supplied by any of the usual mechanisms described in the variables guide: TF_VAR_ environment variables, -var, -var-file, or HCP Terraform variable sets. Environment variables are the natural fit for a CI pipeline that mints short-lived credentials per run.

Ephemeral Outputs in Child Modules

Outputs can be ephemeral too, with one hard restriction: only in child modules. The purpose is to pass temporary data between modules, for example a module that opens a Vault lease and hands the credentials to a sibling module that configures a database provider.

# modules/db-creds/main.tf
ephemeral "vault_database_secret" "app" {
  mount = "database"
  name  = "app-role"
}

output "username" {
  value     = ephemeral.vault_database_secret.app.username
  ephemeral = true
}

output "password" {
  value     = ephemeral.vault_database_secret.app.password
  ephemeral = true
  sensitive = true
}

The documentation lays down two conditions for an ephemeral output: “The value of the output block must come from an ephemeral context” and “You can only reference that output in other ephemeral contexts.” So module.db_creds.password can feed a provider "postgresql" block or a write-only argument, but not a regular resource argument and not a root output.

Why can the root module not have ephemeral outputs? Root outputs are stored in state so that terraform output and terraform_remote_state can read them later. An ephemeral root output would be a contradiction, which is why Terraform rejects it at validation rather than silently dropping the value.

Write-Only Arguments

Ephemeral resources solve the reading side: get a secret without storing it. Write-only arguments, added in Terraform 1.11, solve the writing side: give a secret to a resource without storing it.

How They Work

A write-only argument is a resource argument that the provider has marked as write-only. The 1.11 changelog states the contract in three lines: “Providers can specify that certain attributes are write-only”, “They are not persisted in state”, and “You can use ephemeral values in write-only attributes”. By convention the AWS and Azure providers name them with a _wo suffix:

ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
  password_wo         = ephemeral.random_password.db_password.result
  password_wo_version = 1
}

When Terraform creates the instance it sends password_wo to the AWS provider, the provider uses it in the API call, and then, in the documentation’s words, Terraform “discards the password value without ever storing it”. The state file records password_wo as null. Note that write-only arguments “accept both ephemeral and non-ephemeral values”, so a plain string literal is legal, just not recommended.

The Version Companion

If Terraform never stores the password, it cannot tell when the password changes. The documentation is explicit: Terraform “has no way of knowing if a write-only argument value has changed” and “cannot create plan diffs for write-only arguments”. That is why every write-only argument ships with a companion such as password_wo_version.

The version argument is an ordinary, stored, planned attribute. Change it and the provider is told to re-send the current write-only value:

resource "aws_db_instance" "main" {
  # ...
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db.secret_string
  password_wo_version = 2   # bumped from 1 to rotate the password
}

The exam phrasing to expect: “A team rotated the secret in Secrets Manager but the database still has the old password after terraform apply. Why?” The answer is that the write-only value is not diffed; nobody incremented password_wo_version. The implementation of version arguments is provider-specific, but the pattern is universal across the HashiCorp-maintained providers.

Capturing a Generated Secret

Because write-only values are discarded, a generated password has to be captured somewhere or it is lost. The documented pattern writes it to a secrets manager through another write-only argument, then reads it back through an ephemeral resource:

ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_secretsmanager_secret" "db_password" {
  name = "db_password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id                = aws_secretsmanager_secret.db_password.id
  secret_string_wo         = ephemeral.random_password.db_password.result
  secret_string_wo_version = 1
}

ephemeral "aws_secretsmanager_secret_version" "db_password" {
  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
}

resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
  password_wo_version = aws_secretsmanager_secret_version.db_password.secret_string_wo_version
}

Trace the secret through this configuration and you will find it is never in state: generated ephemerally, written to Secrets Manager write-only, read back ephemerally, passed to RDS write-only. The only values in state are the secret’s ARN and the integer 1. Tying password_wo_version to secret_string_wo_version means rotating the stored secret and rotating the database password are a single version bump.

The same pattern exists for Azure with azurerm_key_vault_secret (value_wo and value_wo_version) and azurerm_mysql_flexible_server (administrator_password_wo).

terraform.applying and ephemeralasnull

Two smaller 1.10 additions round out the feature and both are fair game on the exam.

terraform.applying is an ephemeral boolean that is true during the apply phase and false during plan. Being ephemeral, it can only be used in ephemeral contexts, which in practice means provider configuration. The motivating use case is least privilege: plan with a read-only role, apply with a role that can write.

locals {
  aws_read_role_arn  = "arn:aws:iam::123456789012:role/terraform-plan"
  aws_write_role_arn = "arn:aws:iam::123456789012:role/terraform-apply"
}

provider "aws" {
  region = "eu-west-1"
  assume_role {
    role_arn = terraform.applying ? local.aws_write_role_arn : local.aws_read_role_arn
  }
}

ephemeralasnull(value) “takes a value of any type and returns a similar value of the same type with any ephemeral values replaced with non-ephemeral null values and all non-ephemeral values preserved”. It exists for the case where a map or object mixes ephemeral and ordinary values and you want to persist the ordinary part, for example in a root output:

variable "session_token" {
  type      = string
  ephemeral = true
}

locals {
  settings = {
    env   = "development"
    token = var.session_token   # this local is now ephemeral
  }
}

output "settings" {
  value = ephemeralasnull(local.settings)
  # returns { env = "development", token = null }
}

Without the function, the root output would be rejected because local.settings is ephemeral. With it, the non-secret parts are stored and the token becomes null.

Vault and Objective 4h

Objective 4h names Vault explicitly, and the ephemeral model is what makes the Vault provider’s dynamic secrets safe to use from Terraform. The flow the exam expects you to recognise:

1. Terraform authenticates to Vault (AppRole, OIDC, or a token from the environment).
2. An ephemeral Vault resource requests a dynamic secret: a database username and password generated on demand with a short lease.
3. The credentials flow into a provider block or a write-only argument.
4. When the dependent provider finishes, Terraform closes the ephemeral resource, Vault revokes the lease, and the credentials are dead. Nothing was stored.

Compare that with the pre-1.10 approach, where a data "vault_generic_secret" block copied the credentials into state and they stayed valid, and readable, for as long as the state existed. The sensitive-variables tutorial’s advice to use a secrets manager was always right; ephemeral values are what make it complete.

For a broader picture of where Vault sits in the HashiCorp ecosystem, the Terraform Associate exam guide covers the adjacent HashiCorp Vault Associate credential, which goes much deeper into leases, dynamic secrets engines and auth methods than the Terraform exam ever will.

HCP Terraform and Ephemeral Values

A common follow-up question is how any of this interacts with HCP Terraform, which encrypts state and variables at rest. Two things to keep straight:

• HCP Terraform sensitive variables are a workspace feature: the UI will not show the value again after you save it (the tutorial calls this “write-only” in the HCP Terraform sense). That protects the variable store, not the state file. A sensitive workspace variable that feeds a normal resource argument still ends up in state.
• Ephemeral values are a language feature and behave identically in HCP Terraform, the CLI and Terraform Enterprise. Combine them: store the Vault token as a sensitive workspace variable, declare the matching variable block with ephemeral = true, and use it only to configure the Vault provider.

The HCP Terraform guide covers workspace variables, variable sets and the run environment in detail.

How the Exam Frames Ephemeral Values

Objective 4h questions tend to arrive in one of these shapes:

• “Which argument prevents a variable’s value from being stored in state?” ephemeral = true. Not sensitive = true, which only redacts output.
• “A resource argument references ephemeral.random_password.db.result and plan fails. Why?” Ephemeral values can only be used in ephemeral contexts; a normal resource argument is not one. Use the resource’s write-only argument instead.
• “The password rotated in the secret store but the database password did not change.” Increment the _wo_version companion. Terraform cannot diff write-only values.
• “Which block reads a secret from Vault without persisting it?” An ephemeral block, not a data block.
• “Can the root module declare ephemeral = true on an output?” No. Only child modules.
• “Which Terraform version introduced ephemeral resources, and which introduced write-only arguments?” 1.10 and 1.11 respectively. Expect distractors that swap them.
• “How does Terraform treat an ephemeral resource between plan and apply?” It is opened again during apply; nothing is carried in the plan file.
• “Which value lets a provider configuration behave differently during apply?” terraform.applying.

The free Terraform Associate practice questions include sensitive-data scenarios in this style, and the practice exam page lets you try a sample under exam conditions. For a timed, objective-weighted rehearsal that covers the 004 additions (ephemeral values, custom conditions, depends_on and lifecycle rules, HCP Terraform projects) alongside the rest of the blueprint, the HashiCorp Terraform Associate (004) Mock Exam Bundle is built around the current objectives, including the Terraform 1.12 behaviours described here.

Practical Guidance and Gotchas

• Check the provider version, not only the Terraform version. Write-only arguments and ephemeral resources need provider support. The AWS provider added password_wo to aws_db_instance and the ephemeral aws_secretsmanager_secret_version in its 5.x line; an older pinned provider will simply not have the argument. Your provider version constraints matter here.
• Expect (write-only attribute) in the plan. The plan renders write-only arguments with a placeholder rather than a value or a diff, which is correct behaviour, not a bug.
• Keep the version companion in version control. password_wo_version is the only record that a rotation happened. Treat bumping it as the deliberate, reviewed act it is.
• Do not use random_password ephemerally without capturing the result. It regenerates on every operation. If you need the same password on the next run, store it write-only in a secrets manager and read it back ephemerally, as in the pattern above.
• Provisioners can consume ephemeral values but cannot emit them. Terraform 1.11 fixed the error message for “ephemeral values included in provisioner output”; the point is that a provisioner’s stdout is not an ephemeral context.
• Ephemeral does not mean invisible. An ephemeral value can still be printed by a provisioner’s echo, logged by a provider in TF_LOG=TRACE, or exposed by a misconfigured CI runner. Ephemerality protects plan and state files; it is not a substitute for careful debugging hygiene.
• Migrate existing secrets deliberately. Switching an existing password argument to password_wo is a change to the resource schema the provider must support, and the old value remains in historical state snapshots until those are purged. Rotate the secret after the migration.

Conclusion

Ephemeral values fix the oldest complaint about Terraform secrets handling by changing the language rather than the storage. sensitive still means hidden from the terminal; ephemeral means never written to the plan or state file, and Terraform enforces it by restricting where the value can flow. Ephemeral resources (1.10) bring secrets in through an open, renew, close lifecycle that is re-run in every phase; write-only arguments (1.11) send secrets out to a provider without a stored copy, with a _wo_version companion standing in for the diff Terraform can no longer compute. Ephemeral variables and child-module outputs carry those values between the two, and terraform.applying plus ephemeralasnull handle the edge cases.

For the Terraform Associate (004) exam, remember the seven ephemeral contexts, the root-module output restriction, the version numbers (1.10 and 1.11), the fact that a write-only value is never diffed, and the hard line between sensitive and ephemeral. Combine the two for real credentials, keep Vault or a cloud secrets manager as the source of truth, and the state file stops being the weakest link in your secrets story.

Frequently Asked Questions

What is the difference between sensitive and ephemeral in Terraform?

sensitive = true redacts a value in CLI output but Terraform still stores it in state and plan files, and terraform output -json prints it in plain text. ephemeral = true (Terraform 1.10 and later) keeps the value out of plan and state files entirely by restricting the value to contexts that are never persisted. The two are independent and are commonly combined on the same variable.

Where can an ephemeral value be used in Terraform?

In seven contexts: a write-only resource argument, another ephemeral block, a locals block, a variable block with ephemeral = true, a child-module output with ephemeral = true, a provider configuration block, and a provisioner or provisioner connection block. Using an ephemeral value anywhere else, including a normal resource argument, a data source argument or a root-module output, is a plan-time error.

What is an ephemeral resource in Terraform?

An ephemeral block, available in Terraform 1.10 and later, that behaves like a resource or data source in the dependency graph but is never stored in state or plan files. It has an open, renew, close lifecycle: Terraform opens it when a dependent needs the value, asks the provider to renew it if it would expire mid-operation, and closes it once the dependent providers finish. It is re-opened in each phase, so the plan file carries nothing across to apply.

What are write-only arguments in Terraform?

Resource arguments, available in Terraform 1.11 and later and marked by the provider (usually with a _wo suffix such as password_wo), whose values Terraform sends to the provider during an operation and then discards. They accept ephemeral or ordinary values and are recorded as null in state. Because Terraform cannot diff them, each has a companion version argument such as password_wo_version that you increment to make the provider re-send the value.

Why did my write-only password not update after I changed the secret?

Terraform has no stored copy of a write-only value, so it cannot detect that the value changed and produces no diff. Increment the companion _wo_version argument; that attribute is stored and planned normally, and changing it tells the provider to apply the current write-only value.

Can a root module output be ephemeral?

No. The documentation states that you cannot add the ephemeral argument to output blocks in the root module, because root outputs are stored in state for terraform output and remote state consumers. Only child-module outputs can be ephemeral, and they can only be referenced from other ephemeral contexts. Use ephemeralasnull() if you need to expose the non-secret parts of a mixed value from the root module.

Do ephemeral values work with saved plan files?

Yes, with one adjustment. Because the plan file omits ephemeral input variable values, you must supply them again when running terraform apply against a saved plan, using -var, -var-file or TF_VAR_ environment variables. Ephemeral resources are simply opened again during apply.

Which Terraform versions introduced ephemeral values and write-only arguments?

Ephemeral resources, ephemeral input variables and outputs, terraform.applying and ephemeralasnull() arrived in Terraform 1.10. Write-only arguments arrived in Terraform 1.11. The Terraform Associate (004) exam tests on Terraform 1.12, so both are in scope.