A city batch Job must read shared CSV files from a PVC while several worker Pods run at once. Writers elsewhere already finished the data. Which consume-side access mode should the Job’s PVC request?
Select an answer to reveal the explanation.
Short Explanation
Picture a shared binder of finished CSVs on a library cart—everyone can flip through, nobody needs a pen. ReadOnlyMany lets many Job Pods mount that finished data for reads without fighting over writers. Exclusive write modes are the wrong gear for a read-only consume pattern.
Full Explanation
A city batch Job that must read shared CSV files from a PVC while several worker Pods run at once—after writers elsewhere finished the data—should request ReadOnlyMany (ROX) on the consume-side PVC when the storage provider supports it. ROX allows multiple Pods to mount the volume concurrently for reads, matching parallel municipal batch readers without granting write races.
ReadWriteOnce limits attach to a single node and is oriented toward exclusive writers, which fights multi-Pod read parallelism across nodes. ReadWriteMany would allow concurrent overwrites the stem does not need and may be unavailable. Leaving accessModes empty is invalid for a PVC you author—the API expects modes.
Exam caveat: Access modes are necessary but not sufficient; the StorageClass/provider must implement ROX/RWX. Many cloud disks are RWO only—then colocate readers on one node or copy data to object storage.
Operational check: kubectl get pvc -o yaml | grep accessModes; schedule multiple Job Pods; confirm all mount successfully; attempt a write and confirm read-only enforcement if the mount is readOnly. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.