CKS Monitoring, Logging and Runtime Security Practice Question
An administrator runs 'crictl ps' and sees no containers listed, but kubectl shows running pods. What is the most likely cause?
⚠ Common exam trap
CKS often tests the distinction between kubectl and crictl; candidates might think crictl is namespace-aware or that it relies on the kubelet, but it directly queries the container runtime, so socket misconfiguration is a common trap.
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
✓
crictl is not configured to connect to the correct container runtime socket
The most likely cause is that crictl is not configured to connect to the correct container runtime socket. crictl is a command-line tool for interacting with CRI-compatible container runtimes. If it is not pointed to the correct socket (e.g., /var/run/containerd/containerd.sock or /var/run/crio/crio.sock), it will not see any containers, even though kubectl (which communicates with the kubelet) shows running pods. This is a common misconfiguration when multiple runtimes are installed or when the default socket path differs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
crictl is not configured to connect to the correct container runtime socket
Why this is correct
crictl is a CLI that communicates with a CRI-compliant runtime via a gRPC endpoint, and it must be told where that runtime's socket lives via the --runtime-endpoint flag or a configuration file such as /etc/crictl.yaml. If it points to a default or stale socket (for example /var/run/dockershim.sock instead of /run/containerd/containerd.sock), it will not see the containers managed by the actual containerd or CRI-O runtime. Even though pods are running, a misconfigured runtime endpoint commonly produces a misleading empty list or a connection error, so this is the correct explanation.
- ✗
The images have not been pulled yet
Why it's wrong here
For any Kubernetes pod to reach the Running state, kubelet must have already pulled all required container images; if an image were missing or still being downloaded, the container would remain in ImagePullBackOff or ContainerCreating and would not show up in crictl ps as a running container. Since crictl ps lists only currently running containers, an empty list means there are no running containers to inspect, not that images are unavailable — in fact, running containers imply their images already exist locally. Thus, image pulling status cannot explain why crictl ps shows no containers when pods are actively running.
- ✗
The containers are running in a different namespace
Why it's wrong here
Kubernetes namespaces are logical API constructs used to group objects like pods and services; they have no direct counterpart inside the container runtime itself. crictl queries the runtime socket directly and is not aware of Kubernetes namespaces, so it lists every container on that node regardless of which namespace it belongs to — including containers from kube-system, monitoring, or any other namespace. A container being in a different Kubernetes namespace would still appear in crictl ps output, so this option is not a reason for seeing no containers.
- ✗
The kubelet is not running
Why it's wrong here
The kubelet is the CRI client that talks to the runtime to create and manage pods, but crictl is an independent diagnostic tool that also connects to the same runtime socket, bypassing kubelet entirely. If the kubelet were stopped, any containers that are already running would continue to be visible to crictl, and conversely, a stopped kubelet would not make the runtime socket unreadable or hide existing containers. In the scenario described, pods are running, which implies the kubelet is alive and actively managing them; therefore, a down kubelet is not a plausible cause for crictl returning an empty container list.
Go deeper
Related to this question
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 →
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 CNCF exam blueprint
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.