Terraform Basics — Providers and Resources — Terraform & Infrastructure as Code

Terraform's power comes from its plugin architecture. Terraform Core is a thin engine that understands HCL syntax, manages state, computes diffs, and walks dependency graphs — but it has no built-in knowledge of AWS, GCP, Azure, or any other service. All cloud-specific knowledge lives in providers: plugins that Terraform downloads at init time and that implement the create/read/update/delete operations for specific services. The AWS provider knows how to call AWS EC2 APIs; the Kubernetes provider knows how to interact with the Kubernetes API server; the GitHub provider knows how to manage GitHub repositories. This architecture means Terraform can manage virtually any API-driven service — over 3,000 providers exist in the Terraform Registry. Resources are the fundamental building blocks declared in Terraform configurations — each resource corresponds to one infrastructure object managed by a provider.

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.