Terraform’s newer secret-handling features solve a long-standing infrastructure-as-code problem: some values are needed during an operation but should not be written into plan or state artifacts. Ephemeral values and write-only resource arguments create a path for temporary secrets to flow through Terraform without becoming durable Terraform data.
This topic is part of the current Terraform Associate 004 learning scope and fits naturally within the broader HashiCorp certification path. One important version distinction should be clear from the start: ephemeral resources and ephemeral variable/output behavior are available from Terraform 1.10, while managed-resource write-only arguments require Terraform 1.11 or later. They are related features, but they were not introduced as one Terraform 1.12 feature set.
Sensitive is not the same as ephemeral
Terraform’s sensitive marking reduces accidental disclosure in normal CLI and UI output, but sensitive values can still be stored in state. That means the state backend must still be protected with strong access controls, encryption, and careful sharing. Masking a secret from terminal output does not remove it from Terraform’s persistent data model.
Ephemeral values are different. Terraform intentionally omits them from plan and state files. The value exists only where Terraform allows it during the current operation. This makes ephemeral handling useful for short-lived tokens, generated passwords, provider credentials, or other data that should not survive the run.
The existing guide to managing Terraform secrets provides broader secret-management context. Ephemeral values do not replace a secrets manager; they change how a secret moves through Terraform so the secret manager can remain the durable system of record.
Ephemeral variables and outputs keep temporary data out of state
A Terraform variable can be declared with ephemeral = true when its value should not be persisted in state or plan artifacts. Child-module outputs can also be ephemeral so a temporary value can cross a module boundary without turning into a durable output.
This matters when modules need credentials or tokens that exist only for the run. Instead of marking a value merely sensitive and accepting that state will contain it, the module can declare that the value is ephemeral and restrict its use to contexts where Terraform permits ephemeral data.
The restriction is intentional. Terraform does not let an ephemeral value flow into arbitrary normal attributes because that would eventually require persisting it. Ephemeral values can be used in supported ephemeral contexts such as provider configuration, ephemeral blocks, write-only arguments, certain locals, and explicitly ephemeral module interfaces.
Ephemeral resources retrieve or generate temporary data
An ephemeral block represents a temporary interaction whose result should not be persisted. A provider can implement an ephemeral resource that obtains a short-lived credential, opens a temporary session, or generates a secret for immediate use. Terraform opens the ephemeral resource during the operation and discards its result afterward.
A common pattern is to generate a password with an ephemeral resource, then pass that password directly into a write-only argument on another managed resource. The password never needs to appear in Terraform state. Another pattern is to retrieve a temporary cloud credential and use it to configure a provider for the current operation.
Provider support matters. Terraform language support alone does not make every provider resource ephemeral. The provider must implement the appropriate ephemeral resource or write-only argument. Always check the provider schema and documentation before designing around the feature.
Write-only arguments are the sink for temporary resource values
A write-only argument is a managed-resource argument that accepts a value during the current operation but is not stored in the Terraform plan or state. Provider authors mark specific arguments as write-only, commonly for passwords, API tokens, or secret material that the remote API needs only when creating or updating the object.
This solves an important gap. An ephemeral password is useful only if the destination can accept it without forcing Terraform to persist it. A normal resource argument usually participates in planning and state. A write-only argument gives the provider the value long enough to call the remote API and then lets Terraform discard it.
Write-only arguments often use names such as password_wo. The naming convention is provider-specific, so do not assume that every password attribute has a write-only counterpart. Terraform 1.11+ is required, and the provider must expose the feature.
Version arguments let Terraform track change without storing the secret
Terraform normally detects drift and changes by comparing configuration with prior state. A write-only value is absent from state, so Terraform cannot compare the previous password to the new one. Providers often pair the write-only argument with a normal version field such as password_wo_version.
The version is not secret and can be stored in state. When the version changes, the provider knows it should use the supplied write-only value as a new secret. This separates change tracking from secret storage: Terraform remembers “version 2” without remembering the password itself.
Teams should document this pattern because forgetting to increment the version can produce confusing behavior. The secret may be different in an external system or secret manager, yet Terraform has no durable value to compare. The non-secret version becomes the deliberate signal that a rotation is intended.
Ephemeral data still has exposure risks during the operation
Not persisting a secret in Terraform state is valuable, but it does not mean the value is magically immune from disclosure. The value can still exist in process memory, provider memory, environment variables, application logs, remote API logs, or shell history depending on how it is introduced and consumed.
Providers and external systems also determine whether the value is handled safely after Terraform passes it. A write-only Terraform argument prevents Terraform persistence; it cannot prevent the remote service from storing or logging the value according to that service’s design.
Operational controls therefore still matter: secure the runner, restrict debug logging, use short-lived credentials where possible, protect environment injection, and avoid printing secret values from local-exec or other scripts. Ephemeral Terraform semantics reduce one important risk surface, not every secret-management risk.
Provider support determines where the pattern can terminate
Terraform can mark a value ephemeral, but a practical secret flow still depends on provider features. If the target resource exposes only a normal persisted password argument, an ephemeral value cannot simply be forced into that argument. The provider schema must offer a compatible write-only argument or another ephemeral context that accepts the value.
This is why practitioners should inspect the provider documentation and Registry schema before designing a non-persistent secret workflow. Support can vary by resource and by provider version. One database resource may offer a write-only password while another service from the same provider still requires a normal argument.
Provider upgrades can therefore be part of a security improvement plan. Moving to a provider release that implements write-only arguments can remove a class of secrets from future state, but the team should still test the provider change, rotate any previously persisted secret, and review historical state according to its retention policy.
State security remains essential
Ephemeral features do not make Terraform state non-sensitive. State can still contain infrastructure identifiers, IP addresses, resource configuration, non-ephemeral credentials exposed by older providers, and outputs that were not designed correctly. Existing resources may also retain secrets in state even after a team adopts new ephemeral patterns.
Continue to use an appropriately secured remote backend, restrict state read/write permissions, encrypt data at rest and in transit, and audit who can access state. HCP Terraform protects state through its platform controls, while other backends have their own security model.
When migrating an existing configuration, remember that changing future handling does not automatically erase a secret from historical state versions. Secret rotation and state-history policy may be needed if the old value was previously persisted.
Design a source-to-sink secret path
A useful way to reason about ephemeral data is to map the full secret path. The source may be a secret manager, an ephemeral random value, a short-lived identity token, or an operator-provided ephemeral variable. The sink may be a provider configuration or a managed resource’s write-only argument.
Every step between source and sink must support ephemeral semantics. If an ephemeral value is assigned to a normal output or resource attribute, Terraform will reject the configuration or force a different design because that context requires persistence. This restriction helps practitioners discover where their configuration would otherwise leak a temporary secret into durable artifacts.
The dependency model in Terraform fundamentals still applies, but ephemeral data adds a second question: not only “what depends on this value?” but also “is every hop allowed to remain non-persistent?”
Use ephemeral features where non-persistence is genuinely required
Do not convert every variable to ephemeral simply because the feature is newer. Terraform needs durable values for planning and reconciliation, and many normal attributes should remain in state so drift detection works. Ephemeral handling is best for values whose security benefit from non-persistence outweighs the loss of normal state-based comparison.
Good candidates include short-lived authentication material, generated bootstrap secrets, temporary provider credentials, and passwords that a resource API accepts through a provider-supported write-only argument. Poor candidates include ordinary configuration values that Terraform needs to compare over time.
For Terraform Associate 004, the key distinction is conceptual: sensitive hides normal presentation but can still persist; ephemeral values are intentionally omitted from plan and state; write-only arguments let managed resources accept temporary values without persisting them. Understanding how those pieces connect is more useful than memorizing a single version number.