A city database PVC uses access mode ReadWriteOnce. Two application Pods on different nodes both try to mount it read-write. What should the admin expect?
Select an answer to reveal the explanation.
Short Explanation
RWO is a single-workshop rule: one node gets the writable mount. Two Pods on different nodes fighting for the same disk usually lose—the volume won’t attach everywhere like a shared network share. If you need many nodes writing, that’s RWX territory (and a backend that supports it).
Full Explanation
A city database PVC using access mode ReadWriteOnce generally allows a single-node writer mount. If two application Pods on different nodes both try to mount it read-write, the volume typically fails to attach or mount on the second node—RWO is not a cluster-wide shared writable disk. Multiple Pods on the same node may share that mount, but multi-node simultaneous RWO mounts are the usual failure mode municipal DB teams hit when they scale replicas naively.
ReadWriteOnce does not guarantee every node can mount read-write concurrently. It does not automatically convert to ReadWriteMany when a second Pod schedules. It does not only restrict Ingress controllers—access modes govern volume mounts, not Ingress.
Exam caveat: ReadWriteOncePod is a stricter single-Pod mode in newer APIs; do not confuse it with classic RWO. For multi-node writers you need RWX and a backend that supports it (NFS, certain file CSI drivers), not wishful RWO.
Operational check: attempt two Pods on different nodes mounting the same RWO PVC, observe attach/mount errors, then either colocate on one node, use a single-writer Deployment strategy, or move to an RWX-capable class. 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.