CKA Services and Networking Practice Question
Which two of the following are valid methods for service discovery in Kubernetes?
⚠ Common exam trap
It's easy for candidates to confuse external traffic management tools (Ingress) or third-party service meshes (Consul) with Kubernetes' native service discovery mechanisms, or mistake kubectl proxy (a debugging tool) for an in-cluster discovery method.
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
✓
Environment variables injected into pods
Option D is correct because Kubernetes automatically injects environment variables (e.g., <SVCNAME>_SERVICE_HOST and <SVCNAME>_SERVICE_PORT) into containers for each active Service, allowing pods to discover service endpoints without an external mechanism. Option E is correct because CoreDNS runs as the cluster DNS add-on and resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) to ClusterIPs, which is the standard in-cluster service discovery method. Option A is incorrect because an Ingress controller only routes external HTTP/HTTPS traffic to Services; it is not a service discovery mechanism. Option B is incorrect because Consul is a third-party tool, not a built-in Kubernetes service discovery method, and running a Consul agent per node is an external integration rather than a native Kubernetes mechanism. Option C is incorrect because kubectl proxy only creates a local proxy to the Kubernetes API server for accessing the API, not for discovering Services.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Ingress controller
Why it's wrong here
An Ingress controller is a reverse proxy that routes external HTTP/S traffic into the cluster based on hostname and path rules; it does not provide internal name resolution for pods. Service discovery requires resolving service names from inside the cluster, whereas Ingress is an edge routing layer. Therefore, it is not a valid built-in method for service discovery.
- ✗
Consul agent running on each node
Why it's wrong here
Consul is an external service mesh and discovery tool that can be installed on nodes to provide key-value discovery and health checking, but it is not a native or automatically integrated Kubernetes mechanism. Unlike CoreDNS or injectable environment variables, Consul requires separate agents, ACLs, and configuration, and it does not inherently replace kube-dns or the default service discovery behavior. Thus it is not a valid built-in method for service discovery in Kubernetes.
- ✗
kubectl proxy
Why it's wrong here
kubectl proxy is a developer convenience that creates an HTTP proxy between a local machine and the Kubernetes API server, allowing access to REST API endpoints like /api/v1/namespaces. It does not give application pods a way to resolve service names or discover endpoints, and it does not operate inside the cluster's network for normal pod-to-pod communication. It is simply an API gateway for administrative or debugging purposes, not a service discovery mechanism.
- ✓
Environment variables injected into pods
Why this is correct
When a pod starts, the kubelet injects environment variables for every Service that already exists in the pod's namespace, such as MY_SERVICE_SERVICE_HOST and MY_SERVICE_SERVICE_PORT, using the service's cluster IP and port values. Because these variables are set only at container creation time, they become stale if services are created or removed later, and they are namespace-scoped. This is a valid built-in discovery method but less dynamic than DNS.
- ✓
DNS resolution via CoreDNS
Why this is correct
CoreDNS is the default cluster DNS service, deployed as a set of pods with a ClusterIP known as kube-dns, and it watches Kubernetes Services and Endpoints to generate DNS records. Each service gets an A record in the form service.namespace.svc.cluster.local, and SRV records for named ports, so applications can use standard DNS resolution for discovery. It is the preferred and most flexible method because it updates dynamically as services are added, removed, or changed.
Visual reference
Go deeper
Related to this question
Learn chapter
Services and Networking Fundamentals
Key term
Kubernetes Services
A Kubernetes Service is a stable network endpoint that connects a set of pods to internal or external traffic, providing consistent access even as pods change.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.