KCNA Container Orchestration Practice Question
You run the command 'kubectl get pods -n default' and see no pods listed. However, you are sure there should be pods. What is the most likely cause?
⚠ Common exam trap
A common pitfall is assuming an empty pod list means no pods exist, without checking the current kubectl context. Candidates often forget that the context determines which cluster and namespace are being queried.
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 current kubectl context is connected to a different cluster
`kubectl` uses the current context defined in the kubeconfig file to determine which cluster and namespace to communicate with. If the context points to a different cluster (e.g., a test or staging cluster), the `kubectl get pods -n default` command will query that cluster's API server, which may have no pods in the `default` namespace, even though the intended cluster has pods. This is a common misconfiguration when working with multiple clusters.
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 current kubectl context is connected to a different cluster
Why this is correct
kubectl queries whatever cluster the active context points to, so an empty default namespace usually means the context targets a different cluster than the one holding the pods. Switching context with kubectl config use-context reveals the intended workloads.
- ✗
All pods are in the 'kube-system' namespace
Why it's wrong here
Namespace scoping means '-n default' lists only default-namespace pods, so pods elsewhere are invisible regardless of existence. kube-system is tempting because system workloads genuinely live there, and it would be the cause if the administrator had queried that namespace instead.
- ✗
The kube-apiserver is down
Why it's wrong here
An unreachable kube-apiserver would make kubectl return a connection error, not an empty list; the command succeeded, so the control plane is responding. It is tempting because API server outages do break cluster operations, but that scenario produces explicit errors rather than a clean empty result.
- ✗
The pods are in the 'Pending' state and not listed
Why it's wrong here
Pending pods still appear in kubectl get pods output with STATUS Pending; they are never hidden. The state is tempting because Pending signals scheduling trouble, but it concerns pod readiness, not listing, so it cannot explain an empty result.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This KCNA 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 KCNA exam.