Services and Networking →mediumMultiple Choice

CKAD Services and Networking Practice Question

A developer runs 'kubectl run nginx --image=nginx --port=80' and then creates a Service with the following YAML:

apiVersion: v1 kind: Service metadata: name: nginx-svc spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80

However, the Service has no endpoints. What is the most likely cause?

⚠ Common exam trap

Candidates often assume `kubectl run` creates a pod with an `app` label or that the `--port` flag affects the pod's labels, when in fact it only sets the container port and the default label is `run: <name>`.

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

✓

The Service selector 'app: nginx' does not match the pod's label 'run: nginx'

The `kubectl run nginx --image=nginx --port=80` command creates a pod with a default label `run: nginx`, not `app: nginx`. The Service's selector `app: nginx` therefore does not match any pod's labels, so the Service's endpoint controller finds no pods to add to the endpoints list. Without matching labels, the Service cannot route traffic to any pod, resulting in zero endpoints.

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 Service selector 'app: nginx' does not match the pod's label 'run: nginx'
Why this is correct
The pod created by `kubectl run nginx --image=nginx --port=80` is automatically labeled with `run: nginx`, not `app: nginx`. A Service selects backend pods by evaluating its `spec.selector` against the pod's labels; here the Service's selector `app: nginx` matches no pod, so the Service has no endpoints and will not route traffic to the pod. To fix this, either change the Service selector to `run: nginx` or relabel the pod with `app: nginx`, ensuring the selector matches the pod's existing labels.
✗
The Service and pod are in different namespaces
Why it's wrong here
Both the Service and the pod are created in the `default` namespace because `kubectl run` and the Service definition (unless a namespace is explicitly specified) target the current context's namespace, which is `default`. Kubernetes Service discovery using a Service name only works within the same namespace unless a fully qualified DNS name like `service-name.namespace.svc.cluster.local` is used. Therefore, a namespace mismatch is not the cause of the missing endpoints; the problem lies entirely in the selector-label mismatch.
✗
The Service must have a selector defined in order to have endpoints
Why it's wrong here
A Service without a selector is valid in Kubernetes; it simply does not automatically discover endpoints. Instead, an Endpoints object (or an EndpointSlice) can be manually created to point the Service to a specific IP address and port, allowing traffic to be routed to external or non-standard backends. Therefore, the absence of a selector does not inherently prevent the Service from having endpoints; the real issue is that the selector exists but selects the wrong labels, so no endpoints are generated.
✗
The pod is not listening on port 80
Why it's wrong here
The nginx container image listens on TCP port 80 by default, which matches the `port: 80` specified in the Service definition. The Service's `targetPort` (defaulting to the same value as `port`) directs traffic to the container's port 80; the pod does not need to expose the port via a containerPort field for the Service to route to it. Since nginx is listening on port 80, the pod's listening port is not the reason for the Service's failure to have endpoints.

Go deeper

CKAD Services and Networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question