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 run containers in lightweight VMs, providing hardware-level isolation.

  Why this is correct

  Kata Containers provide hardware-level isolation by spawning each container or pod inside a lightweight VM that is booted with its own guest kernel, typically using KVM on Linux. The guest kernel handles system calls as if it were a real host, and the hypervisor enforces CPU and memory isolation at the hardware boundary. This design gives each container a full kernel of its own, which is a stronger isolation boundary than syscall interception because even a compromised guest kernel cannot directly access the host kernel.

• ✓

  gVisor provides a kernel-level sandbox by implementing a user-space kernel.

  Why this is correct

  gVisor achieves sandboxing by placing a user-space kernel, the Sentry, between containers and the host kernel. It intercepts and processes system calls in Go, emulating kernel behavior without needing a separate Kernel-based Virtual Machine (KVM) or full virtualization. This creates a kernel-level isolation boundary because syscalls are not passed directly to the host kernel; instead, they are filtered, validated, and executed in user space, limiting host kernel attack surface.

• ✗

  Kata Containers use the host kernel for system calls.

  Why it's wrong here

  Kata Containers never rely on the host kernel for system call handling; instead, each VM runs an independent guest kernel (for example, a patched Linux kernel) that services all syscalls from the containerized workload. This is a core difference from gVisor, which intercepts syscalls in user space, and from native containerd/runc containers, which call the host kernel directly. Because the guest kernel is isolated by the VM, a syscall issued inside a Kata container cannot reach the host kernel, which is precisely what enables hardware-level isolation.

• ✗

  gVisor runs containers in separate VMs for each pod.

  Why it's wrong here

  gVisor does not use virtual machines at all; it runs as a normal user-space process on the host, with each container sandboxed by runsc and the Sentry in a separate thread group. Unlike Kata Containers, which leverage a hypervisor to create lightweight VMs, gVisor's isolation is purely at the system-call interface, not at the hardware level. Therefore, the claim that gVisor runs containers in separate VMs is categorically false and confuses its syscall-intercepting design with hardware virtualization.

• ✗

  Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

  Why it's wrong here

  RuntimeClass is a convenient Kubernetes mechanism for selecting a non-default runtime such as gVisor or Kata, but it is not a strict requirement. You can configure containerd, CRI-O, or another CRI to use these runtimes as the default runtime or as an additional runtime handler, and then reference them via runtimeClassName when needed. However, if a cluster's standa.rd runtime is already set to gVisor or Kata, Pods may run without any RuntimeClass object or field at all, proving that RuntimeClass is optional, not mandatory.

Go deeper

Related to this question