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.

• ✗

  Manually inject sidecar proxies into every pod to enforce mTLS.

  Why it's wrong here

  Manually adding sidecar proxies to every Pod is not a secure, scalable mTLS strategy: it relies on human consistency, so any Pod that misses the injection will communicate using plaintext traffic and violate the service-mesh policy. Every Pod should instead be intercepted automatically by a mutating admission webhook or a managed sidecar injection mechanism (e.g., Istio or Linkerd), which labels and rewrites Pod specs consistently. Manual injection also complicates upgrades and forces operators to manage proxy configuration drift, creating gaps in identity coverage and encrypted connectivity between services.

• ✗

  Run containers in privileged mode to allow them to perform necessary system calls.

  Why it's wrong here

  Privileged mode is far broader than simply allowing necessary system calls: it disables most container isolation, grants all capabilities (including CAP_SYS_ADMIN), exposes host devices, and effectively lets the process operate as root on the host for kernel operations, making container escape trivial if the workload is compromised. Kubernetes workloads almost never need this; instead, the correct hardening step is to drop all capabilities, add only the required Linux capabilities, and apply a seccomp profile that filters the exact system calls. Running privileged to satisfy a few syscalls needlessly elevates every microservice to maximum host access.

• ✓

  Ensure containers run with a non-root user.

  Why this is correct

  By default, containers in Kubernetes may run as the root user if the image does not declare a non-root USER, and root inside a container shares the kernel and may still access host resources depending on capabilities. Setting runAsNonRoot: true and specifying an unprivileged runAsUser (or using a non-root image USER) makes the container runtime refuse to start the process as UID 0, denying an attacker a wide range of kernel-based privilege escalation and file-permission attacks once the application is compromised. Non-root execution is a fundamental least-privilege control and must be combined with dropped capabilities and a read-only filesystem to meaningfully reduce the blast radius.

• ✓

  Use a read-only root filesystem for containers.

  Why this is correct

  A read-only root filesystem (readOnlyRootFilesystem: true) makes the container's image filesystem immutable at runtime, so an attacker who exploits the application cannot write malicious binaries to /usr/bin or tamper with libraries and configuration files baked into the image. It does not prevent writes to mounted volumes, so operators must explicitly mount emptyDir or other writable volumes for temporary data (e.g., /tmp) and keep runtime-generated files out of the root layer. This control significantly increases the cost of persistence and binary planting, and it is a key requirement in the Kubernetes Pod Security Standards.

• ✗

  Store secrets directly in container images for easy access.

  Why it's wrong here

  Baking secrets into a container image is fundamentally insecure because every image is built from immutable layers; anyone who can pull the image from a registry, cached copy, or CI artifact can inspect the layer history and extract plaintext credentials. Secrets placed in images also spread across base images and tags, making revocation and rotation impractical and turning each image into a persistent credential leak. Use Kubernetes Secrets (with RBAC, encryption at rest, and short-lived credentials) or an external secrets manager so secrets are delivered only to the Pod that actually needs them.

Go deeper

Related to this question