Exercise 1: Denied Despite a Correct-Looking Policy and No Explicit Deny — Possible Solution
====================================================================

What to check next: PERMISSION BOUNDARIES or ORGANIZATION-WIDE
POLICIES (SCPs on AWS, Azure Policy, GCP Organization Policies) --
the layer this chapter specifically identifies as sitting ABOVE and
INDEPENDENT of any individual identity's own IAM policies.

Reasoning through the debugging order:

The scenario states the user's own policy appears to grant full
access, and no explicit deny was found across their attached policies
-- meaning steps 1-4 of this chapter's debugging order (confirm
identity, gather all policies, check for explicit deny, check
resource/condition scoping) have all effectively been checked and
ruled out as the cause. Per the chapter, the ONLY remaining layer in
the debugging order that hasn't yet been checked is step 5: an
org-level or boundary policy.

This matches the chapter's own explicit description of exactly this
situation: "even a user with a policy explicitly granting full
administrator access can still be blocked by an org-level
restriction... a real, common source of confusing tickets where 'the
policy looks completely correct' and access is still denied -- the
missing piece being invisible at the identity level entirely." The
scenario in this exercise is precisely that described case.

WHY THIS WORKS AS AN ANSWER
------------------------------
This works through the chapter's own five-step debugging order,
showing that the scenario as described has already exhausted the first
four identity-level checks, which leaves only the org-level/boundary
layer as the remaining, correct answer -- rather than guessing at the
answer directly, it's derived by process of elimination through the
chapter's own stated sequence.