CKS Minimize Microservice Vulnerabilities Practice Question

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 node has insufficient memory

  Why it's wrong here

  Insufficient memory causes the kubelet to evict the pod or the container to be OOMKilled, producing events like 'The node was low on resource: memory' or an exit code 137 — never a message about the container runtime network. The error 'container runtime network not ready' is a sandbox-level failure indicating the CNI network setup for the pod's network namespace failed, which memory pressure does not affect. Memory exhaustion occurs after the pod is started and processes allocate memory, while the network not ready error occurs during pod sandbox creation, long before any container process runs.

• ✗

  The pod is trying to mount a hostPath volume

  Why it's wrong here

  HostPath volumes are incompatible with the traditional local filesystem assumptions of runC, but Kata Containers explicitly supports them by sharing the host directory into the guest VM via virtiofs or 9p, with only minor restrictions such as the directory needing to exist. A problem with a hostPath volume would surface as a volume mount failure, e.g. 'failed to mount volume' or 'MountVolume.SetUp failed', not as a network readiness error from the container runtime. Since the reported error is specifically about network readiness, the selected option points to a CNI/network configuration failure, not storage.

• ✓

  The CNI plugin is not configured correctly for the kata RuntimeClass

  Why this is correct

  Kata Containers runs each pod inside a lightweight VM, so CNI must do more than create a veth pair in the host namespace: it must set up a virtual network interface (e.g., TAP or virtio-net) that connects the guest VM to the host's network infrastructure. If the CNI plugin in use is not compatible with Kata's VM-based model — for example, a plugin that assumes the container's network namespace is a regular host netns — the plugin's ADD command may fail or return before the VM's network interface is ready. This causes the containerd/kubelet sandbox creation to fail with a network not ready error, exactly as described in the scenario.

• ✗

  The pod's securityContext sets runAsNonRoot: true

  Why it's wrong here

  The runAsNonRoot security context only constrains the UID of the process running inside the container; it does not interact with the network stack or the CNI plugins. If the image's user is root and runAsNonRoot is true, the container runtime refuses to start the container with a message about 'runAsNonRoot' and the image's user, but this is a container-level security check, totally separate from the pod sandbox network setup. Therefore, this setting cannot produce the reported 'container runtime network not ready' error, which is caused by the sandbox's network interface failing to initialize during CNI configuration.

Go deeper

Related to this question