Exercise 3: How Resource Groups Change the Default Organizational Experience — Possible Solution
====================================================================

In AWS, there is no single mandatory construct that every resource
must belong to for organizational purposes -- resources are commonly
organized loosely, through tags, VPC boundaries, or account
structure, all of which are OPTIONAL conventions a team chooses to
adopt (or not) rather than something the platform itself enforces.

In Azure, Resource Groups work differently: every single resource
belongs to exactly one Resource Group from the moment it is created,
with no way to create a resource outside of some group. This is a
genuine, structural requirement built into the platform itself, not
an optional convention teams may or may not follow consistently.

ANSWER: Azure Resource Groups change the default experience by making
grouping mandatory and automatic rather than optional and
convention-dependent -- every resource is guaranteed to belong to
some named group, whether or not anyone deliberately organized it
that way. One real, practical benefit this provides: because an
entire application's related resources (a VM, its storage, its
network interface) can be placed in one Resource Group, the whole
group can be deployed, monitored, and -- critically -- deleted
together as a single logical unit, without needing to separately hunt
down and remove each individual resource by hand once a project is
decommissioned.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the structural difference (mandatory,
platform-enforced grouping vs. optional, convention-based
organization) rather than just saying "Azure has resource groups and
AWS doesn't have an equivalent," and names a specific, concrete real
benefit (simplified group deletion/cleanup) rather than a vague
"better organization" claim.