CKA Troubleshooting Practice Question
A Pod is running but cannot connect to a Service. You have verified that the Service endpoints are correct. Which of the following is the most likely cause if the Pod is using hostNetwork: true?
⚠ Common exam trap
It's easy for candidates to assume `hostNetwork: true` gives the Pod full access to all cluster services, but they overlook that DNS resolution for ClusterIP Services depends on the cluster DNS being reachable and properly configured in the Pod's resolv.conf, which is not automatically set when using hostNetwork.
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 Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration
When a Pod uses `hostNetwork: true`, it shares the node's network namespace and directly uses the host's network stack. ClusterIP Services are virtual IPs managed by iptables or IPVS rules on the node, but these rules are typically applied only to the host's network namespace. However, the most common issue is that the Pod's DNS resolver (e.g., `/etc/resolv.conf`) is configured to resolve the Service name via the cluster's DNS (CoreDNS/kube-dns), which returns a ClusterIP. Since the Pod is on the host network, it may not have the necessary iptables rules to route traffic to the ClusterIP, or the DNS configuration may point to a DNS server that is not reachable from the host network (e.g., the cluster DNS service IP itself). Option D correctly identifies that the Pod cannot resolve the ClusterIP due to DNS configuration, as the Pod's DNS settings are inherited from the node but may not include the cluster DNS server, or the cluster DNS is not accessible from the host network.
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 kube-proxy is not running on the node
Why it's wrong here
Kube-proxy is essential for implementing the Kubernetes Service abstraction by programming network rules (e.g., iptables or IPVS) on each node to direct traffic to Service ClusterIPs. If kube-proxy were not running, *all* pods on that node, or potentially across the cluster, would be unable to connect to *any* Service ClusterIP. This would manifest as a widespread network failure, not an isolated issue with a single pod, especially if other pods are functioning and Service endpoints are correctly populated.
- ✗
The Service is not defined correctly
Why it's wrong here
A Kubernetes Service definition primarily establishes a stable network endpoint (ClusterIP and port) and uses selectors to identify its backend Pods. If the Service's endpoints are verified as correct and populated with the IP addresses of the target pods, it inherently confirms that the Service's selector and port mapping are functioning as intended. Therefore, the Service itself is correctly defined and discovering its backends, making its definition an unlikely cause for a specific pod's connectivity problem.
- ✗
The container image is missing networking tools
Why it's wrong here
While a container image lacking common networking tools like `ping`, `curl`, or `netcat` would significantly impede troubleshooting and diagnostic efforts, it does not inherently prevent network connectivity. The pod's ability to establish connections relies on the underlying container runtime, CNI plugin, and kernel network stack, not on the presence of user-space diagnostic utilities within the container itself. Therefore, missing tools would only prevent testing, not cause the fundamental communication failure.
- ✓
The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration
Why this is correct
When a Pod is configured with `hostNetwork: true`, it directly uses the node's network namespace, bypassing the Kubernetes CNI network. Consequently, such a pod inherits the node's `/etc/resolv.conf` for DNS resolution instead of the cluster's internal DNS (CoreDNS/kube-dns). The node's DNS resolver typically cannot resolve Kubernetes Service ClusterIPs, which are internal to the cluster's DNS domain, leading to name resolution failures for services. This specific DNS misconfiguration prevents the `hostNetwork` pod from finding the Service's IP address.
Visual reference
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
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.
Key term
CoreDNS
CoreDNS is a fast, flexible, and pluggable Domain Name System (DNS) server that is often used as the cluster DNS for Kubernetes, translating service names into IP addresses so containers can find each other.
About these practice questions
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.