KCNA Container Orchestration Practice Question
You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?
⚠ Common exam trap
A common mix-up: candidates think environment variables (Option D) are the primary Kubernetes-native method, but the exam emphasizes DNS as the modern, recommended approach, while environment variables are a legacy fallback with limitations.
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
✓
Use the Kubernetes DNS service to resolve the Service name 'service-b'
Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use the Kubernetes DNS service to resolve the Service name 'service-b'
Why this is correct
Kubernetes DNS resolves a Service name to its stable ClusterIP, letting Service A reach Service B without hard-coded pod IPs. This satisfies the requirement for a Kubernetes-native discovery mechanism, since DNS-based Service resolution is built into the cluster rather than added externally.
- ✗
Use an external service registry like Consul or etcd
Why it's wrong here
Consul or etcd adds an external control plane requiring its own deployment, health checks and credentials, duplicating functionality Kubernetes Services and CoreDNS already provide natively. Tempting because external registries suit multi-cluster or hybrid environments spanning non-Kubernetes workloads, but within one cluster they introduce unnecessary operational overhead.
- ✗
Hardcode the cluster IP of Service B in the configuration of Service A
Why it's wrong here
A cluster IP is assigned dynamically and can change when the Service is recreated, so hardcoding it breaks connectivity and bypasses load balancing across endpoints. Tempting because it appears to remove discovery entirely, but it is fragile; Kubernetes-native discovery relies on stable DNS names resolving to the Service, not fixed addresses.
- ✗
Use environment variables injected by the Kubernetes API into each pod
Why it's wrong here
Environment variables are injected only at pod start, so Service A cannot learn Service B's current IP after restarts or rescheduling without manual intervention. Tempting because Kubernetes does populate service-related variables automatically, but that mechanism is static and unsuitable for dynamic discovery, unlike DNS-based Service records.
Visual reference
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-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 →
Same concept, more angles
2 more ways this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?
medium- ✓ A.Kubernetes Service
- B.Horizontal Pod Autoscaler
- C.ConfigMap
- D.PersistentVolume
Why A: Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.
Variation 2. A microservices application has multiple services that need to discover each other by name. Which Kubernetes object provides built-in service discovery via DNS?
hard- A.Ingress
- B.Namespace
- C.ConfigMap
- ✓ D.Service
Why D: A Kubernetes Service object provides built-in service discovery via DNS. When a Service is created, the cluster's DNS (typically CoreDNS) automatically assigns it a DNS name in the format `<service>.<namespace>.svc.cluster.local`, allowing other microservices to resolve the Service by name without hardcoding IP addresses or using external service registries.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This KCNA 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 KCNA exam.