20+ practice questions focused on Services & Networking — one of the most tested topics on the Certified Kubernetes Administrator CKA exam. Each question includes a detailed explanation so you learn why the right answer is correct.
Start Services & Networking PracticeA developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?
Explanation: The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service routes traffic to pods based on label selectors; if the selector does not match the labels on the pods (e.g., the pods have labels like 'app: myapp' but the Service selector is 'app: frontend'), the endpoints controller will not populate the Service's endpoints, and traffic will be dropped, resulting in a 'Connection refused' error.
An administrator needs to expose a set of pods running a stateful application that require stable network identities. The pods must be reachable from outside the cluster via a DNS name that resolves to individual pod IPs. Which Service type should be used?
Explanation: A Headless Service (ClusterIP: None) is correct because it allows clients to discover individual pod IPs via DNS lookups, returning A/AAAA records for each pod rather than a single ClusterIP. This provides stable network identities for stateful pods, as each pod gets a unique DNS name (e.g., pod-name.service-name.namespace.svc.cluster.local) that resolves directly to its IP, enabling external access through a DNS-based discovery mechanism.
A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?
Explanation: Option D is correct because Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).
A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?
Explanation: With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.
An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?
Explanation: The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.
+15 more Services & Networking questions available
Practice all Services & Networking questions1. Baseline your knowledge
Start with 10 questions to gauge your current understanding of Services & Networking. This tells you whether you need a concept refresher or just practice.
2. Review every explanation
For each question — right or wrong — read the full explanation. Understanding why an answer is correct is more valuable than knowing the answer itself.
3. Focus on exam traps
Services & Networking questions on the CKA frequently use trap wording. Look for subtle differences in answers that test your precision, not just general knowledge.
4. Reach 80% consistently
Do repeated sessions until you score 80%+ three times in a row. Then move to mixed-mode practice to test cross-topic recall under realistic conditions.
The exact number varies per candidate. Services & Networking is tested as part of the Certified Kubernetes Administrator CKA blueprint. Practicing with targeted Services & Networking questions ensures you can handle any format or difficulty that appears.
Yes. Courseiva provides free CKA practice questions across all exam topics and domains. The platform includes topic-based practice, mock exams, missed-question review, bookmarked questions, and readiness tracking — no account required.
Difficulty is subjective, but Services & Networking is a high-priority exam concept tested in multiple ways — direct recall, scenario analysis, and command-output interpretation. Consistent practice is the best way to build confidence.
Launch a full Services & Networking practice session with instant scoring and detailed explanations.
Start Services & Networking Practice →