Courseiva

CKS Minimize Microservice Vulnerabilities Practice Question

You want to run a workload in a sandboxed container using gVisor. You have created a RuntimeClass named 'gvisor' that references the 'runsc' handler. Which of the following Pod specs correctly uses this RuntimeClass?

⚠ Common exam trap

The CNCF-CKS exam often tests the distinction between `runtimeClassName` (a flat string field) and incorrect nested or annotation-based approaches, as candidates may confuse it with other Pod spec fields like `nodeSelector` or `annotations`.

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

✓

apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClassName: gvisor containers: - name: app image: nginx

The `runtimeClassName` field in the Pod spec is the standard Kubernetes API field used to specify a RuntimeClass for a Pod. The RuntimeClass named 'gvisor' must be defined in the cluster with a handler 'runsc', and setting `runtimeClassName: gvisor` in the Pod spec instructs the kubelet to use the gVisor runtime (runsc) to run the containers in a sandboxed environment, minimizing microservice vulnerabilities.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    apiVersion: v1 kind: Pod metadata: name: sandbox-pod annotations: runtimeClass: gvisor spec: containers: - name: app image: nginx

    Why it's wrong here

    Annotations are arbitrary metadata and do not influence runtime selection, so the Pod runs under the default runtime. It is tempting because annotations configure some Kubernetes features, and they are correct for non-scheduling metadata such as Prometheus scrape hints — but RuntimeClass selection requires the dedicated spec field.

  • ✓

    apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClassName: gvisor containers: - name: app image: nginx

    Why this is correct

    Setting runtimeClassName: gvisor in the pod spec instructs the kubelet to select the gvisor RuntimeClass, which maps to the runsc handler and runs containers through gVisor's user-space kernel for sandboxing. This is the correct field; nodeName or annotations would not engage the sandbox runtime.

  • ✗

    apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: nodeSelector: runtime: gvisor containers: - name: app image: nginx

    Why it's wrong here

    nodeSelector matches node labels, not RuntimeClass names, so it schedules the Pod onto nodes labelled runtime: gvisor without invoking runsc. It is tempting because node selection is a legitimate scheduling mechanism, and it is correct when pinning workloads to nodes with specific hardware or taints — but it cannot select a container runtime handler.

  • ✗

    apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClass: name: gvisor containers: - name: app image: nginx

    Why it's wrong here

    Kubernetes has no spec.runtimeClass field; RuntimeClass is selected via spec.runtimeClassName, so this manifest is rejected by the API server. It is tempting because the nested name: gvisor mirrors the RuntimeClass object's own metadata, and that structure is correct inside a RuntimeClass resource — but not within a Pod spec.

About these practice questions

One of 845 original CKS 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 →

How Courseiva writes practice questions · Editorial policy

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.