CKAD Practice Question: Application Environment, Configuration and Security
What is the effect of setting 'readOnlyRootFilesystem: true' in a container's securityContext?
⚠ Common exam trap
Test-takers frequently confuse 'readOnlyRootFilesystem' with making all volumes read-only, or assume the container is terminated on write attempts, when in reality only the root filesystem is affected and writes fail with an error, not silently.
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 container's root filesystem is mounted as read-only.
Setting `readOnlyRootFilesystem: true` in a container's securityContext mounts the container's root filesystem as read-only. This prevents any process inside the container from writing to the root filesystem, enhancing security by reducing the attack surface and ensuring immutability of the container image layers. It does not affect writable volumes mounted at other paths, such as emptyDir or hostPath volumes.
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 container can only read from the root filesystem, but can still write to /tmp.
Why it's wrong here
This statement is incorrect because it assumes /tmp remains writable by default. If no volume is mounted at /tmp, /tmp is simply a directory inside the container's root filesystem, so enabling readonlyRootFilesystem makes /tmp read-only as well. To have a writable /tmp, you must explicitly mount a volume (e.g., emptyDir) at that path, which bypasses the root filesystem's read-only restriction.
- ✓
The container's root filesystem is mounted as read-only.
Why this is correct
This is the correct behavior: setting readonlyRootFilesystem to true in the pod's securityContext causes the container's root filesystem to be mounted with the read-only flag. As a result, all write operations to any file or directory within the container's image filesystem (including the upper layer) will fail with a read-only file system error. This is a common security hardening measure to prevent runtime tampering of the container's filesystem.
- ✗
The container cannot write to any mounted volumes.
Why it's wrong here
This statement is wrong because the readonlyRootFilesystem setting only affects the container's root filesystem, not volumes mounted into the container. Volumes such as emptyDir, hostPath, or persistentVolumeClaims retain their own mount options; unless a volume is specifically mounted as read-only (e.g., readOnly: true in the volumeMounts), the container can freely write to those mounted paths. Therefore, write access to mounted volumes is independent of the root filesystem's read-only status.
- ✗
The container will be killed if it attempts to write to the root filesystem.
Why it's wrong here
This statement is incorrect because a write attempt to a read-only filesystem does not trigger a container kill. The kernel denies the write at the system call level and returns an EROFS error, causing the application's write operation to fail. The container continues running unless the application itself terminates due to unhandled errors. The container runtime does not send SIGKILL or any termination signal as a direct result of the failed write.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.