Exercise 2: Create a Read-Only Reporting Account — Possible Solution
====================================================================

CREATE USER 'reporting_job'@'%' IDENTIFIED BY 'a-genuinely-strong-password';
GRANT SELECT ON shop.* TO 'reporting_job'@'%';

WHY THIS SHOULD BE A SEPARATE ACCOUNT
------------------------------
The main application's account needs SELECT, INSERT, UPDATE, and
DELETE — it has to actually create and modify data as part of normal
operation. A reporting job, by contrast, only ever READS data; it has
no legitimate reason to ever write anything.

If the reporting job reused the main application's account, it would
be running with far MORE privilege than it needs — the least-privilege
violation this chapter and Chapter 3 both flag. Concretely: if the
reporting job's code had a bug, or its credentials leaked, that
mistake or leak could now WRITE to production data, purely because its
account happened to be shared with something that genuinely needed
write access, not because the reporting job itself ever needed it.

A separate reporting_job account with only SELECT granted means the
worst a bug or leak in the reporting job could do is read data it
already had access to — it could never modify or delete anything,
regardless of what went wrong in that code path.