Exercise 3: Does a Stateless REST API Need a PersistentVolume? — Possible Solution
====================================================================

Recommendation: No, they should not configure a PersistentVolume for
these pods.

Justification, using this chapter's "when to actually use persistent
storage" material directly:

The chapter states plainly: "stateless applications -- most web and
API servers -- generally don't need persistent volumes at all. They
should store state in an external database or object store... rather
than local pod storage." The scenario described matches this exactly
-- a REST API that "doesn't store any of its own data locally" and
instead "reads and writes to an external managed database" is, by
definition, already following the pattern the chapter recommends: all
actual state lives in the external database (a `cloud1-4`-style
managed storage service, existing entirely independently of any given
pod), not on the pod's own local filesystem at all.

Since there is no local data on the pod that needs to survive pod
replacement in the first place, there's nothing for a PersistentVolume
to actually protect here. Adding one would introduce real, unnecessary
complexity (managing a PVC, a StorageClass, access modes) to solve a
problem this specific application doesn't have -- directly echoing
this course's own recurring "don't add complexity to solve a problem
you don't actually have" theme (the same reasoning `k8s1-1`'s "when
you don't need Kubernetes" section used for a different decision).

Per the chapter, persistent volumes are genuinely needed for "stateful
workloads specifically -- databases, message queues with local state"
-- categories this REST API explicitly is NOT, since its own
statelessness (and reliance on an external database) is exactly the
architecture that avoids needing one.

WHY THIS WORKS AS AN ANSWER
------------------------------
This maps the scenario's own stated details (stateless, no local data,
external managed database) directly onto the chapter's explicit
"stateless apps generally don't need persistent volumes" guidance,
and names the specific unnecessary complexity a PersistentVolume would
add here, rather than defaulting to "more durability is always better"
without weighing the actual trade-off the chapter itself raises.