CKS Cluster Hardening 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.

• ✓

  Pod Security Admission: Enforces pod security standards at admission time

  Why this is correct

  Pod Security Admission is a native admission controller that intercepts pod creation requests and validates them against the Pod Security Standards (privileged, baseline, restricted). It can be configured per namespace with enforce, audit, or warn modes, and it rejects non-compliant pods before they are persisted in etcd. As an admission-time control, it directly inspects the pod's SecurityContext, capabilities, and host namespaces.

• ✓

  Network Policies: Controls traffic flow between pods and namespaces

  Why this is correct

  Network Policies are cluster-scoped (via namespaces) objects that define granular ingress and egress rules at the IP and port level using selectors and CIDR blocks. They function only if the underlying CNI plugin (such as Calico, Cilium, or Weave) implements them, acting as a distributed firewall for pod-to-pod and pod-to-external traffic. They do not inspect pod security contexts; they only filter network packets based on labels, ports, and IPs.

• ✓

  RBAC: Regulates access to Kubernetes API resources

  Why this is correct

  RBAC (Role-Based Access Control) is the authorization mechanism governing which identities—human users, Kubernetes users, or ServiceAccounts—can perform specific verbs (e.g., get, list, watch, create) on Kubernetes API resources, such as Pods, Secrets, and Deployments. It relies on Role and ClusterRole objects bound to subjects via RoleBinding or ClusterRoleBinding, making it a pure control-plane security layer. It is orthogonal to network traffic and admission validation, focusing exclusively on API access.

• ✓

  kube-bench: Checks Kubernetes clusters against CIS benchmarks

  Why this is correct

  kube-bench is an externally run security scanner that evaluates a Kubernetes cluster's configuration against the CIS Kubernetes Benchmark, a published set of security best practices. It executes a series of automated checks via a pod or binary, covering areas like etcd TLS settings, kubelet authentication, API server flags, and file permissions on sensitive files. This tool provides a detailed pass/fail/warn report that helps operators identify insecure hardening gaps.

• ✗

  Pod Security Admission: Controls network traffic between pods

  Why it's wrong here

  This statement is factually wrong because Pod Security Admission has no data-plane role; it is entirely an admission-time gate on the API server. PSA only inspects the pod spec for security context compliance before creation and issues an admission response—allow or deny—based on the Pod Security Standards. Network traffic between pods is controlled by Network Policies, which are enforced by the CNI plugin after pods are running, so this option confuses admission-time policy with runtime traffic filtering.

• ✗

  Network Policies: Enforces pod security standards

  Why it's wrong here

  Network Policies do not enforce pod security standards; they only govern which workloads can communicate over the network by matching selectors, ports, and IP blocks. They cannot evaluate or enforce security contexts such as privileged containers, hostPID, or allowed capabilities—those are validated by Pod Security Admission at pod creation time. This answer is wrong because it attributes a control-plane admission responsibility to a data-plane traffic filter, mixing two distinct layers of Kubernetes security.

Go deeper

Related to this question