KCNA Cloud Native Architecture Practice Question
Which THREE of the following are benefits of using a service mesh in a cloud native architecture?
⚠ Common exam trap
KCNA often tests the core responsibilities of a service mesh; candidates may confuse it with other cloud native tools like container registries or state management solutions, leading them to select options that are not service mesh benefits.
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
✓
Traffic management capabilities like canary deployments
Option B is correct because a service mesh provides layer-7 traffic management (e.g., weighted routing, header-based routing) that enables canary deployments and blue/green releases without changing application code. Option D is correct because service meshes like Istio and Linkerd automatically provision and rotate mutual TLS (mTLS) certificates between sidecar proxies, giving strong service-to-service authentication and encryption. Option E is correct because sidecar proxies emit uniform telemetry—request metrics, distributed traces, and access logs—across all services, improving observability without per-service instrumentation. Option A is not a service mesh benefit: application state management is handled by databases, caches, or stateful orchestration, not by the mesh's data plane. Option C is also incorrect because the mesh adds sidecar proxies and control-plane components, which tend to increase rather than reduce container image sizes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Management of application state across services
Why it's wrong here
Service meshes handle service-to-service traffic, mTLS, retries and observability; they do not manage application state across services. It is tempting because meshes coordinate distributed services, but state management belongs to datastores or stateful platforms, not the mesh.
- ✓
Traffic management capabilities like canary deployments
Why this is correct
A service mesh provides layer 7 traffic management through sidecar proxies, enabling fine-grained routing rules that split traffic between service versions. This directly supports canary deployments, where a small percentage of requests route to a new version before full rollout, satisfying the stem's requirement for progressive delivery without changing application code.
- ✗
Reduction of container image sizes
Why it's wrong here
A service mesh adds sidecar proxies to pods, increasing rather than reducing image size. It is tempting because meshes do streamline operational concerns like traffic and security, but image size is determined by the application image, not by the mesh layer.
- ✓
Improved security through mutual TLS encryption
Why this is correct
Mutual TLS encrypts all pod-to-pod traffic and authenticates both endpoints via certificates, satisfying the stem's security benefit. Unlike network policies, which only filter traffic, mTLS provides encryption and identity verification between workloads, delivering zero-trust communication without application code changes.
- ✓
Enhanced observability with metrics and tracing
Why this is correct
Sidecar proxies emit uniform request metrics and distributed traces for every service without application code changes, satisfying the stem's observability benefit. This uniform telemetry across heterogeneous workloads is the mechanism a service mesh adds beyond per-service instrumentation.
Go deeper
Related to this question
Learn chapter
Cloud Native Architecture and Concepts
Key term
Microservices Architecture
Microservices architecture is a way of building software as a collection of small, independent services that each handle one specific business function and communicate over a network.
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
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 →
Same concept, more angles
4 more ways this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are benefits of using a service mesh? (Choose two.)
medium- ✓ A.Improved observability of service-to-service communication
- B.Direct management of virtual machines
- C.Automated container image building
- D.Replacing the need for a container runtime
- ✓ E.Traffic management capabilities such as canary deployments
Why A: Service mesh provides improved observability and enables traffic management features like canary deployments.
Variation 2. Which TWO are benefits of using a service mesh? (Choose two.)
medium- ✓ A.Observability of service-to-service communication
- B.Automatic database scaling
- ✓ C.Traffic management (e.g., canary deployments)
- D.Container image building
- E.Load balancing of external requests
Why A: Option A is correct because a service mesh like Istio or Linkerd provides observability of service-to-service communication by deploying sidecar proxies (e.g., Envoy) alongside each workload, which capture metrics, distributed traces, and logs for every request without requiring application code changes. Option C is correct because a service mesh enables traffic management capabilities such as canary deployments, blue-green releases, traffic splitting, retries, and circuit breaking through its control plane and proxy configuration (e.g., Istio VirtualService and DestinationRule resources). Option B is not a service mesh benefit because automatic database scaling is a database platform feature (e.g., Aurora Auto Scaling or DynamoDB on-demand), not something a service mesh provides. Option D is incorrect because container image building is handled by CI/CD tooling such as Docker, Buildah, or Kaniko, not by a service mesh. Option E is incorrect because load balancing of external requests is typically performed by an ingress controller, API gateway, or cloud load balancer, whereas a service mesh primarily handles east-west traffic between internal services.
Variation 3. Which THREE are key benefits of using a service mesh in a cloud-native architecture? (Choose 3)
medium- A.Persistent storage management for stateful applications.
- ✓ B.Mutual TLS (mTLS) encryption between services.
- C.Automatic horizontal scaling of pods.
- ✓ D.Observability through distributed tracing and metrics.
- ✓ E.Traffic management such as canary deployments and circuit breaking.
Why B: Option B is correct because a service mesh like Istio or Linkerd transparently provisions mutual TLS (mTLS) between sidecar proxies, giving every service-to-service call strong identity-based encryption and authentication without application code changes. Option D is correct because service meshes emit uniform telemetry from their sidecars — distributed traces (e.g., via Envoy and Zipkin/Jaeger), request metrics (latency, error rates, throughput), and access logs — providing consistent observability across heterogeneous services. Option E is correct because the mesh's control plane configures traffic routing rules that enable canary releases, blue/green rollouts, retries, timeouts, and circuit breaking at the proxy layer. Option A is not a service mesh benefit; persistent storage for stateful workloads is handled by CSI drivers, PersistentVolumes, and StatefulSets, not by the mesh data plane. Option C is also not a mesh function; automatic horizontal pod scaling is performed by the Kubernetes Horizontal Pod Autoscaler (HPA) based on metrics, independent of the service mesh.
Variation 4. Which THREE of the following are benefits of using a service mesh? (Select three.)
hard- A.Automatic scaling of pods
- B.Increased application performance
- ✓ C.Fine-grained traffic control (e.g., canary deployments)
- ✓ D.Improved observability through metrics and tracing
- ✓ E.Simplified service-to-service security with mutual TLS
Why C: A service mesh, such as Istio or Linkerd, provides fine-grained traffic control through features like traffic splitting, header-based routing, and weighted load balancing. This enables canary deployments by directing a small percentage of traffic to a new version of a service, allowing safe testing in production without affecting all users.
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.