Reading Existing Resources with Data Sources

Welcome back. In this lesson we’ll explore Terraform data sources — read-only lookups that let your configuration query existing infrastructure instead of creating it. Data sources make Terraform configurations more flexible and safer by dynamically retrieving values (IDs, ARNs, CIDRs, endpoints, etc.) from cloud providers or other platforms and exposing those attributes for use in resources, variables, and outputs. By the end of this article you’ll understand what data sources are, how they work, and how to use them across common providers (AWS, Azure, Kubernetes, VMware) to avoid hard-coded values and enable dependable dependency resolution.

What is a data source?

A data source is a Terraform block that queries provider APIs to return attributes of an existing resource. Unlike resource blocks, data blocks do not create or modify infrastructure — they only read and expose information. Common uses:

Look up an existing VPC by tag or name to obtain its ID and CIDR.
Query an Azure Kubernetes Service (AKS) cluster and expose its resource ID or kubeconfig.
Retrieve VMware datacenter, datastore, or cluster information for VM provisioning.
Read managed or external resources that your deployment must reference.

Example: mixing resource creation with a data lookup

resource "azurerm_resource_group" "prd" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "dv" {
  name                = "example-network"
  resource_group_name = azurerm_resource_group.prd.name
  location            = azurerm_resource_group.prd.location
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_mssql_database" "db1" {
  name      = "example-db"
  server_id = azurerm_mssql_server.server.id
  collation = "SQL_Latin1_General_CP1_CI_AS"
}

data "azurerm_kubernetes_cluster" "aks" {
  name                = "prod-cluster"
  resource_group_name = "prod-group"
}

Note: The data block above is read-only; Terraform will not create or modify the AKS cluster when you run plan or apply.

When data sources are useful

Hybrid and multi-environment setups where some resources already exist.
Environments managed outside Terraform (cloud console, other teams).
Dynamic resource creation that depends on attributes of existing resources (IDs, subnets, endpoints).
Preventing configuration drift and fragile hard-coded identifiers.

Situation	Why use a data source
Referencing an existing VPC by name	Returns the VPC ID and CIDR so subnets can be created dynamically
Deploying VMs into a specific VMware cluster	Query the datacenter/cluster and pass attributes to VM resources
Reusing a shared resource (e.g., database)	Avoid duplicating definitions; lookup the resource and reference attributes
Cross-team or multi-account resources	Read attributes from another account/tenant without managing the resource

Example: Azure, VMware, and AWS scenarios

Azure: Look up an AKS cluster that already exists so you can deploy workloads or configure RBAC without recreating the cluster.
VMware: Query the correct datacenter, cluster, or datastore to target VM provisioning dynamically across environments.
AWS: Look up an existing VPC (by tag or name) to obtain vpc_id and cidr_block when creating subnets.

Networks and IP addressing are especially important. For example, when creating subnets in AWS you must provide the VPC ID. If you only know the VPC name, a data source can resolve the correct ID and CIDR block and prevent hard-coding.

A purple-themed architecture diagram showing a Terraform configuration that looks up an existing VPC and defines three subnet resources. On the right is an AWS Cloud illustration of the VPC with three availability zones, each containing a subnet.

Example: find the VPC and create subnets using values from the data source

data "aws_vpc" "prd" {
  filter {
    name   = "tag:Name"
    values = ["prd-vpc"]
  }
}

resource "aws_subnet" "pub" {
  vpc_id     = data.aws_vpc.prd.id
  cidr_block = "10.0.6.0/24"
  # ...
}

output "prd_vpc_cidr" {
  value = data.aws_vpc.prd.cidr_block
}

This pattern avoids hard-coding the VPC ID or CIDR and ensures the plan/apply phases use live values returned by the provider API.

Why use data sources?

Read-only: they never create or modify resources.
Enable implicit dependency resolution when a new resource relies on an existing one.
Reduce hard-coded values (IDs, ARNs, CIDRs), lowering error-proneness and drift.
A single data source can be referenced multiple times across a configuration.

Data sources are read-only lookups that allow Terraform to discover existing infrastructure and use those attributes in resource creation or outputs.

Data source syntax and examples

Every data source starts with the data keyword, followed by two labels and a block body:

First label: provider resource type (for example, aws_vpc, azurerm_resource_group, kubernetes_namespace).
Second label: a local identifier you choose to reference the lookup elsewhere.
Body: arguments or filters supported by the provider for that data source (these vary per provider).

Examples:

data "aws_vpc" "prd" {
  filter {
    name   = "tag:Name"
    values = ["prd-vpc"]
  }
}

data "azurerm_resource_group" "dev" {
  name = "dev-resource-group"
}

data "kubernetes_namespace" "app" {
  metadata {
    name = "customer-app"
  }
}

These blocks instruct Terraform to query the provider API and populate attributes that you can reference.

Referencing attributes

Use the pattern: data.<type>.<name>.<attribute> Examples for data.aws_vpc.prd:

ARN: data.aws_vpc.prd.arn
CIDR block: data.aws_vpc.prd.cidr_block
ID (VPC ID): data.aws_vpc.prd.id
Owner ID: data.aws_vpc.prd.owner_id

A data source can return many attributes. Check the provider documentation for the exact list. Representative JSON-style output from data.aws_vpc.prd:

{
  "arn": "arn:aws:ec2:us-west-2:123456789012:vpc/vpc-0abcd1234efgh5678",
  "cidr_block": "10.0.0.0/16",
  "default": false,
  "dhcp_options_id": "dopt-0abcdef1234567890",
  "enable_dns_hostnames": true,
  "enable_dns_support": true,
  "id": "vpc-0abcd1234efgh5678",
  "instance_tenancy": "default",
  "ipv6_association_id": null,
  "ipv6_cidr_block": null,
  "main_route_table_id": "rtb-0abcdef1234567890",
  "owner_id": "123456789012",
  "tags": {
    "Name": "prd-vpc"
  }
}

Use data.aws_vpc.prd.id inside a subnet resource to reference the VPC ID, or output data.aws_vpc.prd.cidr_block to expose the VPC CIDR.

Best practices and tips

Use clear, concise data source labels (e.g., prd, dev, shared_vpc) to make intent obvious.
Prefer filters or exact identifiers so the data source returns a single resource when required.
Reuse a single data source across your configuration rather than repeating lookups.
Consult the provider’s documentation for supported arguments and returned attributes.
When matching by tag or name, be explicit to avoid ambiguous results that return multiple resources.

Table: quick checklist

Item	Recommendation
Naming	Use meaningful local names like `prd`, `shared_vpc`, `primary_cluster`
Filters	Use tag filters or exact names to return one resource
Reuse	Reference the same `data` block from multiple resources instead of duplicating lookups
Docs	Follow the provider documentation for supported attributes and behavior

Wrap-up

Data sources let Terraform read and reference existing infrastructure so your configurations remain dynamic, maintainable, and less error-prone. Use data sources to fetch existing resources and reference their attributes when creating new resources, wiring outputs, or enabling cross-team reuse. Further reading and references:

Terraform documentation: https://www.terraform.io/docs
AWS VPC data source docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/vpc
AzureRM data sources: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources
Kubernetes provider data sources: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/data-sources

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Reading Existing Resources with Data Sources

What is a data source?

When data sources are useful

Example: Azure, VMware, and AWS scenarios

Why use data sources?

Data source syntax and examples

Referencing attributes

Best practices and tips

Wrap-up

Watch Video

​What is a data source?

​When data sources are useful

​Example: Azure, VMware, and AWS scenarios

​Why use data sources?

​Data source syntax and examples

​Referencing attributes

​Best practices and tips

​Wrap-up

Watch Video

What is a data source?

When data sources are useful

Example: Azure, VMware, and AWS scenarios

Why use data sources?

Data source syntax and examples

Referencing attributes

Best practices and tips

Wrap-up