CKS Minimize Microservice Vulnerabilities Practice Question
A pod is using a RuntimeClass that specifies gVisor (runsc). Which of the following scenarios is most likely to cause the pod to fail?
⚠ Common exam trap
The CKS exam often tests the misconception that gVisor is a lightweight container runtime that allows all standard operations, but the trap here is that `privileged: true` and hostPath mounts are fundamentally incompatible with gVisor's sandboxing model, leading to pod failure.
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
✓
The pod attempts to mount a hostPath directory with privileged access.
GVisor (runsc) operates as a sandboxed kernel that intercepts system calls, and it does not support privileged operations such as mounting hostPath directories with privileged access. The `privileged: true` flag attempts to bypass the sandbox, which gVisor explicitly denies, causing the pod to fail. This is a core security constraint of gVisor, which aims to minimize microservice vulnerabilities by restricting host-level interactions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod runs a web server listening on port 8080.
Why it's wrong here
A web server on port 8080 is completely normal under gVisor because runsc implements a user-space network stack (netstack) that handles TCP/IP at the application layer, intercepting socket, bind, and listen syscalls without needing to touch the host kernel. Standard network operations require no privileged host access, so the pod functions exactly as it would on an ordinary runtime. The key distinction is that gVisor translates the syscalls into its own virtual network functions, not that it blocks legitimate web serving.
- ✓
The pod attempts to mount a hostPath directory with privileged access.
Why this is correct
This is the only option that would realistically fail because gVisor's design goal is to prevent pods from accessing host resources directly. A hostPath volume bypasses the VFS layer and requests a raw directory from the host, and while gVisor can theoretically mount hostPath volumes if explicitly configured, combining it with privileged: true is contradictory — gVisor explicitly rejects giving the app direct host access. Even a privileged container inside runsc runs with gVisor's restricted kernel, so the mount attempt either fails at volume setup or the app cannot perform privileged operations on the host path, causing the pod to misbehave or not start.
- ✗
The pod mounts a ConfigMap as a volume.
Why it's wrong here
ConfigMap volumes work seamlessly with gVisor because they are synthesized by the kubelet and exposed to the pod as read-only files through the volume management layer. gVisor intercepts the opens and reads on those files and serves them from the gofer process, which acts as a trusted broker between the sandbox and the host filesystem. There are no raw host syscalls or privileged operations involved, so a ConfigMap mount is a supported and safe operation under runsc.
- ✗
The pod uses a PersistentVolumeClaim for storage.
Why it's wrong here
A PersistentVolumeClaim (PVC) is also perfectly compatible with gVisor because storage requests are implemented via the volume plugin mechanism and ultimately accessed through the gofer or a 9P-backed filesystem proxy, not directly through host kernel drivers. The sandbox's application-level syscalls are translated, and block storage or network filesystems are handled behind the scenes by the host's storage stack on behalf of the pod. Since the pod never obtains direct host device access, PVCs operate normally under gVisor and do not trigger the restrictions that host mounts or privileged access do.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF 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 CKS exam.