CKAD Services and Networking Practice Test 4 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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

Question 8

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 9

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. 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 10

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

Question 11

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

Accepted Answer

An Ingress resource. A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Answer

A second Service of type NodePort

Answer

A NetworkPolicy

Answer

A ConfigMap

Question 12

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

Accepted Answer

All three pod IPs as separate A records. A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Answer

The IP of the first pod only

Answer

The cluster IP of the Service

Answer

A round-robin list of pod IPs

Question 13

Which TWO statements about Kubernetes Services are correct? (Choose two.)

Accepted Answer

A Service provides a stable endpoint for a set of pods.. A Kubernetes Service provides a stable virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of pod IPs, ensuring reliable connectivity to the pod group.

Answer

Services can only route traffic based on named ports.

Answer

Services can only route traffic to pods in the same namespace.

Answer

Every Service must have a cluster IP assigned.

Question 14

Which THREE components are required for a basic Ingress to route HTTP traffic to a Service? (Choose three.)

Accepted Answer

A Service of type ClusterIP or NodePort. Option B is correct because an Ingress routes external HTTP traffic to a backing Service, which must exist as a ClusterIP or NodePort Service that selects the application's pods and exposes the target port. Option D is correct because the Ingress resource YAML defines the routing rules (host, path, and backend Service name/port) that the controller reads to configure HTTP routing. Option E is correct because an Ingress resource has no effect on its own; an Ingress controller such as nginx-ingress watches Ingress objects and programs the actual HTTP load balancer/proxy. Option A is not required because the Ingress only needs a Service with endpoints, and those endpoints can come from any workload controller or even manually managed pods, not specifically a Deployment. Option C is not required because NetworkPolicy is an optional security control; basic Ingress routing works without any NetworkPolicy as long as the controller can reach the Service endpoints.

Answer

A Deployment of the application

Answer

A NetworkPolicy allowing traffic from the Ingress controller

Question 15

Refer to the exhibit. A user has created the Service shown. The application pods listen on port 8080. Which port should an external client use to access the application from outside the cluster?

Accepted Answer

30007. The Service is of type NodePort, which exposes the application on a static port (30007) on each node's IP address. External clients can access the application by hitting any cluster node's IP on port 30007, which forwards traffic to the Service's ClusterIP on port 80, then to the pods on port 8080.

Answer

8080

Answer

80

Answer

30000