Exercise 2: Why CloudFormation Is a Poor Fit and Terraform Isn't, for a Multi-Cloud Team — Possible Solution
====================================================================

CloudFormation is an AWS-NATIVE tool -- per the chapter's comparison
table, its provider scope is "AWS only." It has no mechanism at all for
describing an Azure resource; its entire resource type catalog is
scoped to AWS's own services. A team using CloudFormation to manage AWS
infrastructure would need an entirely SEPARATE tool (ARM/Bicep, in
Azure's case) to manage the Azure side -- two different languages, two
different workflows, two different mental models, with no shared
concepts between them beyond "this is IaC."

Terraform's core value, as the chapter states directly, is expressing
infrastructure across providers using ONE consistent language and
workflow. Its provider model isn't tied to a single cloud -- AWS and
Azure resources can be declared in the same HCL language, planned and
applied through the identical `terraform plan`/`apply` workflow, even
referencing each other within the same configuration (e.g. an Azure DNS
record pointing at an AWS load balancer's address). The team gets one
tool, one syntax, and one review process (the `plan` step) regardless
of which cloud a given resource happens to live in.

The concrete reason CloudFormation fails this specific team's need: it
was never designed to describe anything outside AWS, so "consistent
workflow across AWS and Azure" is architecturally impossible with it.
Terraform was designed for exactly this cross-provider scenario from
the start.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific architectural limitation (CloudFormation's
resource catalog is AWS-only, not just "less popular" or "less
featured") that makes it structurally unable to meet a genuinely
cross-cloud requirement, and explains what Terraform's provider model
does differently to make the same requirement achievable.