Services and Networking →mediumMultiple Select

CKAD Services and Networking Practice Question

Which TWO statements about Services are true? (Choose two.)

⚠ Common exam trap

The CKAD exam often tests the misconception that a LoadBalancer Service is a standalone type, when in fact it is built on top of NodePort and ClusterIP, and candidates may forget that ExternalName Services do not require selectors.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

A Service of type LoadBalancer automatically creates a NodePort Service.

When a Service of type LoadBalancer is created, Kubernetes automatically creates a corresponding NodePort Service (and a ClusterIP Service) as part of its implementation. The cloud load balancer routes external traffic to the NodePort on each node, which then forwards to the ClusterIP. This is defined in the Kubernetes Service specification and is a core behavior of the LoadBalancer type.

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 Service of type LoadBalancer automatically creates a NodePort Service.
Why this is correct
A Service of type LoadBalancer is an extension of NodePort: the cloud provider provisions a load balancer that targets the NodePort Service automatically created for that Service. Because NodePort exposes the Service on every node's IP and port, the external load balancer can route incoming traffic to any healthy node, which then forwards it through the ClusterIP to the selected pods. Thus, you only need to define a single LoadBalancer Service and Kubernetes creates the underlying NodePort and ClusterIP Services for you.
✗
A Service of type ClusterIP is accessible from outside the cluster.
Why it's wrong here
A ClusterIP Service gets a stable virtual IP from the cluster's service CIDR, and kube-proxy programs iptables or IPVS rules so that traffic to that IP is load-balanced to the Service's pods. This virtual IP is only routable inside the cluster's network namespace; it is never announced to external networks, so clients outside the cluster cannot reach it. To expose a ClusterIP Service externally, you must front it with a NodePort, LoadBalancer, or Ingress resource.
✗
A Service of type ExternalName requires a selector to route traffic.
Why it's wrong here
ExternalName is a special Service that returns a CNAME alias to an external DNS name instead of proxying to pods. It deliberately has no selector, and because the Service never creates Endpoints, a selector is not only unnecessary but also meaningless. When a client resolves the Service's DNS name, they get the external domain, so traffic bypasses kube-proxy entirely.
✗
A headless Service has clusterIP set to "0.0.0.0".
Why it's wrong here
A headless Service is configured by setting clusterIP to None, not to 0.0.0.0, because you are explicitly telling Kubernetes not to allocate a virtual IP. Without a clusterIP, the Service does not do load balancing; instead, the DNS A record query returns the IP addresses of the backing pods directly. This pattern is used for stateful applications that need stable network identities or direct pod-to-pod discovery.
✓
A Service of type NodePort exposes the Service on a static port on each Node's IP.
Why this is correct
A NodePort Service does exactly what its name says: it opens a static port (by default in the 30000–32767 range) on every node in the cluster. A request to any node's IP at that port is accepted and forwarded through the Service's ClusterIP to one of the selected pods. Because the node port is the same on all nodes, clients can use any node's IP to access the Service.

Go deeper

CKAD Services and Networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question