KCNA - Container Orchestration (28% of the exam) - Section 2.6
Describe the Linux primitives and runtime options that isolate containers.
Namespaces and cgroups as the isolation and limiting primitives, and sandboxed runtimes such as gVisor and Kata Containers where stronger isolation is required than a shared kernel provides.
Linux namespacescgroupsgVisorKata Containersrootless containers
Practice question for this objective
lock_openFree sampleContainer Orchestrationhard
A team runs semi-trusted third-party code and wants stronger isolation than the default runtime gives, because a kernel exploit inside a container could compromise the host. They want to keep container start-up fast and avoid running a full separate guest kernel per Pod. They choose a runtime that interposes a user-space kernel to intercept and service the container's system calls, shrinking the host kernel attack surface. Which runtime matches this approach?
AgVisor, which runs a user-space kernel that intercepts container syscalls before they reach the host kernelcheck_circle Correct
BKata Containers, which wraps each Pod in a dedicated lightweight virtual machine with its own guest kernel
Crunc, the default OCI runtime that starts containers as host processes sharing the host kernel
Dchroot, which changes the apparent root directory so the process sees a different filesystem tree
gVisor strengthens isolation by intercepting container syscalls in a user-space kernel rather than running a full guest kernel. gVisor places an application kernel in user space between the container and the host, servicing most syscalls itself and forwarding only a limited set to the host, which reduces the host kernel attack surface without the cost of a per-Pod guest kernel.
Why A is correct: gVisor inserts a user-space application kernel that handles the container's system calls, so only a narrow set reaches the host kernel, giving stronger isolation without booting a full guest kernel per container.
Why B is wrong: Tempting because Kata also strengthens isolation over the default runtime, but it does so by running a real guest kernel inside a VM, which is exactly the full separate guest kernel the team wanted to avoid.
Why C is wrong: Tempting because runc is the runtime already in use, but it shares the host kernel directly and provides no extra syscall interception, so it does not deliver the stronger isolation being sought.
Why D is wrong: Tempting because chroot is an early isolation mechanism, but it only remaps the filesystem view and offers no syscall filtering or kernel attack-surface reduction.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
gVisor boots a full guest kernel for each Pod, whereas Kata Containers shares the host kernel directly with no additional layer.
errorWhy it is wrong: This reverses the two designs: it is Kata Containers that runs a guest kernel, while gVisor does not boot a per-Pod virtual machine and does not simply share the host kernel unmediated.
Privileged containers, which grant the container broad host access
errorWhy it is wrong: Privileged containers are the opposite of what is wanted: they grant the container broad access to host devices and capabilities, so a breakout would land with more privilege rather than as an unprivileged user.
Each container shares the host kernel but is confined by a stricter seccomp profile that is applied automatically when it starts.
errorWhy it is wrong: A tighter seccomp profile does reduce risk, but it still shares the host kernel, so it does not give the separate-kernel boundary that Kata Containers is chosen for.