A Terraform data source is a read-only configuration object that retrieves information from an external system or another Terraform context. It lets a module consume existing values, such as IDs, attributes, or computed results, without managing that object’s lifecycle. This is useful when infrastructure needs context rather than ownership.
Expanded Definition
A Terraform data source is read-only by design. It does not create or own infrastructure; instead, it retrieves existing facts from a provider, a remote system, or Terraform state so a configuration can make decisions with current context.
The boundary matters. A data source is for discovery, lookups, and computed values, while a resource is for managing lifecycle. That distinction is easy to miss when both appear in the same module, but it is central to how Terraform plans behave. If a value comes from a data source, Terraform treats it as an input to the graph, not as something it will provision, replace, or delete.
In practice, data sources often expose IDs, names, tags, network attributes, account details, or existing infrastructure references. They are common in modules that need to attach to pre-existing systems, query shared services, or adapt to environment-specific values without hardcoding them.
Examples and Use Cases
Terraform data sources typically show up in these situations:
- Looking up an existing VPC, subnet, AMI, DNS zone, or secret reference so a module can attach to current infrastructure.
- Reading a remote state output to connect one stack to another without duplicating ownership.
- Fetching provider-computed metadata, such as the current account, region, or caller identity, to parameterize a deployment.
- Resolving a named object from an external platform when the infrastructure team owns the object elsewhere.
- Pulling configuration context into a reusable module so the same code works across multiple environments.
A common implementation tradeoff is that lookups make modules more flexible, but they also make them more dependent on external state being stable and discoverable. If the queried object changes shape or disappears, the plan can fail even though the module code itself has not changed.
For practitioners, the useful mental model is “reference, do not manage.” If the module needs to own the object, a resource is usually the right abstraction. If it only needs to consume the object’s current attributes, a data source is the cleaner fit.
Security Implications
Security issues arise when a data source is assumed to be harmless simply because it is read-only. The lookup may still expose sensitive context, import an unsafe dependency, or silently bind a deployment to the wrong target. That can turn a harmless-looking reference into an access, integrity, or drift problem.
One failure mode is overtrust in external lookups. If a data source pulls the wrong subnet, key, account, certificate, or environment-specific value, the resulting infrastructure may be deployed into an unintended trust boundary. Another is leaking operational details through overly broad outputs, logs, or module interfaces.
OWASP API Security Top 10 is a useful companion when the data source is reading from APIs, because lookup integrity and authorization errors can produce the same class of broken trust decisions seen in API-driven systems.
When data sources are used for shared state or environment discovery, practitioners should watch for stale references, ambiguous naming, and undocumented dependencies. Those are often the earliest signals that a supposedly simple lookup is becoming an operational control point.
Security, Operational and Governance Implications
Terraform data sources matter because they shape what the plan believes is true. In a controlled environment, that is useful. In a poorly governed environment, it can create hidden coupling between modules, teams, and accounts, especially when the source of truth sits outside the Terraform configuration.
From a governance perspective, the key question is ownership. A data source can depend on objects that another team manages, but the consuming module still inherits the security quality of that dependency. If the external object changes without review, the downstream configuration may remain syntactically valid while becoming operationally unsafe.
The operational implication is that lookup hygiene becomes part of infrastructure quality. Clear naming, stable interfaces, constrained read permissions, and explicit documentation help keep data sources predictable. When the lookup surface grows too broad, misbinding and unintended exposure become much more likely.
NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because the control families around access control, audit, and configuration management map directly to how external lookups should be governed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Data sources depend on stable, governed configuration inputs and external references. |
| Recommendation — Document and harden lookup inputs so Terraform reads only approved configuration sources. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Data sources consume external system data, so access to queried systems must be controlled. |
| GV — Govern | Data sources create cross-team dependency and ownership questions for infrastructure inputs. | |
| ID.AM — Asset Management | Data sources reference existing assets, so the inventory must reflect what modules consume. | |
| Recommendation — Restrict read access to only the systems and attributes Terraform modules need. Assign ownership for external lookup sources and review their governance before reuse. Keep asset inventories accurate so Terraform lookups resolve to approved targets. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
