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.

• ✓

  Set securityContext.runAsNonRoot: true

  Why this is correct

  Setting securityContext.runAsNonRoot: true forces Kubernetes to reject the container if the image runs as UID 0, ensuring the process executes with a non-root user ID. This prevents an attacker from obtaining root privileges inside the container after exploiting a vulnerability, which massively reduces the ability to modify system files, install tooling, or leverage kernel-level privilege escalation. It also helps satisfy Pod Security Standards restricted profile requirements.

• ✓

  Drop all capabilities via securityContext.capabilities.drop: ["ALL"]

  Why this is correct

  Linux capabilities are discrete privileges that root normally has; by dropping ALL with capabilities.drop: ["ALL"], the container is left with no capabilities, such as CAP_NET_BIND_SERVICE, CAP_KILL, or CAP_CHOWN. This follows the principle of least privilege: even if the container's user is compromised, the kernel refuses any privileged syscall like mount, raw socket use, or ptrace. Because capabilities are tied to the process's effective credentials, this control works independently of runAsNonRoot, preventing privilege escalation via retained capabilities.

• ✗

  Set high CPU requests to ensure performance

  Why it's wrong here

  CPU requests are a scheduling and resource QoS mechanism, not a security boundary. They only indicate to the Kubernetes scheduler how much node capacity the pod requires, affecting placement and eviction; they do nothing to restrict syscalls, filesystem access, or network behavior. Setting high CPU requests may actually worsen security by exhausting node resources and enabling denial-of-service against co-located workloads, while real hardening requires seccomp, AppArmor, and securityContext fields.

• ✓

  Set securityContext.readOnlyRootFilesystem: true

  Why this is correct

  Configuring securityContext.readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, so even a fully compromised process cannot overwrite system binaries, libraries, or configuration files. Writes are only possible on explicitly mounted emptyDir or other writable volumes, encouraging a design where application state is externalized and /tmp is the only writable path. This makes it significantly harder for an attacker to persist backdoors or tamper with the container's execution environment, since any modification requires rebooting the pod.

• ✗

  Expose secrets as environment variables for convenience

  Why it's wrong here

  Putting secrets in environment variables is a serious anti-pattern because environment variables are inherited by all child processes, visible in /proc/1/environ, and often get logged by applications or debugging tools. The secret data is only base64-encoded, not encrypted, so it can be easily decoded by anyone who can read the pod definition or process environment. Kubernetes mounted Secrets are safer because they are exposed as files with permissions, use tmpfs, and allow rotation through file updates rather than container recreation.

Go deeper

Related to this question