GSEC Container Security Practice Question
A security engineer is evaluating a container runtime for a production Kubernetes cluster. The requirement is that the runtime must not share the host kernel with containers, providing stronger isolation than standard runc-based containers. Which of the following runtimes best satisfies this requirement?
⚠ Common exam trap
The trap here is equating hardening features like user namespaces or SELinux with kernel isolation, when only VM-based runtimes such as Kata provide a separate kernel per pod.
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
✓
Kata Containers, which runs each pod inside a lightweight virtual machine
Kata Containers runs each pod in a lightweight virtual machine with its own guest kernel, so workloads do not share the host kernel. This hardware-virtualization-based isolation provides a stronger boundary than runc, containerd with runc, or CRI-O with SELinux, all of which share the host kernel and are therefore vulnerable to kernel-level escapes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
runc with user namespaces enabled
Why it's wrong here
User namespaces map container UIDs to unprivileged host UIDs, which reduces the impact of a container escape but still shares the host kernel. The kernel remains the same attack surface, so a kernel vulnerability could still be exploited from within the container. The requirement explicitly demands kernel isolation, which user namespaces do not provide.
- ✗
CRI-O with the default runtime configured for SELinux enforcement
Why it's wrong here
CRI-O is a Kubernetes-native container runtime, and SELinux enforcement adds mandatory access control on top of shared-kernel containers. It hardens the container against certain attacks but does not isolate the kernel. The requirement for a separate kernel is not met by SELinux policy enforcement alone, regardless of the runtime.
- ✗
containerd configured with the default runc shim
Why it's wrong here
containerd with the default runc shim uses standard Linux namespaces and cgroups, and containers share the host kernel. While containerd is a production-grade runtime, it does not provide the kernel-level isolation the requirement demands. It is the baseline against which stronger runtimes are compared, not a solution to the stated requirement.
- ✓
Kata Containers, which runs each pod inside a lightweight virtual machine
Why this is correct
Kata Containers launches each pod in a lightweight VM with its own guest kernel, so container workloads do not share the host kernel. This provides hardware-virtualization-based isolation that satisfies the requirement. A kernel exploit in the guest does not automatically compromise the host, making Kata the correct choice for stronger isolation.
About these practice questions
One of 351 original GSEC practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GSEC practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GSEC exam.