CKA Troubleshooting Practice Question
An application team reports that a Deployment's Pods in namespace 'web' become unreachable after a rolling update, even though 'kubectl get pods' shows them as Running and Ready. The Service 'web-svc' of type ClusterIP exists and has endpoints listed. You exec into a client Pod in the same namespace and run 'curl http://web-svc:8080'; the connection times out. You then run 'kubectl get networkpolicy -n web' and see a policy named 'deny-all-ingress' with podSelector matching the web Pods and policyTypes: Ingress, but no ingress rules. Which of the following is the MOST likely cause of the timeout?
⚠ Common exam trap
The trap here is assuming that a NetworkPolicy with no rules is a no-op, when in fact an empty ingress rule list combined with policyTypes: Ingress denies all ingress traffic to the selected Pods.
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 NetworkPolicy 'deny-all-ingress' is selecting the web Pods and, because it has no ingress rules, it denies all ingress traffic to those Pods.
The presence of a NetworkPolicy named 'deny-all-ingress' that selects the web Pods and has no ingress rules is the definitive cause. Such a policy isolates the Pods, dropping all inbound connections. The Service and endpoints are healthy, so the timeout is due to packet filtering, not routing or readiness. Removing or modifying the policy restores connectivity.
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 Service 'web-svc' is missing a selector that matches the Pod labels, so no endpoints are created and traffic cannot be routed.
Why it's wrong here
The scenario states that the Service has endpoints listed, meaning the selector does match and endpoints exist. If endpoints were missing, the issue would be a connection refused or no route rather than a timeout, and the policy would still be the primary suspect. This option contradicts the given evidence.
- ✗
The Pods are not actually Ready because their readiness probe is failing, so the Service removes them from endpoints.
Why it's wrong here
The scenario explicitly states that the Pods are Running and Ready, and that the Service has endpoints. If readiness probes were failing, the Pods would not be Ready, and endpoints would be empty. This option contradicts the observed state and does not account for the presence of the deny-all-ingress policy.
- ✓
The NetworkPolicy 'deny-all-ingress' is selecting the web Pods and, because it has no ingress rules, it denies all ingress traffic to those Pods.
Why this is correct
A NetworkPolicy with policyTypes: Ingress and an empty ingress rule list isolates the selected Pods, denying all inbound traffic except from the Pod's own node. Since the policy selects the web Pods, the client's connection is dropped, causing the timeout. This directly explains the symptom and the presence of the policy.
- ✗
The kube-proxy component on the client's node is not programmed with the Service's iptables rules, so the ClusterIP is not reachable.
Why it's wrong here
If kube-proxy were failing, other Services would likely also be affected, and the presence of a NetworkPolicy that denies ingress is a more specific and immediate cause. A kube-proxy issue would typically manifest as connection refused or no route to host, not a timeout after the policy was applied.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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 CKA 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 CKA exam.