A records app should run with a read-only root filesystem but still needs a writable cache directory. What configuration satisfies both?

readOnlyRootFilesystem: true hardens a records app by making the container’s root filesystem immutable at runtime, which reduces tampering and unexpected writes. Applications still often need a writable cache or temp directory. The correct combination is to keep the root read-only and mount an explicit writable volume—typically emptyDir—at the cache path the process uses. That preserves the immutability goal while giving the municipal records service a sanctioned scratch pad for cache files that disappear with the Pod (unless you choose a different volume type for persistence).

privileged: true so the root can be remounted read-write defeats the hardening and expands host-level risk; it is not a legitimate way to “fix” read-only root. Writing cache files permanently into image layers is neither practical at runtime (the root is read-only) nor desirable for ephemeral cache data. ConfigMaps are for configuration key/value material with size limits; they are not a general-purpose writable filesystem substitute for application caches, and apps cannot treat ConfigMap keys as a POSIX cache directory.

Exam caveat: emptyDir is node-local and Pod-lifetime; do not confuse it with PersistentVolumeClaim if the records cache must survive rescheduling. Also ensure the mount path matches where the app actually writes. Operational check: set readOnlyRootFilesystem true, mount emptyDir at the cache path, confirm the Pod becomes Ready, and verify writes succeed under the cache mount while writes to other root paths fail. kubectl describe pod and the volumeMounts section should show the emptyDir; city reviewers should see both the hardening flag and the intentional writable exception.