KCNA Kubernetes Fundamentals Practice Question
A developer creates a Pod with the following YAML snippet:
spec: containers: - name: web image: nginx ports: - containerPort: 80
The Pod is running, but the developer cannot reach it from another Pod in the same namespace using the Pod's IP address. Which command should the developer run first to verify that the container process is listening on port 80?
⚠ Common exam trap
The trap here is relying on containerPort in the Pod spec as proof that the application listens on that port, when containerPort is only metadata and does not configure the application.
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
✓
kubectl exec -it <pod-name> -- netstat -tuln
The correct first step is to check listening sockets inside the container. Because the Pod is running but unreachable, the issue could be the application not listening on the expected port. Using kubectl exec with netstat (or ss) inside the container provides direct evidence of whether the process is bound to port 80, guiding further troubleshooting.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl describe pod <pod-name>
Why it's wrong here
kubectl describe pod shows events, status, and container details but does not reveal which ports the process is listening on inside the container. It can confirm the container is running but not whether nginx is bound to port 80. This command is useful for scheduling and image pull issues, not for checking listening sockets.
- ✗
kubectl logs <pod-name>
Why it's wrong here
kubectl logs retrieves stdout/stderr from the container, which may show nginx startup messages but not the actual listening ports. Nginx logs typically show startup and access logs, not socket bindings. While logs can hint at configuration errors, they do not definitively confirm that the process is listening on port 80.
- ✗
kubectl get pod <pod-name> -o yaml
Why it's wrong here
kubectl get pod -o yaml displays the Pod specification, including containerPort, but that field is informational and does not guarantee the application is listening. The YAML will show port 80 declared, but the actual process may be bound to a different port or not listening at all. This does not verify runtime behavior.
- ✓
kubectl exec -it <pod-name> -- netstat -tuln
Why this is correct
Running netstat inside the container shows which ports are listening. If the nginx process is bound to port 80, the output will include a LISTEN entry for 0.0.0.0:80 or :::80. This directly verifies whether the application is listening and helps distinguish application issues from network policy or Service misconfiguration.
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 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 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.