Data Sources and References — Terraform & Infrastructure as Code

Not all infrastructure is created by Terraform. Pre-existing resources — a VPC created manually, an AMI maintained by AWS, an SSL certificate managed by another team's configuration, a Route 53 zone that predates your IaC adoption — need to be referenced by new Terraform-managed resources without being imported into state. Data sources solve this: they query the cloud provider's API for existing resource attributes and make them available for use in resource configurations. This makes Terraform configurations self-describing and non-brittle: instead of hardcoding `ami-0c55b159cbfafe1f0` (an AMI ID that varies by region and becomes stale), you query the latest approved AMI dynamically. Instead of hardcoding a VPC ID, you query the VPC by its Name tag. Data sources are the mechanism that bridges Terraform-managed and pre-existing infrastructure.

Analogy🏏Cricket

🏏 Think of it like cricket: Before standardised cricket rulebooks existed, every ground played by its own local customs — different LBW interpretations, different wide-ball rules, inconsistent DRS protocols. A touring team playing in a new city had to learn an entirely different set of rules. The standardised ICC rulebook is IaC: a version-controlled document that specifies exactly how cricket is played anywhere in the world. When any ground host asks 'how should this match be set up?', they apply the rulebook — not their memory, not local tradition, not a wiki page from 2019. Every ground becomes reproducible because they're all applying the same version-controlled specification. The insight is that codifying rules enables consistency at scale — you can run a thousand simultaneous cricket matches and every one follows the same rules because they all reference the same canonical document.