Exercise 1: Splitting a Shared "Backend" Account — Possible Solution
====================================================================

Three separate accounts, each scoped to what that specific service
actually does:

CREATE USER 'web_app'@'%' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'web_app'@'%';
-- the web application creates, reads, updates, and deletes records
-- as part of normal user-facing operation, so it genuinely needs all
-- four.

CREATE USER 'job_processor'@'%' IDENTIFIED BY '...';
GRANT SELECT, UPDATE ON shop.job_queue TO 'job_processor'@'%';
-- a background job processor typically only reads pending jobs from
-- a queue table and updates their status (e.g. pending -> completed)
-- — it has no legitimate reason to touch every table in the database,
-- and no reason at all to INSERT or DELETE most data.

CREATE USER 'nightly_reporting'@'%' IDENTIFIED BY '...';
GRANT SELECT ON shop.* TO 'nightly_reporting'@'%';
-- a reporting script only ever reads data to produce a report; it
-- never needs to write anything at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each account's grants map directly to what that specific service does,
not to what "the backend" as a vague whole might ever need. If the
reporting script's credentials ever leaked, the worst outcome is data
being READ that it already had legitimate access to — it could never
write, update, or delete anything, unlike under the original single
shared account where a leak of any one credential would have exposed
full read/write access to everything.