CKS Monitoring, Logging and Runtime Security Practice Question
What is the purpose of setting a container's filesystem to read-only in a Pod spec?
⚠ Common exam trap
Candidates often mistake the read-only filesystem as a performance or sharing feature, but it is strictly a security control to prevent post-compromise tampering. This is a key concept in the CKS domain of Runtime Security.
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
✓
To prevent an attacker from modifying the container's filesystem after compromise
Setting a container's filesystem to read-only in a Pod spec (via `securityContext.readOnlyRootFilesystem: true`) ensures that the container's root filesystem cannot be written to at runtime. This is a critical runtime security hardening measure because even if an attacker gains code execution inside the container (e.g., through a web application vulnerability), they cannot modify binaries, configuration files, or scripts on the filesystem, severely limiting their ability to persist, escalate privileges, or tamper with the application. This aligns with the principle of immutable infrastructure and is a key control in the CKS domain of Runtime Security.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
To prevent an attacker from modifying the container's filesystem after compromise
Why this is correct
Setting a container's filesystem to read-only enforces a runtime security boundary: even if an attacker gains code execution inside the container, they cannot write to the root filesystem, modify existing binaries, or plant persistent payloads. This aligns with immutable infrastructure principles and limits the blast radius of a compromise, though ephemeral writable locations like tmpfs volumes can still be used if needed.
- ✗
To allow multiple pods to share the same filesystem
Why it's wrong here
Read-only root filesystem has nothing to do with sharing data between pods; cross-pod sharing is achieved by mounting the same PersistentVolume, ConfigMap, or other volume into multiple containers. A read-only rootfs only prevents writes to the container's own image layers, whereas shared volumes are explicitly mounted and can be read-write regardless of the root filesystem mode.
- ✗
To prevent the container from being deleted
Why it's wrong here
A read-only filesystem does not affect pod lifecycle or deletion behavior; the kubelet and container runtime remove pods based on API server requests, eviction, or node pressure, independent of filesystem permissions. The container's rootfs being read-only only prevents in-container processes from modifying files, not the orchestrator from terminating or deleting the container or its pod.
- ✗
To improve disk I/O performance
Why it's wrong here
Reducing write activity on a read-only filesystem could marginally decrease storage write amplification, but that is not the stated purpose and any such I/O side effect is incidental. The primary motivation for making a container root filesystem read-only is security—specifically, to make it harder for attackers to alter the container's runtime environment—not to optimize disk throughput.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 114 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A pod has securityContext.readOnlyRootFilesystem: true. What happens if a process inside the container tries to write to the root filesystem?
medium- A.The write will succeed because tmpfs is used
- ✓ B.The write will fail with an error
- C.The kernel will allow the write but log it
- D.The pod will be restarted
Why B: 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.
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.