CKS Sample Questions With Full Explanations
Here are 8 multiple-choice questions designed to match the difficulty, style, and multi-domain coverage of the Certified Kubernetes Security Specialist (CKS) exam. These questions focus on the decision-making and troubleshooting aspects required of a security engineer, rather than simple recall.
Instructions: For each question, select the single best answer. The scenarios are based on realistic cluster configurations and security incidents you might encounter in the CKS environment. See also CISA Sample Questions With Full Explanations for a complementary perspective.
Question 1
You are auditing a cluster for compliance. You find that the kube-apiserver is running with the flag --authorization-mode=AlwaysAllow. Which of the following is the most immediate and critical security risk?
A. Unauthenticated users can access the API server.
B. Any authenticated user can perform any action, including administrative tasks.
C. The API server is vulnerable to denial-of-service attacks via resource exhaustion.
D. Service account tokens are not being rotated automatically.
Answer: B
Explanation: --authorization-mode=AlwaysAllow bypasses all authorization checks, meaning any authenticated user (or compromised service account) has full cluster-admin privileges. While A is a risk, authentication is still enforced by default (e.g., certificates, tokens). C is a general operational risk, and D is an unrelated security feature.
Question 2
A developer reports that their pod cannot start. The pod is scheduled to a node with a taint dedicated=gpu:NoSchedule. You check the pod spec and find it has tolerations defined. However, the pod is still stuck in Pending. Which of the following is the most likely reason?
A. The toleration key does not match the taint key on the node.
B. The pod does not have a nodeSelector for the GPU node.
C. The toleration has the wrong effect (e.g., NoExecute instead of NoSchedule).
D. The pod is using a privileged security context.
Answer: A
Explanation: For a toleration to work, it must match the taint's key, value (if specified), and effect. If the key is wrong, the toleration is ignored, and the pod remains unscheduled. B is incorrect because a toleration alone is sufficient to schedule onto a tainted node; a nodeSelector is not required. C is plausible, but a mismatched key is a more common root cause. D is a security issue but does not affect scheduling against taints.
Question 3
You are implementing a network policy to isolate a frontend namespace. You want to allow ingress traffic to the web pods only from the api pods in the backend namespace. Which NetworkPolicy ingress rule correctly achieves this?
A. from: - podSelector: matchLabels: app: api (no namespaceSelector)
B. from: - namespaceSelector: matchLabels: name: backend
C. from: - namespaceSelector: matchLabels: name: backend and podSelector: matchLabels: app: api
D. from: - ipBlock: cidr: 0.0.0.0/0 For more on this topic, see our guide on Cisco CyberOps Associate Sample Questions With Full Explanations.
Answer: C
Explanation: To select pods from a specific namespace, you must combine a namespaceSelector (to target the namespace) and a podSelector (to target the pods within it). Option A only selects pods in the same namespace as the policy. Option B allows all pods from the backend namespace, which is broader than required. Option D is a permissive allow-all rule.
Question 4
You are performing a forensic investigation. You need to capture the command-line arguments of a running container to check for secrets passed at runtime. Which command provides the most direct and reliable information?
A. kubectl logs
B. kubectl describe pod
C. crictl inspect
D. kubectl exec
Answer: C
Explanation: crictl (the CRI-compatible CLI) can inspect the container's configuration directly from the container runtime (containerd), including the args and env from the original spec. kubectl describe shows the pod spec but may not reflect the actual runtime state if the container was started differently. kubectl logs shows output, not arguments. kubectl exec runs a process inside the container, which may not show the original process's arguments.
Question 5
You need to rotate the CA certificate for your cluster. After generating a new CA and restarting the control plane components, you find that nodes can no longer join the cluster. What is the most likely missing step?
A. You forgot to update the kubelet configuration file on the control plane.
B. You did not update the kubeconfig files for the nodes to use the new CA.
C. You did not restart the etcd cluster after the CA rotation.
D. You did not update the service-account-private-key-file flag on the API server.
Answer: B
Explanation: When rotating the cluster CA, all clients (including kubelets on worker nodes and kubectl users) must trust the new CA. The kubeconfig files contain the certificate-authority-data which must be updated to point to the new CA. A is incorrect; the kubelet config is on the nodes, not the control plane. C is incorrect; etcd does not need to be restarted for CA rotation (though it uses its own certificates). D is relevant for service account token signing, not node authentication.
Question 6
You are hardening a container image. You want to ensure that the container process cannot write to its own filesystem, but it needs to write to an emptyDir volume. Which securityContext setting is the most appropriate?
A. readOnlyRootFilesystem: true
B. allowPrivilegeEscalation: false This connects to what we discuss in CompTIA A+ Core 2 Sample Questions With Full Explanations.
C. capabilities: drop: ["ALL"]
D. runAsNonRoot: true
Answer: A
Explanation: readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing writes to the image layers. Writes to mounted volumes (like emptyDir) are still permitted. B prevents privilege escalation but does not restrict filesystem writes. C drops capabilities but does not prevent writes to the root filesystem. D ensures the process runs as a non-root user but does not restrict the filesystem.
Question 7
You have deployed an admission controller (e.g., OPA/Gatekeeper) to enforce security policies. You need to test a new policy that will deny pods with privileged: true. You deploy a test pod that is privileged. It is created successfully, and the policy is not enforced. Which of the following is the most likely cause?
A. The admission controller is not enabled in the API server's --enable-admission-plugins flag.
B. The policy is in audit mode and not in enforce mode.
C. The pod was created in a namespace that is excluded from the policy.
D. All of the above are equally plausible.
Answer: D
Explanation: All three are common reasons why a policy might not be enforced. The admission controller must be enabled (A), the policy must be set to deny rather than audit (B), and the policy might have a namespaceSelector that excludes the test namespace (C). In a real-world scenario, you must check all of these.
Question 8
You are using kube-bench to scan a node for CIS benchmark compliance. The report shows a failure for the check "1.2.6 Ensure that the --authorization-mode flag is not set to AlwaysAllow". You have already fixed the API server. However, the scan still fails. What is the most likely reason?
A. You need to run kube-bench with the --targets node flag.
B. The kube-bench configuration file is pointing to the wrong version of the CIS benchmark.
C. You need to restart the kubelet service for the changes to take effect.
D. The API server pod was recreated with the old flags from the static manifest.
Answer: D
Explanation: In a kubeadm-based cluster, the API server is a static pod. If you edit the manifest file (/etc/kubernetes/manifests/kube-apiserver.yaml), the kubelet will automatically restart the pod. However, if you edited the running pod's YAML via kubectl edit (which is not possible for static pods) or made a temporary change, the pod will revert to the manifest's flags. The most common mistake is editing the live pod spec instead of the static manifest file. A is incorrect because the check is for the control plane, not the node. B is possible but less likely than a configuration revert. C is incorrect; the kubelet does not control the API server's flags.
As you plan your CKS preparation around troubleshooting misconfigurations like this one, a free CKS study plan can give you a schedule that fits your available study hours.
These questions illustrate the need to understand not just what a security tool does, but why it fails in practice. The CKS exam heavily tests your ability to troubleshoot and identify the root cause of misconfigurations, often involving a chain of events (e.g., static manifests, admission controllers, and network policies).
To spot weak areas before your exam, use the free CKS readiness check for a handful of practice questions with explanations.
See how your preparation compares to the passing standard on Certified Kubernetes Security Specialist (CKS) mock exam.