CKS Monitoring, Logging and Runtime Security Practice Question
You need to configure a Kubernetes Pod to have an immutable root filesystem. Which field should you set in the Pod spec?
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
✓
securityContext.readOnlyRootFilesystem: true
Setting `securityContext.readOnlyRootFilesystem: true` in the container's security context makes the container's root filesystem read-only, preventing the container from writing to its own filesystem unless explicitly allowed (e.g., via volume mounts). Option A (`spec.hostPID`) shares the host's PID namespace, not relevant. Option B (`allowPrivilegeEscalation`) controls whether a process can gain more privileges than its parent, not filesystem immutability. Option C (`runAsUser`) sets the user ID for the container, not filesystem permissions. Thus, only D achieves an immutable root filesystem.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
spec.hostPID: true
Why it's wrong here
spec.hostPID: true shares the host's PID namespace with the pod, exposing host processes to the container. While this is a serious security risk that can aid process visibility and potential breakout, it has no effect on how the container's root filesystem is mounted. Filesystem immutability is controlled by mount options and storage settings, not by process namespace sharing, so this option does not prevent writes.
- ✗
securityContext.allowPrivilegeEscalation: false
Why it's wrong here
securityContext.allowPrivilegeEscalation: false blocks a process from gaining more privileges than its parent process, such as through setuid binaries or capabilities. This is a privilege control that limits escalation but does nothing to alter the writability of the root filesystem. Even with this setting, a container running as root or with write permissions can still modify files on a mutable root filesystem, so it is unrelated to making the filesystem immutable.
- ✗
securityContext.runAsUser: 1000
Why it's wrong here
securityContext.runAsUser: 1000 changes the UID of the container's main process to 1000, a non-root user. Running as a non-root user reduces the privileges of the process and may prevent writes to root-owned directories if permissions are not granted, but the root filesystem itself remains writable. This is an identity-based security control, whereas filesystem immutability is a mount-level property that must be explicitly enforced with read-only mounting or storage restrictions.
- ✓
securityContext.readOnlyRootFilesystem: true
Why this is correct
securityContext.readOnlyRootFilesystem: true mounts the container's root filesystem with read-only permissions, so any process inside the container cannot write to the root filesystem at all. This directly enforces immutability of the core container filesystem, which is exactly what this question requires. Note that ephemeral volumes like emptyDir can still be mounted to provide writable directories, so the setting is compatible with workloads that need temporary storage.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 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.