Cloud Native Architecture →hardMultiple Select

KCNA Cloud Native Architecture Practice Question

Which THREE of the following are features typically provided by a service mesh? (Choose three.)

⚠ Common exam trap

KCNA often tests the confusion between service mesh features and orchestration features, leading candidates to select auto-scaling or service discovery as mesh responsibilities.

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

✓

Observability through metrics and tracing

A service mesh like Istio or Linkerd provides observability by collecting metrics and distributed traces from the sidecar proxies (e.g., Envoy) that intercept service-to-service traffic, so option A is correct. It also delivers traffic management capabilities such as routing rules, retries, timeouts, circuit breaking, and canary or blue-green deployments, making option C correct. Additionally, a service mesh secures service-to-service communication with mutual TLS (mTLS), automatically issuing and rotating certificates and enforcing encryption and identity between workloads, so option D is correct. Option B is wrong because pod auto-scaling based on CPU is handled by the Kubernetes Horizontal Pod Autoscaler (HPA), not by a service mesh. Option E is wrong because service discovery is a core Kubernetes function (via kube-dns/CoreDNS and Services), not a feature typically attributed to the service mesh itself.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Observability through metrics and tracing
Why this is correct
Service meshes collect per-request telemetry from sidecar proxies, exposing golden signals such as latency, error rates and request volume, plus distributed traces across service hops. This satisfies the stem's observability feature, giving uniform metrics and tracing without instrumenting each application.
✗
Auto-scaling of pods based on CPU
Why it's wrong here
Auto-scaling pods on CPU is a Kubernetes Horizontal Pod Autoscaler function, not a service mesh feature; meshes manage traffic, not replica counts. It tempts because meshes expose request metrics, so it would be correct if the question asked what data a mesh supplies to an autoscaler.
✓
Traffic management between services
Why this is correct
Service meshes route requests between services through sidecar proxies, enabling load balancing, retries, timeouts, circuit breaking and canary or blue-green routing. This satisfies the stem's traffic management feature, controlling east-west service communication independently of application code.
✓
Security with mutual TLS (mTLS)
Why this is correct
Service meshes terminate and originate sidecar proxies, issuing workload identities so every service-to-service call is encrypted and mutually authenticated via mTLS, satisfying the stem's requirement for a security feature. This delivers zero-trust encryption and identity verification without application code changes.
✗
Service discovery
Why it's wrong here
Service discovery is provided by the platform or Kubernetes itself, not typically by a service mesh, which handles traffic between services. It tempts because meshes consume discovery data for routing, so it would be correct if the question asked which feature a mesh integrates with rather than provides.

Go deeper

KCNA Cloud Native Architecture Practice Question

Why each option matters

Option-by-option breakdown

Related to this question