Courseiva
Container OrchestrationhardMultiple ChoiceObjective-mapped

KCNA Container Orchestration Practice Question

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

⚠ Common exam trap

CNCF often tests the misconception that a Service of type NodePort is required for any DNS-based communication, but the trap here is that ClusterIP is the correct choice for internal cluster DNS stability, while NodePort is only needed for external access.

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

Service of type ClusterIP

A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • EndpointSlice

    Why it's wrong here

    EndpointSlice tracks which pods are endpoints of a Service, but does not provide a stable DNS name by itself.

  • Service of type NodePort

    Why it's wrong here

    NodePort exposes the service on a port on each node's IP, typically for external access, but it also provides internal DNS. However, ClusterIP is the standard for internal communication.

  • Ingress

    Why it's wrong here

    Ingress provides external HTTP/HTTPS routing, not internal DNS for pod-to-pod communication.

  • Service of type ClusterIP

    Why this is correct

    A ClusterIP Service provides a stable internal IP and DNS name for pod-to-pod communication within the cluster.

About these practice questions

This KCNA question is part of Courseiva's 833-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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way 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 have a microservices application deployed as a set of Pods in a Kubernetes cluster. You need to ensure that Pods can discover each other using stable DNS names. Which Kubernetes resource should you create?

medium
  • A.ConfigMap
  • B.Ingress
  • C.Service
  • D.Deployment

Why C: A Service of type ClusterIP (the default) provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that resolves to the Pods selected by its label selector. This allows Pods to discover each other using consistent DNS names, regardless of Pod IP changes due to scaling or restarts. The kube-dns or CoreDNS addon automatically creates DNS records for Services, enabling service discovery within the cluster.

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.