CKS Practice Question: A security auditor runs kube-bench and reports…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Container runtime will not be able to pull images

  Why it's wrong here

  Image pulling is executed by the container runtime (containerd, CRI-O, etc.) through the kubelet's image service, which handles registry authentication and layer downloads independently of the --protect-kernel-defaults flag. This kubelet flag exclusively governs whether kernel tunables (sysctls) are validated and protected, and its absence has no effect on the code paths that fetch images. Thus, omitting the flag cannot disrupt image pulling; it only disables enforcement of recommended kernel security settings.

• ✗

  The node will be unable to schedule pods

  Why it's wrong here

  Pod scheduling is performed by the kube-scheduler based on node taints, tolerations, resource capacity, and the node's readiness as reported by the kubelet's status updates. The absence of --protect-kernel-defaults does not alter kubelet's liveness or readiness, nor does it change the node object's schedulable state, so the scheduler will continue to place pods on the node. This flag affects only kernel-default enforcement, which is a separate concern from the scheduling pipeline.

• ✗

  The kubelet will refuse to start

  Why it's wrong here

  Missing --protect-kernel-defaults does not cause kubelet to refuse to start because the flag defaults to false; kubelet launches normally and simply skips verification of kernel parameter values. If the flag were explicitly set to true and the node's kernel tunables did not match kubelet's expected secure defaults, then kubelet would terminate at startup—but that is a different scenario. Here, the flag's absence lowers security but does not affect kubelet's process lifecycle or ability to boot.

• ✓

  Kernel parameters may be modified, potentially reducing node security

  Why this is correct

  Without --protect-kernel-defaults, kubelet does not verify that kernel parameters such as kernel.panic, vm.overcommit_memory, or net.ipv4.ip_forward match the secure values required by the CIS Kubernetes Benchmark, nor does it prevent containers from applying unsafe sysctls that can alter node-wide kernel behavior. A pod could thus modify kernel settings (e.g., enabling IP forwarding, changing shared-memory limits, or altering panic behavior), weakening node isolation and potentially facilitating container escapes or lateral network movement. Setting the flag to true forces kubelet to enforce these defaults or refuse to start, preserving node security.

Go deeper

Related to this question