KCNA Cloud Native Architecture Practice Question
Which TWO are benefits of using a service mesh in cloud-native applications?
⚠ Common exam trap
CNCF often tests the misconception that a service mesh reduces latency or replaces monitoring, when in fact it adds a small overhead and complements, rather than replaces, existing monitoring tools.
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
✓
Advanced traffic management capabilities
Option B is correct because a service mesh provides advanced traffic management capabilities such as fine-grained routing, canary releases, blue-green deployments, retries, timeouts, circuit breaking, and traffic splitting through sidecar proxies, which are core features of tools like Istio and Linkerd. Option D is correct because service meshes automatically provision and rotate mutual TLS (mTLS) certificates between services, providing identity-based authentication and encryption-in-transit without requiring application code changes. Option A is incorrect because a service mesh does not eliminate the need for application monitoring; it enhances observability with metrics, traces, and logs, but monitoring tools and practices are still required. Option C is incorrect because persistent storage management is handled by storage classes, CSI drivers, and persistent volume claims in Kubernetes, not by a service mesh. Option E is incorrect because service meshes typically add a sidecar proxy hop that can introduce slight latency overhead rather than reduce network latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Eliminates need for application monitoring
Why it's wrong here
A service mesh exports telemetry such as metrics, traces and logs, but applications still require their own monitoring and alerting; it complements rather than replaces it. It is tempting because meshes provide rich observability out of the box, yet they cannot eliminate the need for application-level monitoring.
- ✓
Advanced traffic management capabilities
Why this is correct
Service meshes provide layer-7 traffic control: weighted routing, canary releases, retries, circuit breaking and fault injection, all configured declaratively rather than coded into each service. This satisfies the stem's requirement for advanced traffic management beyond Kubernetes' basic layer-4 Service load balancing.
- ✗
Simplified persistent storage management
Why it's wrong here
Persistent storage is provisioned through CSI drivers and StorageClasses, not by a service mesh, which handles service-to-service traffic, mTLS and routing. It is tempting because meshes simplify several operational concerns, but storage lifecycle management sits outside their data-plane and control-plane scope entirely.
- ✓
Automatic mTLS encryption between services
Why this is correct
Sidecar proxies transparently negotiate mutual TLS for every service-to-service connection, issuing and rotating certificates without application code changes. This delivers automatic encryption and workload identity, unlike plain Kubernetes networking, which carries traffic unencrypted by default between pods.
- ✗
Reduced network latency
Why it's wrong here
Service mesh sidecar proxies add an extra network hop and per-request processing, typically increasing latency rather than reducing it. It is tempting because meshes optimise traffic routing and retries, which can improve reliability, but latency reduction is not a benefit they deliver; observability, mTLS and traffic control are.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
Learn chapter
Kubernetes API and Core Objects
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.
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
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.