CKAD Services and Networking — Timed 15 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 and bypass the Pod network, so kube-proxy does not set up iptables rules for ClusterIP Services. However, a regular ClusterIP Service still creates stable DNS records (via CoreDNS) that resolve to the Service's virtual IP, which can then be used for stable DNS names even though direct ClusterIP connectivity is lost. This ensures that other components can discover the Pods via DNS without relying on Pod IPs that may change.

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

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

Accepted Answer

NodePort. NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 7

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 8

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. Option D is correct because 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 9

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 10

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 11

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. Option A is correct because 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

Question 12

Which TWO of the following are required for Ingress to route HTTP traffic to a backend Service?

Accepted Answer

An Ingress controller deployed in the cluster. An Ingress controller is required because the Ingress resource itself is just a set of routing rules; it does not process traffic. The Ingress controller, typically a pod running a reverse proxy like nginx or Envoy, watches the Ingress API and configures itself to route external HTTP/HTTPS traffic to the appropriate backend Services. Without a running Ingress controller, the Ingress resource has no effect.

Answer

Pod readiness probes

Answer

A Service of type LoadBalancer

Answer

A TLS certificate for HTTPS

Question 13

You are responsible for a multi-tier application running in a Kubernetes cluster. The frontend Pods communicate with backend Pods via a Service named 'backend' in the same namespace. Recently, the frontend team reported that the backend Service is intermittently unreachable. You inspect the backend Pods and notice that they are all running and ready, but the Endpoints object for the 'backend' Service shows only a subset of the Pod IPs. You also notice that the backend Pods have a readiness probe configured that checks an HTTP endpoint '/healthz'. The readiness probe has a periodSeconds of 5 and failureThreshold of 3. The application logs show occasional spikes in response time on the /healthz endpoint, sometimes exceeding 15 seconds. You need to resolve the intermittent unavailability without removing the readiness probe. Which action should you take?

Accepted Answer

Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness. Option D is correct because increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.

Answer

Remove the readiness probe configuration from the backend Pods

Answer

Add a second readiness probe on a different endpoint to increase redundancy

Answer

Change the Service type from ClusterIP to NodePort to bypass endpoint issues

Question 14

You have deployed a microservices application in a Kubernetes cluster. One of the services, 'payment-service', needs to be accessed by other services within the cluster via a stable DNS name. You create a Service of type ClusterIP named 'payment' with selector app=payment. However, when you try to curl http://payment from another Pod, the connection times out. You verify that the Pods backing 'payment-service' are running and ready, and the Endpoints object lists the correct Pod IPs. You also confirm that the Pods are listening on port 8080, and the Service defines targetPort: 8080. The cluster uses a standard CNI plugin (Calico) and DNS is provided by CoreDNS. What is the most likely cause of the timeout?

Accepted Answer

The Pods are listening on 127.0.0.1 only, not on 0.0.0.0. The most likely cause is that the Pods are listening only on 127.0.0.1 (localhost), which means they only accept connections from within the same Pod. When the Service sends traffic to the Pod via its cluster IP, the connection arrives on the Pod's network interface (e.g., eth0), not on loopback. Since the application is not bound to 0.0.0.0, it rejects or ignores the incoming packets, causing a timeout. This is a classic misconfiguration where the application's listen address is too restrictive.

Answer

The Service name 'payment' is not resolvable by DNS

Answer

The targetPort in the Service does not match the containerPort in the Pod spec

Answer

The Service type should be NodePort instead of ClusterIP

Question 15

A company runs a web application in a Kubernetes cluster. The application consists of a frontend service and a backend service. The frontend needs to communicate with the backend using a DNS name that does not change even if the backend pods are recreated. Which Kubernetes resource should the frontend use to reach the backend?

Accepted Answer

A regular ClusterIP Service. A regular ClusterIP Service provides a stable virtual IP and DNS name (e.g., ..svc.cluster.local) that remains constant regardless of pod churn. The frontend can use this DNS name to reach the backend, and the service load-balances traffic to the current set of backend pods via its label selector. This meets the requirement of a fixed DNS name that survives pod recreation.

Answer

An EndpointSlice

Answer

An Ingress resource

Answer

A headless Service