Challenge 1: Choose the Right Mount Type — Possible Solution
====================================================================

(a) A PostgreSQL database's data directory in production — NAMED
VOLUME. This is exactly the "persistent application data" case a named
volume is the recommended default for: it needs to survive container
restarts and redeployments, be portable independent of any one
specific host filesystem layout, and be manageable through Docker's
own tooling rather than tied to a bind-mounted host path.

(b) Source code during local development with live reload — BIND
MOUNT. This is the textbook bind-mount use case this chapter named
directly: mapping the actual host filesystem path where the developer
is editing files directly into the container, so changes made on the
host are immediately visible inside the running container without
rebuilding an image.

(c) A directory holding decrypted API credentials only for the
duration of one request — TMPFS. Credentials that exist only
transiently and should never be written to disk at all are exactly
what tmpfs is for — the data lives purely in memory and is
automatically gone the moment the container (or, more precisely, that
mount) stops existing, with no risk of a decrypted secret lingering on
disk somewhere it could later be discovered.