Exercise 2: The Specific Real Mistake Behind the 2023 Leak — Possible Solution
====================================================================

The real cause was not simply that a token "leaked" in some generic
sense -- it was a specific SCOPING misconfiguration in how the token
was originally created. The SAS token was intended to share a
specific, public open-source AI training dataset. Instead of scoping
the token's own permissions narrowly to just those specific intended
files, it was configured to grant "full control" permissions over the
ENTIRE storage account -- meaning anyone with the token could read,
and potentially modify, every other file in that account, including
38TB of completely unrelated, genuinely private data that was never
meant to be shared at all.

Two further real, compounding mistakes made this worse: the token was
set to expire in 2051, effectively never expiring in any practical
sense, and there was no built-in Azure monitoring in place to detect
either the token's own creation or its ongoing use -- meaning the
overscoped, long-lived token could sit exposed indefinitely with no
automated way to catch it.

ANSWER: The specific real mistake was granting the SAS token
account-wide "full control" permissions instead of scoping it
narrowly to the specific dataset files it was meant to share -- not
merely "a token leaked," but a token that was far too broadly
permissioned in the first place, combined with an effectively
permanent expiration date and no monitoring to catch the
misconfiguration before it was exploited.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the real, specific configuration error
(scope, not just secrecy) rather than treating the incident as a
generic "credential leak," and names all three real compounding
factors (overscoped permissions, near-permanent expiration, no
monitoring) the chapter itself documents, rather than stopping at
just one.