Exercise 3: What a Resource Hierarchy Is For, and Azure's Resource Group Gap — Possible Solution
====================================================================

What a resource organization hierarchy is for:

As an organization's cloud usage grows, it accumulates large numbers
of individual resources (VMs, storage buckets, databases, networks)
that need to be grouped, billed, and access-controlled sensibly rather
than existing as one flat, unorganized pile. A resource hierarchy
provides nested CONTAINERS for organizing resources -- typically by
team, project, environment (dev/staging/production), or billing unit
-- so permissions, budgets, and policies can be applied at the right
level of granularity rather than resource by resource. This is also
directly what answers "where do I even look for this resource" during
troubleshooting -- knowing the hierarchy tells you where to start
searching, not just what the resource is called once found.

Why Azure's Resource Group specifically has no clean 1:1 equivalent:

Per the chapter, AWS's hierarchy is Organizations -> Accounts, and
GCP's is Organizations -> Folders -> Projects -- in both cases, the
top-level containers (AWS Accounts, GCP Projects) tend to function as
fairly heavyweight, semi-permanent boundaries, often tied closely to
billing and broad access separation.

Azure's Resource Group sits at a DIFFERENT level of granularity: it's
a lightweight container specifically for grouping resources that share
a common LIFECYCLE -- for example, every resource belonging to one
specific application deployment, so the whole group can be managed or
deleted together as a unit. Neither an AWS Account nor a GCP Project is
really designed to be created and torn down that casually or that
often at that fine a grain -- they're closer in spirit to Azure's
higher-level Subscription, one level up from Resource Group. Because
AWS and GCP don't have an equivalent "disposable, lifecycle-scoped
grouping" concept at that same intermediate layer, Azure's Resource
Group doesn't map cleanly onto either provider's hierarchy -- it's not
that the concept of "grouping resources" is unique to Azure, it's that
the SPECIFIC LEVEL and LIFECYCLE SCOPE Azure groups resources at
doesn't have a matching container in the other two hierarchies.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly explains the practical "where do I look for this
resource" consequence the chapter names, and grounds WHY the Resource
Group specifically resists a clean mapping -- it's a lifecycle-scoped
container at a granularity the other two providers' hierarchies simply
don't have a matching layer for, rather than an arbitrary naming
difference like most of the chapter's own terminology table.