KCNA Cloud Native Architecture Practice Question
A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?
⚠ Common exam trap
CNCF often tests the misconception that mTLS encryption is a major source of latency, but in practice its overhead is negligible compared to misconfigured proxy settings that directly impact request handling.
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
✓
Misconfigured sidecar proxy settings
In Istio, the sidecar proxy (Envoy) intercepts all inbound and outbound traffic for the application container. Misconfigured proxy settings—such as incorrect timeouts, retry policies, or circuit breaker thresholds—can introduce significant latency by causing unnecessary retries, connection delays, or queueing. This is the most common and immediate cause of increased latency in a service mesh, as the data plane is directly in the request path.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Kubernetes Network Policies blocking traffic
Why it's wrong here
Network Policies block or permit packets, producing connection failures and timeouts rather than the gradual latency increase described; they are the correct focus when services cannot reach each other at all. Latency with successful responses points to proxy processing instead.
- ✓
Misconfigured sidecar proxy settings
Why this is correct
Each Istio sidecar proxies every inbound and outbound request, so an incorrect proxy setting—such as a misconfigured concurrency limit, buffer size or timeout—directly adds per-hop latency to inter-service calls. Inspecting sidecar configuration and Envoy stats isolates this overhead before blaming the application or network.
- ✗
Application code is not optimized for the mesh
Why it's wrong here
Istio's sidecar proxies intercept traffic transparently, so application code needs no mesh-specific optimisation; unoptimised code adds latency equally without a mesh. Code profiling is the right investigation when latency traces to inefficient queries or algorithms rather than the service mesh layer.
- ✗
mTLS encryption overhead
Why it's wrong here
mTLS handshakes occur once per connection and are amortised across keep-alive sessions, so they do not explain sustained inter-service latency; encryption overhead is the right suspect when connections are short-lived and renegotiated constantly. Persistent latency instead implicates per-request proxy processing.
Go deeper
Related to this question
Learn chapter
Cloud Native Application Design Principles
Key term
Service Mesh
A service mesh is a dedicated infrastructure layer that manages communication between microservices, handling tasks like service discovery, load balancing, encryption, and observability without requiring changes to application code.
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 →
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.