A library publishes static content that many reader Pods on different nodes should mount without write access. Which access mode fits?
Select an answer to reveal the explanation.
Short Explanation
Think of a reference book chained open in every branch—lots of readers, no red pens. ReadOnlyMany is that multi-node, read-only mount mode. RWO is the wrong shape for many nodes, and hoping fsGroup or omitting accessModes invents ROX is wishful.
Full Explanation
A library publishing static content that many reader Pods on different nodes should mount without write access fits ReadOnlyMany (ROX). ROX is the reference book chained open in every branch—lots of readers, no red pens. Multi-node read-only mounts distribute published assets without granting write concurrency.
ReadWriteOnce does not express multi-node read-only sharing just because traffic is read-only at the application layer. ReadWriteMany with fsGroup 0 does not disable all writes cluster-wide as a substitute for ROX. Setting volumeMode: Filesystem without accessModes does not default to RWX write semantics—you must declare accessModes appropriately.
Exam caveat: the PV/CSI backend must support ROX; some disks only offer RWO. Applications must still open files read-only; ROX prevents multi-node writers at the mount contract layer.
Operational check: create a PVC/PV with ReadOnlyMany, mount it in reader Pods across nodes, confirm reads succeed and writes fail as expected for the library content volume. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.