CKA Services and Networking Practice Questions

Free CKA Services and Networking practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. Sign up free to practice the full set.

1. Question 1Services and Networking

   Which Service type exposes the Service on each node's IP at a static port?

   • AClusterIP
   • BLoadBalancer
   • CExternalName
   • DNodePortCorrect
   ✓ Correct answer: D

   A NodePort Service allocates a static port in the range 30000-32767 on every cluster node and forwards traffic arriving at <NodeIP>:<NodePort> to the backend pods. Kubernetes automatically creates a ClusterIP for the Service as well, so NodePort builds on top of ClusterIP. This makes the application reachable from outside the cluster directly through any node's IP address without requiring a cloud load balancer.

   Why the other options are wrong

   • AClusterIP creates an internal virtual IP that is only reachable within the cluster; it does not expose the Service on node IPs or open any port on the node's network interface.
   • BLoadBalancer provisions an external cloud load balancer that provides a single external IP; it does create a NodePort internally but is a distinct Service type that depends on cloud provider integration.
   • CExternalName maps the Service to an external DNS name via a CNAME record; it does not expose any port on the nodes and is used to give cluster-internal DNS aliases to external services.
2. Question 2Services and Networking

   You create an Ingress resource but see no routing. What is the most likely reason?

   • AThe Ingress needs a NodePort Service
   • BNo Ingress controller is deployedCorrect
   • CThe Ingress class must be set to none
   • DCoreDNS has not cached the new host
   ✓ Correct answer: B

   The Ingress object is just configuration; a running Ingress controller such as ingress-nginx must watch and implement it. Without a controller, creating the Ingress has no effect on traffic. The controller programs the actual proxy or load balancer that serves the rules.

   Why the other options are wrong

   • AAn Ingress routes to a Service but does not require it to be NodePort.
   • CThere is no 'none' class requirement; a controller must simply exist.
   • DIngress routing is done by the controller, not by DNS caching.
3. Question 3Services and Networking

   How does a Service decide which pods receive its traffic?

   • ABy matching pod labels with a selectorCorrect
   • BBy listing pod names in the Service spec
   • CBy the order pods were created in time
   • DBy choosing pods on the same node only
   ✓ Correct answer: A

   A Service's spec.selector matches pod labels, and the endpoints controller populates the Service with the IPs of matching, ready pods. As pods with those labels come and go, the endpoint set updates automatically. Pods are never referenced by name in a standard Service.

   Why the other options are wrong

   • BA Service uses label selectors, not an explicit list of pod names.
   • CCreation order does not determine Service membership.
   • DEndpoints are chosen by labels regardless of which node a pod runs on.
4. Question 4Services and Networking

   What is the purpose of an ExternalName service?

   • AIt maps a service to a DNS name for an external endpointCorrect
   • BIt bypasses kube-proxy for external traffic
   • CIt creates an external IP address for the service
   • DIt exposes a service on each node external IP
   ✓ Correct answer: A

   An ExternalName service does not have a selector or ClusterIP. Instead, when a pod queries the service's DNS name, CoreDNS returns a CNAME record pointing to the value of spec.externalName. This allows applications inside the cluster to use a stable Kubernetes service name while the underlying external hostname can change, and it requires no proxying by kube-proxy.

   Why the other options are wrong

   • BIt bypasses kube-proxy for external traffic is a partial truth but not the purpose. ExternalName services indeed do not use kube-proxy for proxying, but the defining purpose is the DNS CNAME mapping to an external hostname, not bypassing kube-proxy as a goal.
   • CIt creates an external IP address for the service describes the LoadBalancer service type. ExternalName does not allocate any IP address; it only provides a DNS alias.
   • DIt exposes a service on each node external IP describes the NodePort service type. ExternalName services are purely DNS-based and do not bind to any node port or IP.
5. Question 5Services and Networking

   Which command shows detailed information about a service including its endpoints, selector, and events?

   • Akubectl describe svc frontendCorrect
   • Bkubectl get svc frontend --show-details
   • Ckubectl get svc frontend -o wide
   • Dkubectl inspect service frontend
   ✓ Correct answer: A

   kubectl describe svc frontend is the correct command because it retrieves a human-readable summary of a Service object that includes its selector labels, type, ClusterIP, ports, Endpoints (the pod IPs backing the service), and the recent event log. This is the primary troubleshooting command for understanding how a Service is configured and whether it has healthy endpoints.

   Why the other options are wrong

   • Bkubectl get svc frontend --show-details is not a valid kubectl flag; --show-details does not exist, so this command would fail with an unknown flag error.
   • Ckubectl get svc frontend -o wide adds a few extra columns such as selector to the tabular output but does not display endpoints, events, or the full configuration detail that describe provides.
   • Dkubectl inspect service frontend is not a valid kubectl subcommand; no such command exists in the kubectl CLI.
6. Question 6Services and Networking

   Which command outputs the YAML of an existing service "redis-svc"?

   • Akubectl export svc redis-svc --format=yaml
   • Bkubectl get svc redis-svc -o yamlCorrect
   • Ckubectl describe svc redis-svc --output=yaml
   • Dkubectl show svc redis-svc -o yaml
   ✓ Correct answer: B

   kubectl get with the -o yaml output flag retrieves the full Kubernetes object from the API server and serializes it as YAML, including all spec fields, status, and metadata such as labels and annotations. This is the standard way to export or inspect a resource's complete definition and is commonly used before editing a resource or saving it to a file.

   Why the other options are wrong

   • Akubectl export svc redis-svc --format=yaml references the export subcommand which was deprecated and removed from kubectl in Kubernetes v1.18; it no longer exists.
   • Ckubectl describe svc redis-svc --output=yaml is incorrect because kubectl describe does not support -o yaml or --output=yaml; describe produces human-readable text output only and does not accept output format flags.
   • Dkubectl show svc redis-svc -o yaml uses a non-existent kubectl subcommand; show does not exist in kubectl.
7. Question 7Services and Networking

   Which field in a LoadBalancer service restricts source IPs that can access the load balancer?

   • Aspec.sourceIPWhitelist
   • Bspec.allowedSourceIPs
   • Cspec.firewall.sourceRanges
   • Dspec.loadBalancerSourceRangesCorrect
   ✓ Correct answer: D

   The spec.loadBalancerSourceRanges field on a LoadBalancer Service accepts a list of CIDR ranges. The cloud provider's load balancer implementation uses this list to configure firewall or security group rules, restricting inbound access to only the specified source IP ranges. Traffic from IPs outside those ranges is dropped at the load balancer level before reaching the cluster.

   Why the other options are wrong

   • Aspec.sourceIPWhitelist is not a valid Kubernetes Service field; no such field exists in the Service spec for restricting source IPs.
   • Bspec.allowedSourceIPs is not a recognized field in the Kubernetes Service API; the correct field name is spec.loadBalancerSourceRanges.
   • Cspec.firewall.sourceRanges is not a valid path in the Kubernetes Service spec; Kubernetes does not have a nested firewall object within the Service specification.
8. Question 8Services and Networking

   Two pods in different namespaces need to communicate. Pod A in "ns-a" needs to reach "svc-b" in "ns-b". A NetworkPolicy in ns-b allows ingress only from pods with label app=client. What must happen?

   • Apod A needs a ClusterRoleBinding granting it API access to resources in the ns-b namespace
   • Bpod A needs label app=client and the NetworkPolicy needs a namespaceSelector allowing ns-aCorrect
   • Cpod A needs a service account bound to a Role that permits calls into other namespaces
   • Dpod A needs an Ingress resource routing external HTTP traffic into svc-b within ns-b
   ✓ Correct answer: B

   For Pod A in namespace ns-a to reach svc-b in ns-b through a NetworkPolicy that restricts ingress, two conditions must be met simultaneously. First, Pod A must carry the label app=client so it matches the NetworkPolicy's podSelector. Second, because Pod A is in a different namespace, the NetworkPolicy's from rule must also include a namespaceSelector that matches namespace ns-a (for example, by a label on ns-a). Placing both selectors in the same from entry uses AND logic, meaning only pods with the correct label AND in the correct namespace are permitted.

   Why the other options are wrong

   • ARBAC ClusterRoleBindings control Kubernetes API access, not pod-to-pod network traffic governed by NetworkPolicy.
   • CService accounts and Roles authorize API operations, not data-plane traffic between pods across namespaces.
   • DIngress handles north-south external traffic into the cluster, not east-west pod-to-service calls between namespaces.

How Services and Networking is tested

This domain holds 168 of the 903 questions in the CKA bank, about 19%. The mix is 159 single-answer multiple choice and 9 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Services and Networking on its own rather than re-running full-length mocks.

Other CKA exam domains

• Cluster Architecture Installation and Configuration197 questions
• Workloads and Scheduling187 questions
• Storage168 questions
• Troubleshooting183 questions
• All CKA practice questions903 total
• Services and Networking study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Services and Networking FAQ