mediumMultiple Choice
CKS Practice Question: To protect kernel defaults on a node, which flag…
To protect kernel defaults on a node, which flag should be set on the kubelet?
⚠ Common exam trap
A common mix-up: candidates confuse the exact flag name with plausible-sounding alternatives like 'protect-kernel-parameters' or 'kernel-security', but the CKS exam expects precise recall of the actual kubelet flag `--protect-kernel-defaults=true` as defined in the CIS Benchmark.
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=true
The `--protect-kernel-defaults=true` flag on the kubelet ensures that the kubelet will not start if any kernel tunables (e.g., `vm.overcommit_memory`, `kernel.panic`) differ from their default values. This is a security hardening measure to prevent misconfigured nodes from running with weakened kernel settings, as required by the CIS Kubernetes Benchmark.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
--hardening=true
Why it's wrong here
The flag `--hardening=true` does not exist in the kubelet's command-line interface. Kubelet hardening is not enabled by a single generic boolean; instead, specific flags and configuration fields address individual concerns, such as `--protect-kernel-defaults` for sysctl protection and separate settings for seccomp or AppArmor. Passing an unrecognized flag like this will cause the kubelet to fail to start with an unknown flag error.
- ✓
--protect-kernel-defaults=true
Why this is correct
The `--protect-kernel-defaults=true` flag is the correct option, as it instructs the kubelet to verify that security-sensitive kernel parameters—such as `vm.overcommit_memory` and `kernel.panic`—are set to their expected default values and to avoid modifying them. When enabled, the kubelet is also unable to change these parameters, and it will refuse to start if the host kernel does not already match the required defaults, preventing accidental weakening of the kernel's security posture.
- ✗
--protect-kernel-parameters=true
Why it's wrong here
Although `--protect-kernel-parameters=true` sounds plausible, this exact flag is not recognized by the kubelet. The real flag targets kernel *defaults* specifically, not generic parameters, and the option name is `--protect-kernel-defaults`. An unknown flag name will be rejected during kubelet startup, so using this variant would not only fail to protect anything but also prevent the kubelet from running.
- ✗
--kernel-security=true
Why it's wrong here
`--kernel-security=true` is not a valid kubelet flag; the kubelet does not expose a catch-all 'kernel security' boolean. Kernel security in Kubernetes is achieved through a combination of mechanisms, including sysctl protection via `--protect-kernel-defaults`, AppArmor/SELinux profiles, seccomp filters, and `sysctl` allowlists in the kubelet configuration. This option is therefore a nonsensical distractor and would cause the kubelet to fail with an unrecognized flag error.
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.