CKS Practice Question: Arrange the steps to configure and use kube-bench…

Answer analysis

Option-by-option breakdown

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

• ✓

  Install kube-bench, then run kube-bench against the cluster, then review audit results, then apply remediation, then re-run kube-bench to verify.

  Why this is correct

  This is the correct order because kube-bench must be installed first, run against the cluster to generate results, then results are analyzed to identify failures, remediations are applied, and finally re-audited to ensure fixes are effective.

• ✗

  Run kube-bench against the cluster, then review audit results, then install kube-bench, then apply remediation, then re-run kube-bench to verify.

  Why it's wrong here

  This ordering is impossible because the kube-bench executable, its CIS benchmark configuration files, and its dependency on a working container or binary runtime must all be present on the host before an audit can execute. Running kube-bench against the cluster before installing it presupposes a tool that does not yet exist, and any hypothetical initial scan would produce no meaningful results. The correct sequence places installation first because kube-bench must be available to invoke before it can generate compliance data for the cluster.

• ✗

  Install kube-bench, then review audit results, then run kube-bench against the cluster, then apply remediation, then re-run kube-bench to verify.

  Why it's wrong here

  After merely installing kube-bench, no audit results have been produced, so reviewing nonexistent results is a logical and operational impossibility. Installation only places the binary and benchmark definitions on the system; it does not execute any checks against the kubelet, etcd, control-plane components, or host OS. You must run kube-bench to generate the report, and only then can you review output to identify failing controls, so this option misorders the dependency between the audit run and the review.

• ✗

  Install kube-bench, then run kube-bench against the cluster, then apply remediation, then review audit results, then re-run kube-bench to verify.

  Why it's wrong here

  Applying remediation immediately after running kube-bench, before reviewing the audit results, forces you to act without knowing which checks actually failed, which are warnings that require context, and which controls may already be compliant. This can lead to changing configuration files or service arguments unnecessarily, potentially breaking cluster components or introducing security regressions in areas that never had an issue. The review step is what triggers targeted remediation, so it must precede any changes to the cluster's hardened configuration.

Go deeper

Related to this question