Exercise 1: "I'm Logged In But Get Access Denied" — AuthN or AuthZ? — Possible Solution ==================================================================== This is an AUTHORIZATION problem, not an authentication problem. Per the chapter's own distinction, authentication is proving who you are (the login itself), and authorization is what an ALREADY-VERIFIED identity is actually permitted to do. The user in this scenario has already successfully completed authentication -- they explicitly say "I'm logged in fine" -- so the login/identity-verification step is not in question at all. The failure is happening at the NEXT step: the system has confirmed who they are, and is now refusing to let them perform a specific action, which is exactly what authorization governs. What should be checked next: 1. Which specific policy (or policies) are attached to this user's identity, and whether any of them explicitly allow the action they attempted, on the specific resource they attempted it against. 2. Whether the action requires a resource-level permission that's present in a general/broad grant but not scoped correctly for the exact resource involved (per the chapter's resource-level restrictions material). 3. Critically, per the chapter's own warn-box: whether a SEPARATE attached policy contains an EXPLICIT DENY for this specific action or resource -- since an explicit deny anywhere overrides an allow granted elsewhere, a broad-looking "should have access" policy can still be blocked by a narrower deny sitting in a different policy entirely. WHY THIS WORKS AS AN ANSWER ------------------------------ The user's own wording ("I'm logged in fine") is the direct signal that authentication already succeeded, which is exactly the triage distinction the chapter calls out as commonly confused by end users who describe both problems identically. The investigation steps follow the chapter's own troubleshooting pattern precisely, ending with the explicit-deny nuance the chapter flags as a common, real trap.