CKAD Services and Networking — 20 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

Question 11

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 12

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), so 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, the kernel rejects the SYN with a TCP RST, and the client typically sees 'connection refused'. (A timeout could occur if a network policy is silently dropping packets, but the localhost bind is the most common and direct issue.)

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 13

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 14

A DevOps engineer notices that traffic to a Service named 'api' is not being forwarded to newly created pods. The Service selects pods with label 'app: api'. The pods are running and have the correct label. However, the Service's endpoints list does not include the new pods. What is the most likely cause?

Accepted Answer

The Service's targetPort does not match the container's port. The Service's `targetPort` must match the `containerPort` defined in the pod's container spec. If they differ, the Service will not route traffic to the pod, and the pod will not appear in the Endpoints object, even if the label selector matches. Kubernetes validates the endpoint population by checking that the pod's readiness probe passes and that the target port is reachable on the pod's IP.

Answer

The pods are in a different namespace

Answer

The Service type is NodePort instead of ClusterIP

Answer

The pods have a different label than 'app: api'

Question 15

During a security audit, it is discovered that a pod running a database is accessible from any other pod in the cluster. The database should only be accessible by pods with label 'role: backend'. Which resource should be applied to enforce this restriction?

Accepted Answer

A NetworkPolicy with an ingress rule selecting pods with label 'role: backend'. A NetworkPolicy with an ingress rule that selects pods with label 'role: backend' explicitly restricts inbound traffic to the database pod to only those pods that match that label. NetworkPolicies are Kubernetes-native resources that enforce firewall rules at the IP address or port level (OSI layer 3 or 4) using the pod's labels as selectors, and they are the standard mechanism for controlling pod-to-pod traffic within a cluster.

Answer

An Ingress resource with TLS

Answer

A Service of type ClusterIP with a firewall rule

Answer

A PodSecurityPolicy

Question 16

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 17

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. A Service of type ClusterIP or NodePort is required because the Ingress resource routes external HTTP traffic to a Service, which then forwards it to the Pods. ClusterIP is the default and most common type for internal cluster routing, while NodePort can also be used but is less typical. Without a Service, the Ingress has no endpoint to direct traffic to.

Answer

A Deployment of the application

Answer

A NetworkPolicy allowing traffic from the Ingress controller

Question 18

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

Question 19

A developer deploys a web application as a Deployment named 'web-app' with 3 replicas. The application listens on port 8080 and should be accessible from within the cluster via the service name 'web-svc' on port 80. Which Service YAML correctly exposes the application?

Accepted Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: web-app. Option A is correct because it defines a ClusterIP Service that maps port 80 to targetPort 8080 and uses the selector `app: web-app` to match the Pods. Option D is incorrect because it uses the selector `name: web-app`, which does not match the Pods labeled with `app: web-app`. Option B is incorrect because it adds `type: NodePort`, which is unnecessary for internal cluster access and may expose the service externally. Option C incorrectly swaps `port` and `targetPort`, sending traffic to the wrong container port.

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: web-app

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 8080
    targetPort: 80
  selector:
    app: web-app

Answer

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: web-app

Question 20

A DevOps engineer is setting up network policies in a Kubernetes cluster. The goal is to allow traffic from pods with label 'role=frontend' to pods with label 'role=backend' on TCP port 8080, and deny all other ingress to backend pods. Which two components are necessary to implement this? (Choose two.)

Accepted Answer

A NetworkPolicy with an ingress rule selecting pods with role=backend. A NetworkPolicy with an ingress rule selecting pods with label 'role=backend' defines the target pods for the policy. This is the foundational component that scopes the policy to backend pods, allowing you to then specify which sources (frontend pods) and ports (TCP 8080) are permitted.

Answer

A Service of type LoadBalancer to expose backend pods

Answer

A pod anti-affinity rule to ensure frontend pods are not scheduled on the same nodes as backend pods

Answer

A CNI plugin that supports NetworkPolicy enforcement, such as Calico