CKAD Services and Networking Practice Question
Which of the following is true about Istio as a service mesh?
⚠ Common exam trap
A common mix-up: candidates confuse Istio's sidecar proxy with kube-proxy, assuming it replaces the default service routing mechanism, when in fact they operate at different layers and can coexist.
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
✓
It injects a sidecar proxy into each pod
Istio is a service mesh that deploys an Envoy sidecar proxy alongside each application pod. This sidecar intercepts all inbound and outbound traffic, enabling advanced traffic management, observability, and security features without modifying application code. The sidecar injection is typically done automatically via a mutating webhook admission controller.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It replaces kube-proxy for service routing
Why it's wrong here
Istio does not replace kube-proxy; both run concurrently in a cluster. kube-proxy continues to implement Service ClusterIP routing through iptables or IPVS rules, while Istio's Envoy sidecars handle pod-level traffic interception and L7 features. The sidecars effectively override kube-proxy for inter-pod communication by resolving endpoints directly, but kube-proxy remains essential for non-mesh traffic and external connections. Thus, the claim of replacement is inaccurate—it is a complementary data-plane enhancement.
- ✓
It injects a sidecar proxy into each pod
Why this is correct
This is correct: Istio's core mechanism is injecting an Envoy proxy sidecar into each application pod, typically via an admission webhook that mutates the Pod spec at creation time. This sidecar intercepts all inbound and outbound traffic using iptables rules, enabling L7 routing, mutual TLS, traffic policies, and telemetry without modifying the application code. Automatic sidecar injection is the default in modern Istio installations, and manual injection via istioctl is also supported for fine-grained control.
- ✗
It only works with HTTP traffic
Why it's wrong here
Istio is not restricted to HTTP traffic. Envoy is a general-purpose L4/L7 proxy, and Istio supports plain TCP, gRPC, HTTP/1.x, and HTTP/2 protocols. For raw TCP services, you can define DestinationRules with load-balancing settings and apply mTLS, while gRPC works natively over HTTP/2 with full traffic-management capabilities. The misconception stems from Istio's web UI and example apps, but production deployments commonly include database protocols and other non-HTTP workloads.
- ✗
It requires all services to be of type LoadBalancer
Why it's wrong here
Istio imposes no requirement that mesh services use the LoadBalancer type. In fact, the sidecar proxies communicate directly with pod IPs, bypassing the Service VIP entirely; using a ClusterIP service is sufficient and typical. The Service type is relevant only for exposing workloads to external clients, and the Istio ingress gateway—often a LoadBalancer—handles that edge in a mesh deployment. Internal services can even be headless, as Envoy resolves endpoints directly through the Kubernetes API.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 CKAD 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 CKAD exam.