CKAD Services and Networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The kube-dns service is responsible for DNS resolution

  Why it's wrong here

  The kube-dns service is not the component that performs DNS resolution; it is a ClusterIP service that points to the CoreDNS pods. CoreDNS is the actual DNS server that handles queries, while the kube-dns service exists for backward compatibility so that applications can resolve cluster-internal names. Saying the service itself is responsible conflates a stable network endpoint with the workload that implements the DNS feature.

• ✓

  A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'

  Why this is correct

  This is correct because Kubernetes constructs a service's fully qualified domain name using the pattern `<service-name>.<namespace>.svc.<cluster-domain>`. With the default cluster domain of `cluster.local`, a service named `api` in the `prod` namespace resolves to `api.prod.svc.cluster.local`. Other pods in the cluster can rely on this DNS name for service discovery, and the name is stable for the service's lifetime.

• ✗

  Pods with hostNetwork: true automatically get DNS entries

  Why it's wrong here

  Pods that run with `hostNetwork: true` share the node's network namespace and therefore do not receive a unique pod IP from the cluster CIDR. Because Kubernetes DNS does not have a pod IP to format into an A record, it does not automatically create a DNS entry for these pods. They can still use DNS as clients, but they are not discoverable via a pod-specific DNS name unless you manually assign a `hostname` and `subdomain` and attach them to a headless service.

• ✓

  Headless services also have DNS A records for each pod

  Why this is correct

  When a service is headless (`clusterIP: None`), it does not get a virtual ClusterIP; instead, DNS returns a set of A records—one for each ready pod backing the service. This allows clients to discover individual pod IPs directly, which is essential for stateful workloads like databases or any app that needs to connect to a specific replica. For a `StatefulSet` pod, the A record corresponds to its stable hostname, such as `pod-0.headless-svc.namespace.svc.cluster.local`.

• ✗

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

  Why it's wrong here

  Pod DNS records use the pod IP with dots replaced by dashes, for example `10-0-0-1.default.pod.cluster.local`, so the literal string `pod-ip` is never part of the name. These records are only created when the pod has a specified `hostname` and `subdomain` and belongs to a non-headless service; many pods do not have an A record at all. Therefore the statement's claim that the DNS name is 'always' this format is false, as most pods rely on service DNS names rather than their own.

Go deeper

Related to this question