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.

• ✗

  Kata Containers require no additional configuration in Kubernetes

  Why it's wrong here

  In Kubernetes, Kata Containers cannot be used without explicit additional configuration. You must install the Kata runtime on each node, define a RuntimeClass (e.g., system-runtime-class=class.kata-containers.io/kata-qemu), and then assign that RuntimeClass to Pods via the Pod spec. The kubelet also needs to be configured to recognize the kata runtime handler. Thus the claim that no extra configuration is required is incorrect.

• ✗

  Kata Containers have lower overhead than gVisor

  Why it's wrong here

  Kata Containers typically have higher overhead than gVisor, not lower. Kata boots a lightweight virtual machine with its own relatively complete kernel for each container, incurring startup latency, extra memory for the guest kernel, and virtualization costs. gVisor, by contrast, runs a user-space kernel (Sentry) that intercepts system calls without needing a hardware VM, so its per-container overhead is generally lower. The premise that Kata has lower overhead is wrong; it uses a heavier isolation mechanism.

• ✓

  Kata Containers use lightweight VMs to isolate containers

  Why this is correct

  Kata Containers use lightweight virtual machines to isolate containers, providing a hardware-level security boundary. Each container or pod runs inside its own VM, using a guest kernel and hardware virtualization (e.g., via QEMU, Cloud Hypervisor, or Firecracker), while still offering container interfaces like OCI. This design delivers stronger isolation than standard runc or even gVisor, because a separate kernel and hardware virtualization protect against many host-validating side channels. This is precisely the defining characteristic of Kata Containers.

• ✗

  Kata Containers provide a user-space kernel that intercepts system calls

  Why it's wrong here

  The behavior of a user-space kernel that intercepts system calls is the hallmark of gVisor, not Kata Containers. Kata uses hardware virtualization to run a standard Linux kernel inside a VM; it does not rely on a user-space syscall-interception layer. gVisor's Sentry handles syscalls in user space and spoofs kernel boundaries, whereas Kata's VM provides a true kernel boundary via hardware-assisted virtualization. Therefore, this option incorrectly describes a gVisor feature as a Kata characteristic.

Go deeper

Related to this question