Challenge 2: Design Least-Privilege Roles — Possible Solution
====================================================================

db.createUser({
  user: "shop_app",
  pwd: passwordPrompt(),
  roles: [ { role: "readWrite", db: "shop" } ]
})

db.createUser({
  user: "reporting_job",
  pwd: passwordPrompt(),
  roles: [ { role: "read", db: "shop" } ]
})

WHY THIS WORKS AS AN ANSWER
------------------------------
Both users are scoped to the SAME database (shop) — neither one gets
access to any other database on the server — but they get DIFFERENT
roles reflecting what each one actually needs to do:

shop_app genuinely needs to write data (new orders, updated
inventory, etc.) as part of normal application operation, so
readWrite is the correct, and correctly minimal, role — not root or
readWriteAnyDatabase, which would grant it access to every other
database on the server for no reason.

reporting_job, by its own description, ONLY ever reads from shop — it
never writes anything. Granting it readWrite anyway (a common shortcut
that "might as well cover everything") would mean that if the
reporting job's credentials were ever leaked or its code had a bug,
that leak could accidentally or maliciously WRITE to production data
it was never supposed to touch, purely because its role was broader
than its actual behavior needed.

This is the same principle the chapter's own overly-broad-role
comparison box made: a compromised credential can only do as much
damage as the role it was granted, so each user's role should map as
tightly as possible to what that specific user is actually meant to
do.