Exercise 2: Alerting on a Blocked Anomalous Action — Possible Solution
====================================================================

This event is still worth alerting on immediately, even though the
DELETE should fail, because a FAILED attempt is exactly as strong a
signal of something wrong as a successful one — arguably a clearer
one, since a legitimate, correctly-behaving reporting job should NEVER
attempt a write statement at all, successful or not.

Two realistic explanations for why this happened, both worth
investigating urgently:

1. THE ACCOUNT'S CREDENTIALS HAVE BEEN COMPROMISED, and whoever is now
   using them is testing what they can do — probing for a
   misconfiguration, or simply unaware this particular account has
   been scoped to read-only. Chapter 3's least-privilege design is
   precisely what causes the attempt to fail here — but "the attempt
   failed" and "there was no attempted attack" are not the same thing;
   catching it now, while it's still contained, is far better than
   only noticing after some other, more successful action later.

2. THE APPLICATION CODE ITSELF HAS A BUG that's attempting a write it
   was never supposed to make — a real defect worth fixing regardless
   of whether it represents an active attack, since it indicates the
   application's own logic doesn't match its intended read-only role.

Either way, treating this as "no real harm done, since the privilege
system caught it" misses the point of anomaly detection: the goal is
noticing a deviation from expected, normal behavior AS EARLY AS
POSSIBLE — ideally before a misconfiguration or a genuinely successful
compromise causes real damage, not only after something actually
succeeds.