mediumMultiple Choice
CKS Practice Question: Configuring kubelet to protect kernel defaults
You are configuring kubelet to protect kernel defaults. Which flag enables this?
⚠ Common exam trap
It's easy for candidates to confuse Docker's `--security-opt` flags (which apply per-container) with kubelet's node-level hardening flags, or they invent plausible-sounding flag names like `--enable-protect-kernel` that do not exist in the kubelet reference.
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
✓
--protect-kernel-defaults
The `--protect-kernel-defaults` flag is a kubelet option that, when set to `true`, enforces kernel tunable protections by checking that sysctl settings like `vm.overcommit_memory`, `vm.panic_on_oom`, and `kernel.panic` match the kubelet's expected safe defaults. This is a critical hardening measure to prevent container breakout scenarios where a compromised pod could weaken host kernel parameters.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
--security-opt=protect-kernel
Why it's wrong here
The flag --security-opt=protect-kernel is a Docker daemon/container runtime flag used to add security labels to containers, not a kubelet flag. The kubelet does not parse --security-opt at all; kernel hardening for the node is controlled by the dedicated kubelet flag --protect-kernel-defaults. Attempting to pass this Docker-specific option to kubelet will result in an 'unknown flag' error and prevent the kubelet from starting.
- ✓
--protect-kernel-defaults
Why this is correct
The kubelet flag --protect-kernel-defaults, when set to true, enforces that the node's kernel parameters (such as vm.overcommit_memory and kernel.panic) are at their default secure values, and it refuses to start if these settings deviate. This flag also blocks pods from overriding unsafe sysctls, preventing kernel-level misconfigurations that could compromise the node. It is the only correct flag among the options for enabling this kind of kernel protection in a Kubernetes kubelet.
- ✗
--enable-protect-kernel
Why it's wrong here
--enable-protect-kernel is not a recognized kubelet flag; the kubelet's CLI and configuration schema only define a boolean flag named --protect-kernel-defaults. Kubelet flags do not use an 'enable' prefix for this feature, so supplying this variant would cause a fatal 'unknown flag' error during startup. The correct way to enable the protection is to set --protect-kernel-defaults=true (or via the protectKernelDefaults field in the kubelet configuration file).
- ✗
--kernel-security
Why it's wrong here
--kernel-security is a hypothetical flag that does not exist in the kubelet's flag list. Kubelet security is implemented via discrete options such as --protect-kernel-defaults, --read-only-port, and --anonymous-auth, but there is no catch-all 'kernel-security' switch. This option might be confused with SELinux or AppArmor profiles, which are configured at the container runtime level, not through a single kubelet flag.
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.