CKS System Hardening Practice Question
You are a platform engineer for a financial services company. Your Kubernetes cluster runs on bare-metal nodes with Ubuntu 20.04 and uses containerd as the container runtime. The cluster is in production with 50 worker nodes. A recent security scan shows that all nodes have the 'overlayfs' kernel module loaded, which is not required. The security policy requires minimal kernel modules. You need to disable the module without disrupting running containers. What should you do?
⚠ Common exam trap
CNCF often tests the misconception that unloading a kernel module with 'rmmod' or 'modprobe -r' is safe while containers are running, but in reality, overlayfs is actively used by the container runtime and cannot be removed without causing filesystem errors or container crashes.
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
✓
Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining
It permanently disables the overlayfs kernel module by adding it to the modprobe blacklist and updating the initramfs, ensuring the module is not loaded on subsequent boots. Draining and rebooting nodes one by one avoids disrupting running containers, as pods are rescheduled to other nodes before the node is taken offline. This approach aligns with the security policy of minimizing kernel modules while maintaining production uptime.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Restart containerd on each node to unload the module
Why it's wrong here
Restarting containerd does not unload a kernel module; overlayfs remains resident in the kernel because it is still referenced by active superblocks and mount namespaces even if the daemon is briefly stopped. The restart would kill all containers on the node, causing an outage, yet the module would simply be reinitialized when containerd starts again and creates new overlay mounts. This approach neither permanently disables the module nor addresses the root cause.
- ✓
Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining
Why this is correct
Adding 'blacklist overlayfs' to /etc/modprobe.d/ prevents the kernel's module autoload mechanism from loading the module during normal boot, but because overlayfs is often pulled in by the initramfs or as a dependency of another module, 'update-initramfs -u' is required to rebuild the initial RAM disk without it. Draining each node before reboot ensures that all pods are gracefully rescheduled to other nodes, so the reboot itself does not interrupt workloads. This is the only persistent and non-disruptive method to disable the module across reboots.
- ✗
Use 'rmmod overlayfs' after stopping all containers
Why it's wrong here
Stopping all containers (or the entire runtime) to run 'rmmod overlayfs' is a massive disruption in a production cluster, and it still does not provide a persistent solution. The kernel module will be automatically reloaded by udev or containerd on the next container start, because no blacklist rule is added. Additionally, 'rmmod' will fail if any overlay mounts still exist, making the manual removal unreliable and potentially leaving the system in an inconsistent state.
- ✗
Use 'modprobe -r overlayfs' on each node immediately
Why it's wrong here
Running 'modprobe -r overlayfs' immediately on each node is dangerous because the module is currently in use by containerd's overlay mounts; the kernel will return 'Module is in use' and refuse removal, or if forced with '--force', it would cause I/O errors, container crashes, and potential data corruption. Even if the removal succeeded, the module would be reloaded at the next boot or next containerd start since no blacklist entry is added. This approach causes immediate disruption without achieving the desired permanent disabling.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 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 →
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.