Prioritise ephemeral handling when the value is only needed during the run and should not persist after apply. Data sources are useful when state persistence is acceptable, but credentials, passwords, and tokens that must not survive the execution window belong in ephemeral flows or outside Terraform entirely.
When Terraform values should stay ephemeral rather than land in a data source
Terraform data sources are a good fit when you want to read something durable and safe to re-read during later runs. Ephemeral handling is the better choice when the value only needs to exist for the current execution and should not be written into state, plans, logs, or downstream outputs. That distinction is mainly about blast radius, persistence, and whether the value can survive beyond apply.
In practice, the deciding question is not “can Terraform read it?” but “should Terraform be trusted to retain it?” Credentials, passwords, session tokens, and other short-lived secret material usually fail the persistence test. If the value is sensitive enough that later state access would be a problem, the design should avoid normal data-source flows and keep the secret in an ephemeral path or outside Terraform control altogether.
How to tell when a data source is the wrong abstraction
Data sources are built for discoverability and repeatability. They are ideal for metadata, IDs, remote object attributes, and other inputs that can be safely resolved again on a later run. They become the wrong abstraction when the value is itself the sensitive payload, or when the remote system exposes the secret only once and expects the caller to use it immediately.
This is especially important when a secret has operational meaning only inside the run window. If Terraform reads it through a normal data source, the value can become part of state handling or plan evaluation in ways that outlive the intended lifetime. For secrets that are meant to be consumed and discarded, the safer pattern is to keep the secret out of persistent Terraform data flow and feed it only to the component that needs it.
A useful rule is: if the value must remain recoverable after the run, a data source may be acceptable; if recovery would itself be a security failure, treat persistence as the problem to solve, not a convenience to accept.
What changes for secrets, tokens, and short-lived credentials
Secrets are different from ordinary configuration because their exposure is often more damaging than their absence. When the item in question is a password, API token, bearer token, signing key, or temporary credential, the main control objective is usually confinement, not retrievability. That makes ephemeral handling materially better than a data source whenever the secret is only needed to complete a single apply or provisioning step.
This is where rotation, expiry, and one-time delivery semantics matter. A temporary secret that is fetched, used, and discarded aligns with the original security intent. A secret that is resolved through a data source and then preserved in state creates a longer-lived secret path than the application or platform may actually require. If the value is intended to expire quickly, storing it in a reusable lookup mechanism works against that design.
For teams working in broader secrets workflows, NHIMG’s Secrets Management Guide is useful context for deciding when to centralize, rotate, or avoid persistence altogether. The same applies to Static vs Dynamic Secrets, which is the clearest model for deciding whether the credential should exist beyond the current execution.
Risk and Threat Considerations
When Terraform persists a secret that was only meant for transient use, the exposure window expands beyond the original operation. The risk is not just accidental disclosure during apply, but later retrieval through state access, backup copies, provider diagnostics, or troubleshooting workflows. That makes persistence itself part of the threat surface.
Failure mechanism: A short-lived credential or sensitive token is loaded through a durable Terraform path, then retained in state or related execution artifacts after the run ends.
Impact: Anyone with access to those artifacts may inherit a credential that was supposed to vanish, increasing the chance of unauthorized use, replay, or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Terraform state persistence can expose secrets beyond their intended run window. |
| NHI-07 — Long-Lived Secrets | The question is about avoiding persistence for secrets that should not survive apply. | |
| Recommendation — Keep transient secrets out of durable Terraform paths and state. Prefer short-lived or ephemeral secret delivery over stored credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The decision turns on how credentials and tokens are handled across their lifecycle. |
| AU-9 — Protection of Audit Information | State and execution artifacts can reveal sensitive values if not protected. | |
| Recommendation — Manage credential issuance, rotation, and disposal so secrets do not persist unnecessarily. Protect execution artifacts that could capture secrets during provisioning. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Persistent secret handling changes who can later access sensitive material. |
| Recommendation — Restrict access to any Terraform artifact that might retain sensitive values. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Credentials and tokens used in automation must not become reusable outside their intended scope. |
| Recommendation — Use short-lived credentials and avoid exposing reusable authentication material. | ||
Practitioner Guidance
What to prioritise: Decide first whether the secret must still exist after apply. If the answer is no, treat any solution that persists it as the higher-risk option, even if it is operationally convenient.
What to verify: Check the whole path, not just the module input. Confirm whether the secret can appear in plan output, state, logs, remote backends, CI artifacts, or debugging traces before you trust the design.
Decision rule: If the value is a credential, password, token, or signing material whose exposure would be material, keep it ephemeral or external to Terraform; if it is stable reference data that can be re-read safely, a data source is usually fine.
Practitioner takeaway: The right boundary is persistence, not convenience, so use data sources for durable lookups and ephemeral handling whenever the secret’s safe lifecycle ends with the run.
Related resources from NHI Mgmt Group
- Should security teams prioritise DLP over broader data visibility programs?
- When should teams prioritise log normalization over adding more sources?
- When should organisations prioritise data sources over variables or remote state in Terraform?
- When should teams prioritise data rights automation over manual request handling?