KCNA Cloud Native Architecture Practice Question
An architecture review is comparing the sidecar proxy model used by service meshes against embedding resilience logic directly in each application's code. Which TWO statements accurately describe advantages of the sidecar proxy approach? (Choose two.)
⚠ Common exam trap
The trap here is believing the sidecar removes network overhead or edits application code, when it actually adds a local hop and only manipulates traffic at runtime.
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
✓
Retries, timeouts, mutual TLS, and traffic telemetry are applied by the proxy, so application code does not need to implement them.
The sidecar pattern moves cross-cutting concerns out of application code and into a proxy that intercepts Pod traffic. That lets one team manage retries, timeouts, mutual TLS, and telemetry centrally and apply identical policy to services regardless of language, which is the main architectural advantage over per-language libraries. The pattern does not align proxy language with app language, does not remove a network hop, and does not rewrite source code.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Each sidecar can be written in the same language as its application so behaviour stays consistent across the fleet.
Why it's wrong here
Sidecars are infrastructure components deployed as separate containers and are almost always written in a language unrelated to the application, such as a shared proxy binary. Language alignment with the app is neither a property nor a benefit of the pattern, and it would not improve consistency. This statement describes a misconception about how sidecars are implemented.
- ✓
Retries, timeouts, mutual TLS, and traffic telemetry are applied by the proxy, so application code does not need to implement them.
Why this is correct
Because the sidecar intercepts all inbound and outbound traffic for the Pod, cross-cutting concerns such as retries, timeouts, mutual TLS, and request metrics are handled outside the process. Teams can change policy centrally without rebuilding or redeploying the application, which is the core operational benefit of the sidecar model and the reason it is attractive for polyglot microservice fleets.
- ✓
Security and traffic policy can be enforced consistently across services written in different languages and frameworks.
Why this is correct
Since policy is implemented by the proxy rather than by each application, a Java service, a Go service, and a Python service all receive the same authentication, authorization, and traffic rules. This uniformity is a major reason organizations adopt a service mesh, especially when they cannot modify or rebuild every application to add a language-specific library.
- ✗
Because the sidecar runs in a separate container, it eliminates the extra network hop and reduces request latency compared with in-process libraries.
Why it's wrong here
The sidecar model actually adds a hop: traffic is redirected through the local proxy before leaving the Pod, and the peer's proxy may intercept it again. This adds a small amount of latency and CPU overhead compared with an in-process library that makes a direct call. Claiming the sidecar removes the hop and lowers latency is the opposite of what happens.
- ✗
The sidecar automatically rewrites application source code so that existing services gain resilience features without developer effort.
Why it's wrong here
A sidecar never modifies source code. It operates on network traffic at runtime by intercepting connections, so the application binary is untouched. Some mesh implementations can inject the sidecar container into Pods automatically via an admission webhook, but that is workload injection, not source transformation, so this statement is factually wrong.
Go deeper
Related to this question
Learn chapter
Cluster Architecture and Lifecycle Management
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
Courseiva writes every KCNA question from scratch — 930 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 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.