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

• ✗

  A headless service assigns a ClusterIP to the service

  Why it's wrong here

  A headless service explicitly sets spec.clusterIP to None, which tells Kubernetes not to allocate a stable virtual IP from the service CIDR. Since no ClusterIP exists, the kube-proxy rules and ClusterIP-based service discovery are bypassed entirely, so the service cannot be reached via a single virtual IP. Instead, clients must rely on DNS-based pod resolution, making the statement that a ClusterIP is assigned factually incorrect.

• ✗

  Headless services provide round-robin load balancing across pods

  Why it's wrong here

  Round-robin load balancing is a kube-proxy behavior that applies only to services with a ClusterIP, where traffic is forwarded to a randomly or round-robin selected endpoint. A headless service has no ClusterIP and therefore has no kube-proxy virtual IP to load balance across; DNS returns each matching pod IP directly, and any client-side load balancing is left to the application or DNS resolver's own ordering. Thus the service itself does not provide round-robin load balancing across pods.

• ✗

  Headless services require a selector that matches at least one pod

  Why it's wrong here

  While many headless services do use a selector to build an Endpoints object, the selector is optional in Kubernetes. If a headless service omits the selector, it will not automatically populate endpoints; instead, you must manually create a corresponding Endpoints resource to map service DNS to specific IP addresses. Therefore, the requirement that a selector must match at least one pod is not true — a headless service can exist without any selector or with a selector that matches no pods initially.

• ✓

  DNS queries for a headless service return the IP addresses of the backing pods

  Why this is correct

  For a headless service with a selector, Kubernetes still creates an Endpoints object listing the IPs of all pods that match the selector, but it does not expose those IPs behind a ClusterIP. Instead, DNS A/AAAA records for the service name resolve directly to those individual pod IPs, so a query returns one or more pod addresses depending on how many endpoints exist. This is the core mechanism that enables stateful applications, such as databases, to discover and connect to specific pod instances rather than a load-balanced virtual IP.

• ✓

  A headless service is created by setting clusterIP to None

  Why this is correct

  A headless service is defined simply by setting the clusterIP field to None in the service spec, for example: clusterIP: None. This value tells the Kubernetes control plane to skip allocating a ClusterIP from the configured service CIDR and to skip creating the usual kube-proxy virtual IP, while still creating the service object and, if a selector is present, the corresponding Endpoints. This explicit setting is the standard and required way to create a headless service, and it is what distinguishes it from a normal ClusterIP, NodePort, or LoadBalancer service.

Go deeper

Related to this question