KCNA Cloud Native Observability Practice Question
A company is running a microservices application on a Kubernetes cluster. They have noticed that one of the services, 'payment-api', is experiencing intermittent high latency. The team wants to identify the root cause without modifying the application code. Which approach should they take?
⚠ Common exam trap
CNCF often tests the distinction between observability tools that provide request-level context (distributed tracing) versus aggregate resource metrics (kube-state-metrics, Node Exporter) or unstructured logs, leading candidates to mistakenly choose CPU/memory correlation or log analysis for pinpointing intermittent latency in a microservices architecture.
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
✓
Implement distributed tracing using tools like Jaeger or Zipkin to trace requests across services.
Distributed tracing with tools like Jaeger or Zipkin allows you to follow a single request as it traverses multiple microservices, identifying exactly which service or call introduces latency. This approach does not require code changes (if the service mesh or sidecar proxy handles instrumentation) and is specifically designed to pinpoint performance bottlenecks in distributed systems, unlike CPU/memory metrics or log analysis which cannot trace a request's end-to-end 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.
- ✗
Monitor CPU and memory metrics from kube-state-metrics and correlate with latency.
Why it's wrong here
Resource metrics may not directly indicate request latency.
- ✗
Increase log verbosity for all services and search for error messages.
Why it's wrong here
Logs may not capture latency across services.
- ✓
Implement distributed tracing using tools like Jaeger or Zipkin to trace requests across services.
Why this is correct
Distributed tracing tracks request flow and identifies slow components.
- ✗
Check node-level metrics using Prometheus Node Exporter.
Why it's wrong here
Node metrics are too granular for service-level latency.
Go deeper
Related to this question
Learn chapter
Kubernetes Overview and Core Components
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.
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 — 833 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 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.