1.2.2. Multi-Cloud, Hybrid, and Service-Agnostic Workflows
💡 First Principle: Because Terraform talks to every platform through interchangeable provider plugins rather than hard-coded cloud logic, the workflow you learn (write, plan, apply) stays identical whether you target AWS, Azure, on-prem VMware, or a SaaS API — the only thing that changes is which provider you load.
A multi-cloud deployment spreads infrastructure across more than one cloud (perhaps for resilience or to avoid vendor lock-in). A hybrid cloud mixes public cloud with on-premises infrastructure. Service-agnostic means Terraform isn't limited to clouds at all — there are providers for DNS, monitoring tools, databases, GitHub, and hundreds of other services.
The unifying idea is that Terraform provides a single workflow and a single language (HCL) across all of them. You don't learn a new tool for each platform; you load a different provider. This is also why a multi-cloud configuration can reference resources from two clouds in one file and let Terraform orchestrate dependencies between them.
⚠️ Exam Trap: A common distractor implies Terraform "locks you into one cloud" or "requires a different tool per provider." The opposite is true — provider-agnosticism is one of Terraform's headline selling points. Remember also that the exam itself is provider-neutral: you won't be tested on AWS-specific resource names.
Reflection Question: What single architectural feature of Terraform makes the same workflow apply to AWS, a DNS service, and an on-prem hypervisor alike?
