CKS System Hardening Practice Question
Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes? (Select three.)
⚠ Common exam trap
CNCF often tests the misconception that privileged containers are acceptable for debugging in production, but the CKS exam emphasizes that privileged mode should never be used in production environments because it disables all security controls and grants host-level capabilities.
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
✓
Use read-only root filesystems for containers where possible
Using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use read-only root filesystems for containers where possible
Why this is correct
Setting the container's root filesystem to read-only via securityContext or readOnlyRootFilesystem forces any write to use ephemeral volumes like emptyDir or a writable tmpfs, so malware cannot persist by modifying binaries, configuration, or libraries. It also prevents container processes from dropping malicious files onto the underlying image layers, significantly limiting post-exploitation activity. Where a container genuinely needs temporary writes, mount a dedicated emptyDir volume rather than loosening the root filesystem.
- ✗
Allow privileged containers for debugging
Why it's wrong here
Granting privileged: true in a Pod's securityContext lifts every capability restriction and disables most isolation mechanisms, giving the container raw access to the host's devices, /dev, and the ability to mount host filesystems. Debugging rarely requires this level of access; instead use kubectl debug with ephemeral debug containers, or add only specific capabilities such as SYS_PTRACE via capabilities: add. A privileged container that is compromised is effectively equivalent to host root and can easily escape the sandbox.
- ✓
Disable unnecessary system services on nodes
Why this is correct
Every unnecessary service running on a Kubernetes node listens on a port, opens sockets, or exposes RPC endpoints that an attacker who compromises a pod or network segment might probe. Reducing the node's service footprint—disabling things like sshd, metrics agents, cron, or unused DNS services—shrinks the local attack surface and limits lateral movement. Harden the node by running only kubelet, the container runtime, and the system components required for node functionality.
- ✗
Run containers as root to simplify management
Why it's wrong here
When a container runs as root, the process UID 0 inside the container corresponds to kernel UID 0, so any kernel exploit, misconfigured volume mount, or pod escape directly translates to root privileges on the host. Container-specific root is unnecessary for most workloads and conflicts with the principle of least privilege. Set securityContext with runAsNonRoot: true and a specific runAsUser, for example 1000, ensuring the application runs with unprivileged UID.
- ✓
Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)
Why this is correct
hostPID shares the host's process table, hostNetwork binds the container directly to the host network stack, and hostIPC exposes host IPC resources, each breaking the isolation boundary between containers and the node. These settings let a container see other workloads' processes, forge network packets, or read shared memory, enabling privilege escalation or data leaks. Only use these host namespaces for special infrastructure pods; for normal workloads keep the default sandboxed namespaces.
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.