Exercise 3: A Broad Allow vs. a Narrow Explicit Deny — Possible Solution
====================================================================

What happens: the user is DENIED access to that specific resource,
despite the broad policy that would otherwise grant it.

Why: per the chapter's own warn-box, "policies aren't purely
additive... if any attached policy contains an explicit deny for an
action, that deny overrides an allow granted anywhere else, even a
broad allow from a separate policy." This holds true across all three
major providers.

Working through this specific scenario:

- The FIRST policy grants broad access to the service -- on its own,
  this would allow the user to access every resource within that
  service, including the specific one in question.

- The SECOND, separate policy explicitly denies access to just that
  one specific resource.

- When the two policies are evaluated together, the explicit deny in
  the second policy takes precedence over the allow in the first,
  specifically for that one resource -- the user retains their broad
  access to everything ELSE the first policy covers, but is blocked
  from the one resource the second policy explicitly denies.

This is NOT a case of the two policies "canceling out" or the system
picking whichever policy was created first or most recently -- the
rule is specifically that an explicit deny always wins, regardless of
how broad or narrow the competing allow is, or which policy was
attached first.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is a direct, worked application of the chapter's own stated rule
to the exact scenario the exercise describes -- explicitly showing
that the outcome (denied for that one resource, allowed elsewhere) is
a predictable, deterministic consequence of "explicit deny always
wins," not an ambiguous or policy-order-dependent result, which is
exactly the kind of real troubleshooting trap the chapter's warn-box
describes support engineers running into in practice.