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.

• ✓

  They are compatible with the OCI runtime specification

  Why this is correct

  Container sandboxes such as gVisor (runsc) and Kata Containers implement the OCI runtime specification, meaning they expose the same lifecycle commands (create, start, delete) and expect the same OCI image/bundle format. This allows containerd or CRI-O to treat them as drop-in replacements for runc, requiring no changes to the kubelet, container images, or orchestration workflows. OCI compatibility is therefore a core enabler for using these sandboxes in Kubernetes without breaking existing tooling.

• ✗

  They improve container performance over native runc

  Why it's wrong here

  Sandboxing generally adds overhead and reduces performance compared to native runc, not improves it. gVisor incurs latency by intercepting and translating system calls through a user-space kernel, while Kata Containers pays the cost of booting a lightweight virtual machine and performing hardware-virtualized I/O. CPU-, syscall-, or network-heavy workloads can see noticeably lower throughput and higher latency, so sandboxes are chosen for stronger isolation rather than speed.

• ✓

  They can be used with RuntimeClass to select the sandbox runtime per pod

  Why this is correct

  Kubernetes RuntimeClass is the built-in mechanism for choosing a sandbox runtime on a per-pod basis. An administrator defines a RuntimeClass object whose handler points to a specific sandbox runtime (for example, runsc or kata), and then a pod can declare `runtimeClassName` to request that isolation level. This enables mixed clusters where untrusted or sensitive workloads run inside sandboxes while other pods continue using runc, all under standard Kubernetes scheduling semantics.

• ✓

  They provide an additional layer of isolation between containers and the host kernel

  Why this is correct

  Sandboxing solutions add a security boundary between the container and the host kernel. Kata Containers places each pod in a lightweight virtual machine with its own Linux guest kernel, whereas gVisor implements an application kernel in Go that mediates system calls before they ever reach the host. This extra layer prevents a compromised container from directly exploiting host kernel vulnerabilities, providing defense-in-depth beyond the traditional namespace, cgroup, and seccomp isolation used by runc.

• ✗

  They use the host kernel directly for all system calls

  Why it's wrong here

  The defining behavior of native runc is executing containers with direct access to the host kernel for system calls; sandboxes explicitly avoid that. gVisor intercepts system calls and either emulates them or converts them into guarded host operations through a user-space kernel, while Kata routes system calls to an isolated guest kernel inside a VM. Thus a sandboxed container never makes unfiltered, direct syscalls to the host kernel, which is exactly what makes it more resistant to kernel-based container escape attacks than runc.

Go deeper

Related to this question