CKAD Services and Networking — 20 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

Accepted Answer

The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.. A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs. Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Answer

The Service and frontend are in different namespaces; the DNS name must be fully qualified.

Answer

The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.

Answer

The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.

Question 9

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 10

You have an Ingress resource that routes traffic to two services: 'app1' and 'app2'. The requirement is that traffic for 'app.example.com' goes to app1, and traffic for any other host goes to app2. Which Ingress specification correctly achieves this?

Accepted Answer

spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80. Ly uses a rule with `host: app.example.com` to route traffic to `app1`, and a separate rule without a host (which acts as a catch-all) to route all other traffic to `app2`. In Kubernetes Ingress, when no host is specified in a rule, it matches all hosts not matched by other rules, effectively serving as a default backend for host-based routing.

Answer

spec:
  rules:
  - host: "*"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80

Answer

spec:
  defaultBackend:
    service:
      name: app2
      port:
        number: 80
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80

Answer

spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80

Question 11

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: backend. It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Question 12

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

Accepted Answer

No pods match the Service's selector. The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object. This is the direct cause of the missing endpoints.

Answer

The Service is in a different namespace than the pods

Answer

The Service port is incorrect

Answer

The Service type is ExternalName

Question 13

Which command exposes a deployment named 'web' as a ClusterIP service on port 80?

Accepted Answer

kubectl expose deployment web --port=80. `kubectl expose deployment web --port=80` creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command automatically selects the deployment's pod labels and creates a service that maps port 80 to the target port (defaulting to the same port).

Answer

kubectl create service clusterip web --port=80

Answer

kubectl run web --expose --port=80

Answer

kubectl expose deployment web --port=80 --type=NodePort

Question 14

A developer creates a Service named 'backend' in namespace 'default'. The service targets pods with label 'app: backend'. From within a pod in the same namespace, which DNS name resolves to the service's ClusterIP?

Accepted Answer

backend. Kubernetes DNS resolves a Service name to its ClusterIP when queried from within the same namespace. The DNS record for a Service is simply `<service-name>` in the same namespace, so 'backend' resolves directly to the ClusterIP of the backend Service.

Answer

backend.default.svc.cluster.local

Answer

backend.svc.cluster.local

Answer

backend.default.cluster.local

Question 15

A NetworkPolicy allows ingress traffic from pods with label 'role: frontend' in the same namespace. Which podSelector is correct?

Accepted Answer

ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend. Option C is correct because it uses matchLabels, the simplest and preferred method to match exact label values, which directly mirrors the label query syntax used in other Kubernetes contexts. Option A, while valid, uses matchExpressions, which is more complex and not the typical first choice for simple equality matching. Option B matches on namespace labels, not pod labels, and Option D allows traffic from all IPs, which is not what the question asks.

Answer

ingress:
  - from:
    - podSelector:
        matchExpressions:
          - key: role
            operator: In
            values:
            - frontend

Answer

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: frontend

Answer

ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Question 16

A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?

Accepted Answer

To allow direct pod-to-pod DNS resolution for StatefulSets.. A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.

Answer

To provide a stable IP address for the service.

Answer

To expose the service externally without a load balancer.

Answer

To enable DNS round-robin across all pods.

Question 17

Which kubectl command creates a Service of type ClusterIP named 'my-service' that exposes port 80 on a set of pods selected by label 'app: web'?

Accepted Answer

kubectl expose deployment my-deployment --port=80 --target-port=80 --type=ClusterIP --name=my-service. `kubectl expose deployment my-deployment --port=80 --target-port=80 --type=ClusterIP --name=my-service` creates a ClusterIP Service that maps port 80 on the Service to port 80 on pods selected by the deployment's label selector (which includes `app: web`). The `--type=ClusterIP` is the default, but explicitly specifying it ensures the correct type, and the `--name` flag sets the Service name to 'my-service'.

Answer

kubectl run my-service --image=nginx --port=80 --expose

Answer

kubectl create service clusterip my-service --tcp=80:80

Answer

kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-service

Question 18

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

Accepted Answer

To provide stable network identities and DNS records for each pod in the StatefulSet. A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Answer

To prevent DNS resolution of the service

Answer

To enable TLS termination at the service level

Answer

To provide load balancing across the pods

Question 19

You create a Service named 'backend' in namespace 'prod'. A pod in namespace 'dev' tries to reach the service using the DNS name 'backend.prod.svc.cluster.local'. The pod cannot resolve the name. What is the most likely cause?

Accepted Answer

The pod is using the short name 'backend' without the namespace suffix. The pod in the 'dev' namespace is using the short DNS name 'backend' without the namespace suffix. In Kubernetes, DNS names are namespace-scoped: a pod can resolve a service in the same namespace using just the service name (e.g., 'backend'), but to reach a service in a different namespace, the full DNS name including the namespace and cluster domain is required (e.g., 'backend.prod.svc.cluster.local'). The pod's inability to resolve the name indicates it is likely using the short name, which only resolves within its own namespace.

Answer

CoreDNS is configured to reject cross-namespace queries

Answer

The 'prod' namespace does not exist

Answer

The cluster DNS service is not running

Question 20

You apply the following Ingress manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

Accepted Answer

The IngressClass 'nginx' is not installed or configured. The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Answer

The service 'api-service' is in a different namespace

Answer

The service port (80) does not match the container port

Answer

The path '/api' should be pathType: Exact