hardMultiple Choice
CKS Practice Question: After running kube-bench, you see a failing…
After running kube-bench, you see a failing check: '1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive'. What is the remediation?
⚠ Common exam trap
CNCF often tests the exact mapping between kube-bench check IDs and their corresponding file paths, so the trap here is confusing the API server pod spec file with other static pod manifests (like controller-manager) or configuration files (like kubelet config or audit logs).
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
✓
Change permissions of /etc/kubernetes/manifests/kube-apiserver.yaml to 600
Check 1.1.1 from kube-bench specifically targets the API server pod specification file, which is located at /etc/kubernetes/manifests/kube-apiserver.yaml. The remediation is to set its permissions to 600 or more restrictive to prevent unauthorized read or write access, as this file contains critical configuration parameters for the API server.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change permissions of /var/lib/kubelet/config.yaml to 600
Why it's wrong here
This is the kubelet's own configuration file, not the API server's static pod manifest. The failing check 1.1.1 specifically verifies the permissions of the API server pod definition file, so adjusting this kubelet config does not remediate the issue. Moreover, misapplying permissions here could disrupt kubelet behavior or prevent it from reading its own settings.
- ✗
Change permissions of /var/log/audit.log to 600
Why it's wrong here
This path holds the API server's audit log output, which is runtime data rather than the pod manifest that defines the API server's container. The check targets the integrity of the API server's static pod configuration file, not logs. Changing permissions on the audit log may be a fine hardening step but does not address the failing CIS check.
- ✓
Change permissions of /etc/kubernetes/manifests/kube-apiserver.yaml to 600
Why this is correct
This is the static pod manifest that kubelet reads to launch the API server. Restricting it to root:root and mode 600 prevents unprivileged users from tampering with the API server's arguments, such as disabling authentication or adding insecure flags. Since the check is explicitly about this file's permissions, setting 600 directly resolves the failure.
- ✗
Change permissions of /etc/kubernetes/manifests/kube-controller-manager.yaml to 600
Why it's wrong here
This path is the static pod manifest for the controller manager, which is a separate control plane component. Although it too is sensitive, the failing check 1.1.1 is specific to the API server manifest, so changing this file's permissions won't make the check pass. Each component has its own CIS check; addressing the wrong one leaves the original risk unmitigated.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.