CKAD Services and Networking Practice Test 12 — 15 Questions

Question 1

Which TWO statements about Kubernetes DNS are correct?

Accepted Answer

A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'. Kubernetes DNS assigns a fully qualified domain name (FQDN) to services following the pattern `..svc.cluster.local`. For a service named 'api' in the 'prod' namespace, the DNS name is `api.prod.svc.cluster.local`, enabling cluster-internal service discovery via CoreDNS or kube-dns.

Answer

The kube-dns service is responsible for DNS resolution

Answer

Pods with hostNetwork: true automatically get DNS entries

Answer

A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

Question 2

Which THREE statements about NetworkPolicy are correct?

Accepted Answer

NetworkPolicy uses labels to select pods and namespaces. NetworkPolicy uses label selectors (podSelector and namespaceSelector) to determine which pods and namespaces the policy applies to. This allows fine-grained control over traffic flow based on Kubernetes labels, which is the standard mechanism for selecting resources in Kubernetes.

Answer

NetworkPolicy resources are cluster-scoped

Answer

ipBlock can only be used in ingress rules

Question 3

A pod named 'debug' is running. Which command forwards local port 4000 to port 80 on the pod?

Accepted Answer

kubectl port-forward pod/debug 4000:80. `kubectl port-forward pod/debug 4000:80` forwards traffic from localhost port 4000 to port 80 on the specified pod. The syntax `pod/debug` explicitly identifies the resource type and name, which is the standard and unambiguous way to reference a pod in kubectl commands.

Answer

kubectl exec debug -- socat TCP-LISTEN:4000 TCP:localhost:80

Answer

kubectl port-forward pod debug 4000:80

Answer

kubectl proxy --port=4000 --target=80

Question 4

A StatefulSet named 'mysql' is deployed with 3 replicas. The administrator wants each pod to have a stable network identity. Which service configuration is required?

Accepted Answer

A headless service with clusterIP: None and selector matching the StatefulSet. A headless service with `clusterIP: None` is required for a StatefulSet to provide stable network identities. Each pod in a StatefulSet gets a unique, predictable DNS name (e.g., `mysql-0.mysql.default.svc.cluster.local`) that persists across rescheduling. This is achieved by setting the service's `clusterIP` to `None`, which disables load balancing and returns DNS A/AAAA records for individual pod IPs instead of a single service IP.

Answer

A ClusterIP service named 'mysql'

Answer

A NodePort service named 'mysql'

Answer

An ExternalName service pointing to an external database

Question 5

Which TWO statements about Ingress are correct?

Accepted Answer

Ingress can route traffic based on the requested hostname. An Ingress resource can route traffic based on the requested hostname using the `spec.rules.host` field. This allows multiple hostnames (e.g., `app1.example.com` and `app2.example.com`) to be served by the same Ingress controller, with each hostname directing traffic to different backend services. This host-based routing is a core feature of the Ingress API, as defined in the Kubernetes networking specification.

Answer

An Ingress resource without an IngressClass will not work

Answer

Only one Ingress resource can exist per namespace

Answer

Ingress can handle non-HTTP protocols like TCP

Question 6

Which THREE are valid ways to expose a Service externally in Kubernetes?

Accepted Answer

Type: NodePort. (Type: NodePort) is correct because it exposes a Service on a static port on each Node's IP address, allowing external traffic to reach the Service by targeting :. Option C (Type: LoadBalancer) is correct because it provisions an external load balancer in cloud environments that directs traffic to the Service. Option D (Ingress resource) is correct because it provides HTTP/HTTPS routing to Services, often using a load balancer or other entry point. Option A (Headless service) is incorrect because it is used for service discovery without a cluster IP and does not provide external access. Option E (Type: ClusterIP) is incorrect because ClusterIP is internal-only and not exposed externally.

Answer

Headless service

Answer

Type: ClusterIP

Question 7

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 8

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 9

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 10

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 11

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 12

Which of the following Service types exposes a pod on a static port on each node's IP address?

Accepted Answer

NodePort. NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 13

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 14

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. `kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Answer

kubectl expose pod web-pod --port=8080 --target-port=80

Answer

kubectl proxy --port=8080 --target=pod/web-pod:80

Answer

kubectl exec web-pod -- curl http://localhost:8080

Question 15

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