Challenge 2: Explain the Value of Read-Only — Possible Solution
====================================================================

A --read-only container specifically prevents an attacker who has
already successfully exploited a vulnerability in the running
application from WRITING anything to the container's own filesystem
at all, except to explicitly mounted writable paths (like a tmpfs
mount for /tmp).

Concretely, this means an attacker who has gained code execution
inside the application still CANNOT: modify the application's own
source files or binaries to inject persistent malicious code that
would survive a container restart, write a new malicious script or
tool to disk to expand their foothold, or tamper with configuration
files sitting in the image itself. Read-only doesn't stop the initial
exploit from happening — the vulnerability that let the attacker in is
still there — but it removes an entire CLASS of follow-on actions an
attacker would otherwise be able to take once inside, specifically the
ones requiring a write to the filesystem.

This is precisely what makes it "defense in depth" rather than a fix:
it doesn't prevent compromise, but it meaningfully narrows what a
successful compromise can actually accomplish, limiting the practical
damage even when the underlying vulnerability itself remains
unpatched or unknown.