CKS Monitoring, Logging and Runtime Security Practice Question
A pod has securityContext.readOnlyRootFilesystem: true. What happens if a process inside the container tries to write to the root filesystem?
⚠ Common exam trap
Candidates often think that `readOnlyRootFilesystem: true` only applies to certain directories or that Kubernetes will automatically restart the pod on failure, but in reality it is a kernel-enforced read-only mount that denies writes with an error and does not affect the pod lifecycle.
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 write will fail with an error
When `securityContext.readOnlyRootFilesystem: true` is set in a Pod spec, the container's root filesystem is mounted as read-only. Any attempt by a process inside the container to write to the root filesystem (e.g., creating a file in `/` or modifying `/etc/passwd`) will be denied by the kernel's VFS layer, and the write system call will return an error (typically `EROFS` or `EACCES`). This is enforced at the kernel level, not by Kubernetes itself.
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 write will succeed because tmpfs is used
Why it's wrong here
readOnlyRootFilesystem mounts the container's root as read-only; tmpfs is only used if the pod separately defines an emptyDir with medium Memory, which the stem does not. Assuming tmpfs is tempting because writable scratch space is common, but it must be configured explicitly.
- ✓
The write will fail with an error
Why this is correct
readOnlyRootFilesystem mounts the container's root filesystem read-only at the kernel level, so any write syscall to a path on it returns EROFS. The process receives an error rather than the write silently succeeding or the pod restarting.
- ✗
The kernel will allow the write but log it
Why it's wrong here
The read-only mount is enforced by the kernel, which rejects the write with an EROFS error rather than permitting and logging it. Auditing writes is tempting because Linux audit subsystems can log denials, but logging is not the default behaviour and the write does not succeed.
- ✗
The pod will be restarted
Why it's wrong here
A failed write returns an EROFS error to the process; the container is not restarted, and Kubernetes does not monitor filesystem write attempts. Restart behaviour is tempting because it is a familiar pod lifecycle response, but it is triggered by crashes or probe failures, not by a denied write to a read-only mount.
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.