CKS Minimize Microservice Vulnerabilities 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.

• ✓

  Create a Gatekeeper Constraint that requires runAsNonRoot

  Why this is correct

  Gatekeeper is a validating admission controller that extends Kubernetes with policies written in OPA Rego. A ConstraintTemplate defines the validation logic (e.g., requiring `runAsNonRoot: true`), and a Constraint then applies that rule to objects such as Pods. Because it evaluates every resource at admission time, it can reject any Pod whose security context allows root—enforcing the policy before the Pod is persisted. This makes it a valid, flexible way to enforce non-root execution, going beyond the built-in PodSecurity profiles.

• ✗

  Use a NetworkPolicy to block root containers

  Why it's wrong here

  A NetworkPolicy is a Kubernetes resource that controls traffic at the IP address and port level (L3/L4) by defining ingress and egress rules with selectors. It has no mechanism to inspect container image metadata, security contexts, or runtime user IDs. Even if a container runs as root, NetworkPolicy would allow it to communicate normally unless explicitly blocked by IP rules—but that would only block traffic, not change how the container executes. Thus, NetworkPolicy cannot prevent or enforce non-root behavior.

• ✗

  Set the kubelet flag --run-non-root

  Why it's wrong here

  The Kubernetes kubelet has many configuration flags for runtime, networking, and security, but `--run-non-root` does not exist. The kubelet does not have a built-in global switch to force all containers to run as a non-root user; such enforcement must come from admission controllers (like PodSecurity or Gatekeeper) or by setting `securityContext` in the Pod spec. Using a nonexistent flag would either cause a startup error or be silently ignored, so it is not a valid way to enforce the policy.

• ✓

  Enable the PodSecurity admission controller with the 'restricted' profile

  Why this is correct

  The PodSecurity admission controller is a built-in Kubernetes admission controller that applies configurable Pod Security Standards. The `restricted` profile is the most stringent of these standards and includes a requirement for `runAsNonRoot: true` (or an equivalent non-zero `runAsUser`). By labeling a namespace with `pod-security.kubernetes.io/enforce=restricted`, the controller rejects Pods that fail this requirement at creation time. This is a native, cluster-supported way to enforce non-root execution across a namespace.

• ✗

  Use a ServiceAccount to restrict root

  Why it's wrong here

  A ServiceAccount is a Kubernetes identity object used to authenticate Pods to the Kubernetes API and to map into RBAC authorization policies. It does not influence how containers are executed, nor does it inspect or mutate a Pod's securityContext. While a ServiceAccount can be used with admission hookups (e.g., via its annotations, as in the old PodSecurityPolicy admission), by itself it cannot restrict root execution. To enforce non-root, you must use an admission control mechanism, not a ServiceAccount.

Go deeper

Related to this question