CKS Run kube-bench on a control plane node Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  kube-bench run --targets=controlplane

  Why it's wrong here

  kube-bench does not recognize the target name 'controlplane'. The CLI rejects it, so no checks execute and the command exits with an invalid target error. The CIS Kubernetes Benchmark groups all control plane components under the exact target 'master', so you must use that supported name to trigger any control plane audit.

• ✓

  kube-bench run --targets=master

  Why this is correct

  This is the correct invocation because 'master' is the kube-bench target that maps to the control plane section of the CIS Kubernetes Benchmark. Running with --targets=master audits kube-apiserver, kube-controller-manager, kube-scheduler, and etcd bundles on the control plane node. It ensures comprehensive coverage of control plane checks rather than a partial or empty run.

• ✗

  kube-bench run --targets=node

  Why it's wrong here

  The 'node' target runs only benchmarks for worker-node components such as kubelet and kube-proxy, which are not the focus of a control plane audit. On a control plane node, this skips the API server, controller-manager, and scheduler checks, leaving critical security settings unexamined. Even though a control plane node may run kubelet, the node target does not substitute for the master target.

• ✗

  kube-bench run --targets=etcd

  Why it's wrong here

  The 'etcd' target restricts kube-bench to the etcd-only checks in the CIS benchmark, but the control plane includes more than etcd. This command would not audit kube-apiserver, kube-scheduler, or kube-controller-manager, so a major portion of the control plane remains unchecked. Since the prompt asks for control plane checks, limiting the scan to etcd is insufficient and incorrect.

Go deeper

Related to this question