Courseiva
Container Orchestration →easyMultiple Choice

KCNA Container Orchestration Practice Question

A team runs a stateless API as a Deployment with six replicas across three nodes. They need a stable virtual IP and DNS name that load-balances TCP traffic to the ready replicas from other Pods in the same cluster. Which resource should they create?

⚠ Common exam trap

The trap here is selecting NodePort or Ingress for internal-only TCP access, when a ClusterIP Service already provides a stable virtual IP and DNS name inside the cluster.

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 ClusterIP with a selector matching the Pod labels.

A ClusterIP Service is the native Kubernetes way to give a set of Pods a stable in-cluster virtual IP and DNS name, with kube-proxy load-balancing connections across ready endpoints. NodePort, Ingress, and NetworkPolicy serve different purposes: external node-level exposure, HTTP routing, and traffic filtering, respectively. For internal TCP load balancing to ready replicas, a ClusterIP Service with a matching selector is correct.

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 ClusterIP with a selector matching the Pod labels.

    Why this is correct

    A ClusterIP Service provides a stable virtual IP and DNS name inside the cluster and load-balances connections to Pods whose labels match the selector. It only includes endpoints that pass readiness checks, which fits the requirement for TCP access to ready replicas. This is the standard in-cluster exposure mechanism for a stateless API.

  • ✗

    A Service of type NodePort with externalTrafficPolicy: Local.

    Why it's wrong here

    NodePort exposes the Service on each node's IP at a static port, which is intended for external access rather than in-cluster access. externalTrafficPolicy: Local also restricts traffic to Pods on the receiving node, which can unbalance load. The scenario asks for a stable virtual IP and DNS name for other Pods, so a NodePort is unnecessary and adds external exposure.

  • ✗

    An Ingress resource with a path rule for /api.

    Why it's wrong here

    Ingress operates at the HTTP and HTTPS layer and requires an Ingress controller to be installed. It does not provide a stable virtual IP for arbitrary TCP traffic from other Pods, and it is not the right abstraction for in-cluster TCP load balancing. The team needs a Service, not an Ingress rule.

  • ✗

    A NetworkPolicy that allows ingress from the API namespace.

    Why it's wrong here

    A NetworkPolicy controls whether traffic is permitted to reach Pods, but it does not create a virtual IP, DNS name, or load-balancing endpoint. It can only restrict or allow traffic after a Service exists. Creating a NetworkPolicy alone would not give other Pods a stable address for the API.

Visual reference

Source Router + ACL permit 10.0.0.0/8 deny any Server 10.0.0.5 ✓ 192.168.1.1 ✗ dropped ACLs evaluate top-down; first match wins — implicit deny all at end

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 →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official CNCF exam blueprint

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.