Exercise 1: Why Tenant-Wide Identity Simplifies Multi-Subscription Access — Possible Solution
====================================================================

Under AWS's own IAM model, an identity is scoped per account -- an
IAM user created in one AWS account only exists, and only has
meaning, within that specific account. Granting the same real person
access across three separate AWS accounts genuinely requires either
creating three separate IAM users (one per account) or setting up
cross-account role assumption for each one individually.

Entra ID's identity model works differently: an identity is scoped to
the TENANT, not to any single subscription. If all three subscriptions
belong to the same Entra ID tenant (a common real setup for a single
organization), one real user identity already exists at the tenant
level and can simply be granted a Contributor role assignment at each
of the three subscription scopes -- no new identity needs to be
created at all.

ANSWER: Because a single Entra ID identity can be referenced from
role assignments in multiple subscriptions under the same tenant, the
team can create the new employee's identity ONCE, then make three
separate Contributor role assignments (one per subscription) pointing
at that same identity -- rather than needing to create and manage
three genuinely separate identities the way AWS's per-account IAM
model would require.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly locates the real simplification in Entra ID's own
tenant-wide identity scope (one identity, multiple role assignments)
rather than in RBAC's scope hierarchy itself, and explicitly contrasts
it against what the equivalent AWS setup would actually require,
directly matching the chapter's own warn-box framing of this as a
genuine structural difference.