Exercise 3: The Shared Admin Login Problem — Possible Solution
====================================================================

EVERYTHING WRONG WITH THIS SETUP:

1. NO ACCOUNTABILITY. Every query any of the five developers ever ran
   shows up in any log as simply "admin" — there is no way to
   determine, after the fact, which specific person ran a given
   query. This directly breaks Chapter 7's auditing goal: an audit
   trail that can't identify WHO did something provides essentially no
   real accountability at all, regardless of how much logging is
   turned on.

2. REVOKING ACCESS IS IMPOSSIBLE WITHOUT BREAKING EVERYONE ELSE. When
   the one developer leaves the company, there is no way to remove
   JUST their access — the only lever available is changing the shared
   admin password, which immediately locks out the other four
   developers too, forcing an awkward, disruptive password
   redistribution to everyone who still legitimately needs access.
   With individual accounts, the departing developer's single account
   would simply be disabled, with zero effect on anyone else.

3. THE DEPARTED DEVELOPER MAY STILL EFFECTIVELY HAVE ACCESS. If the
   password isn't rotated immediately (a common real-world failure,
   especially since rotating it disrupts four other people), the
   former employee retains full admin access to production data
   indefinitely, with no log entry that would ever distinguish their
   use of it from anyone else's.

4. BLAST RADIUS OF A LEAK. If the shared password is ever exposed —
   written down, reused elsewhere, phished from any one of the five —
   the entire production database is compromised, not just one
   person's slice of access.

THE FIX: each developer gets their own individual database account,
scoped to only the privileges their role actually requires (Chapter
3), so revoking one person's access is a single, isolated action, and
every action in the audit log (Chapter 7) can be attributed to a real,
specific person.