CKS Monitoring, Logging and Runtime Security Practice Question
You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?
⚠ Common exam trap
The exam often tests the misconception that a read-only root filesystem prevents all writes, but candidates may overlook the need for an explicit writable volume mount like emptyDir for directories such as /tmp that applications expect to be writable.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The pod is missing an emptyDir volume mounted at `/tmp`
When `securityContext.readOnlyRootFilesystem: true` is set, the container's root filesystem becomes read-only. Many applications, including those that write temporary files, expect to write to `/tmp`. Without a writable volume mounted at `/tmp`, the container fails to start because it cannot write to that directory. Mounting an `emptyDir` volume at `/tmp` provides a writable location that is ephemeral and tied to the pod's lifecycle, resolving the issue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The `securityContext` is misspelled
Why it's wrong here
Misspelling a field name in the Pod spec is a schema-level mistake that the Kubernetes API server would normally reject during resource creation or update, typically with a validation error like 'unknown field'. Even if the API server were configured to prune unknown fields (e.g., via Server-Side Apply), the securityContext would be silently dropped, meaning the intended read-only root filesystem would never be enabled. Neither outcome produces a runtime write failure inside the container; a misspelling would fail at admission time or simply have no effect, not cause the EROFS error observed.
- ✓
The pod is missing an emptyDir volume mounted at `/tmp`
Why this is correct
The correct fix is to create a dedicated emptyDir volume and mount it at /tmp. When readOnlyRootFilesystem is true, the container's root filesystem is mounted with the MS_RDONLY flag, so every write attempt to any path on that filesystem returns EROFS — regardless of permissions. An emptyDir volume provides a separate, writable filesystem (initially empty, typically backed by the node's disk or tmpfs) that can be mounted exactly where the application expects to write temporary data, allowing the container to work while preserving the immutability of the root filesystem.
- ✗
The container image does not have `/tmp` directory
Why it's wrong here
Whether the container image happens to include a /tmp directory is a red herring. When readOnlyRootFilesystem is enabled, the entire root filesystem is mounted read-only, including any existing /tmp directory; therefore, even if /tmp exists in the image, a write to it would still be rejected with a read-only file system error. The application needs a writable volume like an emptyDir mounted at /tmp, not simply a directory that already exists in the image. In fact, the image's filesystem layout is irrelevant to the mount-read-only behavior.
- ✗
The container is running as a non-root user
Why it's wrong here
The root filesystem's read-only status is enforced at the kernel mount layer, not through Unix user permissions. When readOnlyRootFilesystem is true, the vfsmount is marked MS_RDONLY, and the kernel rejects write operations on that mount for every UID, including root. Changing the container to run as a non-root user would not help because the failure is caused by the mount flag, not a lack of filesystem write permission for the current user; in fact, even a non-root user with full rwx permissions on a directory within the rootfs would still be unable to write when the mount is read-only.
Visual reference
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.