Minimize Microservice Vulnerabilities →hardMultiple Select

CKS Minimize Microservice Vulnerabilities Practice Question

You are deploying a workload that must be isolated from other workloads on the same node. You want to use a container sandboxing runtime to provide an additional security boundary. Which TWO of the following are true regarding the use of gVisor or Kata Containers in a Kubernetes cluster? (Choose two.)

⚠ Common exam trap

Watch out — candidates often confuse sandboxing with privileged mode, which actually removes isolation, or assuming sandboxing provides image encryption rather than runtime isolation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

They require a RuntimeClass resource and a corresponding handler configured on the node.

Sandboxed runtimes like gVisor and Kata Containers require a RuntimeClass and a node-level handler to be selected by pods. They add isolation by using a user-space kernel or a lightweight VM, reducing the risk of container escapes. They are not enabled via privileged mode, do not encrypt images, and are not limited to Windows nodes.

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 only supported on Windows nodes and cannot run on Linux.
Why it's wrong here
Both gVisor and Kata Containers are primarily designed for Linux. gVisor is a Linux-specific sandbox, and Kata Containers runs Linux and Windows guests, but the runtimes themselves are commonly used on Linux nodes. Claiming they are only for Windows is incorrect and would mislead you away from using them on a standard Linux Kubernetes cluster.
✓
They require a RuntimeClass resource and a corresponding handler configured on the node.
Why this is correct
Both gVisor and Kata Containers are implemented as container runtimes that must be registered with the container runtime interface (CRI) on each node. A RuntimeClass object references the handler name, and the pod's spec.runtimeClassName selects it. Without the RuntimeClass and node-level handler, the pod cannot be scheduled with the sandboxed runtime, making this a necessary configuration step.
✓
They provide kernel-level isolation by running each container in its own virtual machine or user-space kernel.
Why this is correct
gVisor intercepts syscalls and implements a user-space kernel, while Kata Containers runs each pod in a lightweight VM with its own kernel. Both provide a stronger isolation boundary than standard runc containers, which share the host kernel. This extra layer limits the impact of kernel exploits and container escapes, which is the primary reason to adopt them in a multi-tenant environment.
✗
They can be enabled by setting the pod's securityContext.privileged field to true.
Why it's wrong here
Setting privileged to true gives the container full access to the host and disables most security boundaries. It does not enable gVisor or Kata Containers. In fact, privileged containers are incompatible with the isolation goals of sandboxed runtimes, and using privileged would undermine the security boundary you are trying to achieve with a sandbox.
✗
They automatically encrypt all container images at rest on the node.
Why it's wrong here
Sandboxing runtimes focus on runtime isolation, not image encryption. Image encryption at rest is typically handled by the container runtime storage layer or by encrypting the node's disk. gVisor and Kata Containers do not provide image encryption, so this statement is unrelated to their purpose and would not satisfy a requirement for data-at-rest protection.

Go deeper

CKS Minimize Microservice Vulnerabilities Practice Question

Why each option matters

Option-by-option breakdown

Related to this question