CKAD Services and Networking — 10 Questions

Question 1

A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?

Accepted Answer

Service of type ClusterIP. A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.

Answer

Service of type NodePort

Answer

Service of type LoadBalancer

Answer

Ingress resource

Question 2

A team uses a Service named 'backend' in namespace 'prod' to reach Pods in namespace 'staging'. The Service in 'prod' has no endpoints. What is the most likely cause?

Accepted Answer

The Service selector does not match any Pods in the same namespace. The Service in the 'prod' namespace has no endpoints because its selector does not match any Pods in the same namespace. Kubernetes Services only discover Pods within the same namespace via label selectors; cross-namespace access requires a different approach (e.g., ExternalName Service or manual endpoint configuration). Since the Pods are in 'staging', the selector in 'prod' finds no matching Pods, resulting in zero endpoints.

Answer

The Service port name does not match the container port

Answer

The Service type is ClusterIP but should be NodePort

Answer

DNS resolution is broken in the staging namespace

Question 3

An application requires Pods to communicate using hostNetwork: true. Which Kubernetes resource is still necessary for stable DNS names?

Accepted Answer

Regular Service (ClusterIP). When Pods use hostNetwork: true, they share the node's network namespace, so their endpoint IP is the node IP. A regular ClusterIP Service still creates stable DNS records (via CoreDNS) that resolve to the Service's virtual IP. kube-proxy will still set up iptables rules to forward traffic from the ClusterIP to the endpoint (node IP), so ClusterIP connectivity is not lost. A Service object is still necessary for stable DNS names. Note: A headless Service also provides a stable DNS name, but it resolves to the individual pod/node IPs instead of a single virtual IP.

Answer

Headless Service

Answer

Endpoints resource

Answer

Ingress

Question 4

A Pod needs to access an external database at db.example.com:3306. Which Service type allows Pods to resolve a cluster-local name to this external address?

Accepted Answer

ExternalName. The ExternalName Service type maps a cluster-local DNS name (e.g., `my-db.default.svc.cluster.local`) to an external DNS name (`db.example.com`) using a CNAME record. This allows Pods to resolve the service name to the external database address without needing to modify application code or use an external endpoint.

Answer

LoadBalancer

Answer

NodePort

Answer

ClusterIP

Question 5

A Service of type LoadBalancer is created but the external IP remains <pending>. What is the most likely reason?

Accepted Answer

The cluster does not have a cloud provider configured. A LoadBalancer Service in Kubernetes relies on an external cloud provider (e.g., AWS, GCP, Azure) to provision a real load balancer and assign its external IP. If no cloud provider is configured (e.g., in a bare-metal or Minikube cluster), the external IP will remain <pending> indefinitely because there is no controller to allocate the IP.

Answer

The Service port is already in use

Answer

The Service selector does not match any Pods

Answer

The Pods are not listening on the container port

Question 6

An Ingress resource routes traffic to a Service 'web' on port 80. The Service has multiple endpoints but all return 503. What should be checked first?

Accepted Answer

Check the readiness probe of the Pods. A 503 Service Unavailable error from the Ingress indicates the upstream Service is not ready to serve traffic. The most common cause is Pods failing their readiness probes, which removes them from the Service's endpoint list. Checking the readiness probe status directly addresses why the Service has endpoints but returns 503.

Answer

Ensure that the Service type is ClusterIP

Answer

Verify that the Service port matches the Pod's container port

Answer

Check the Ingress controller logs

Question 7

A Pod needs to communicate with another Pod in the same cluster but in a different namespace. What is the correct DNS name to use?

Accepted Answer

..svc.cluster.local. Kubernetes DNS resolves services across namespaces using the format `..svc.cluster.local`. When a Pod in one namespace needs to communicate with a service in another namespace, the fully qualified domain name (FQDN) must include the namespace to disambiguate the service. This is defined by the Kubernetes DNS specification, which appends `svc.cluster.local` as the cluster domain suffix.

Answer

..svc.cluster.local

Answer

..pod.cluster.local

Answer

<service>.svc.cluster.local

Question 8

A Service uses a selector to target Pods. After updating the Pod labels, you notice the endpoints list is empty. What is the most likely reason?

Accepted Answer

The new labels do not match the Service selector. A Service uses a label selector to dynamically discover Pods and populate its endpoints. When Pod labels are updated, the selector remains unchanged; if the new labels do not match the selector, the Service cannot find any matching Pods, resulting in an empty endpoints list. This is the most direct and common cause of the issue.

Answer

The Service port was changed

Answer

The Service type changed to ExternalName

Answer

The Pods have a different container port

Question 9

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster?

Accepted Answer

Service type LoadBalancer. Service type LoadBalancer (C) exposes the Service externally by provisioning a cloud load balancer (e.g., AWS ELB, GCP L7) that routes external traffic to the Service's ClusterIP. Service type NodePort (D) exposes the Service on a static port (30000-32767) on every node's IP, allowing external access via :. Both are valid methods for external exposure in Kubernetes.

Answer

Service type ClusterIP

Answer

Service type ExternalName

Answer

Ingress resource with ClusterIP Service

Question 10

Which THREE of the following are valid use cases for a Headless Service (clusterIP: None)?

Accepted Answer

Discovering all Pod IPs via DNS A/AAAA records. A Headless Service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS queries return A/AAAA records containing the IP addresses of all healthy Pods selected by the service. This allows clients to discover and connect directly to individual Pod IPs, which is essential for stateful applications or custom discovery patterns.

Answer

Exposing the service externally via cloud load balancer

Answer

Providing a stable virtual IP for load balancing