KCNA Container Orchestration Practice Question
A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?
⚠ Common exam trap
CNCF often tests the misconception that Ingress or Headless Services can handle session affinity by default, but only a Service with `sessionAffinity: ClientIP` provides this at the Kubernetes networking layer without additional configuration.
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 with sessionAffinity: ClientIP
Setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Headless Service
Why it's wrong here
A headless Service returns pod IPs directly via DNS rather than load-balancing, so the client picks a pod and no session affinity mechanism exists at the Service layer. It is tempting because headless Services suit StatefulSet discovery, but they provide no per-client routing persistence.
- ✓
Service with sessionAffinity: ClientIP
Why this is correct
Setting sessionAffinity: ClientIP on the Service makes kube-proxy route repeated requests from the same client IP to the same backend pod, satisfying the sticky session requirement across multiple replicas without an Ingress or external load balancer.
- ✗
Ingress with default settings
Why it's wrong here
Default Ingress rules route each request independently, with no session affinity, so successive requests from one client can land on different pods. It is tempting because Ingress is the natural place to expose HTTP services and does support cookie-based affinity, but only when that annotation is explicitly configured.
- ✗
Deployment with hostNetwork: true
Why it's wrong here
hostNetwork binds pods to node ports, giving no session affinity and causing port conflicts across replicas; requests still reach whichever pod the Service selects. It is tempting for low-latency or CNI-bypass scenarios, but it does not implement client-to-pod stickiness.
Go deeper
Related to this question
Learn chapter
Cloud Native Application Design Principles
Key term
Kubernetes API Primitives
Kubernetes API Primitives are the basic building blocks that the Kubernetes API uses to represent and manage the state of a cluster, such as Pods, Services, Deployments, and Namespaces.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.