KCNA Cloud Native Observability Practice Question
A site reliability engineer is investigating high latency in a microservices application. They have distributed traces but need to understand how a single trace spans multiple services and where time is spent. Which OpenTelemetry concept allows correlating spans across service boundaries into a single trace?
⚠ Common exam trap
The trap here is assuming that attaching trace IDs to metrics or adding resource attributes is enough to correlate spans, when only context propagation actually carries trace context between services.
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
✓
Context propagation
Context propagation carries trace and span identifiers across service calls, allowing spans from different services to be stitched into one distributed trace. Resource attributes describe the producer, span status indicates success or failure, and metric exemplars link metrics to traces, but none of these provide the cross-service linkage required. Therefore, context propagation is the concept that enables end-to-end trace correlation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Metric exemplars
Why it's wrong here
Metric exemplars attach trace IDs to metric samples, allowing you to jump from a metric to a related trace. They are helpful for linking metrics and traces but do not themselves propagate context across services or assemble a distributed trace. The core requirement is cross-service correlation of spans, which is handled by context propagation, not by exemplars.
- ✗
Resource attributes
Why it's wrong here
Resource attributes describe the entity producing telemetry, such as the service name, host, or container. They help identify where a span originated but do not link spans across services into one trace. While useful for filtering and grouping, they do not provide the cross-service correlation needed to assemble a complete distributed trace, so they do not solve the stated problem.
- ✗
Span status
Why it's wrong here
Span status indicates whether an operation completed successfully or with an error. It is useful for identifying failures but does not connect spans from different services. The engineer needs to correlate spans into a single trace to analyze latency across service boundaries, and span status alone cannot achieve that, making it an incorrect choice for this scenario.
- ✓
Context propagation
Why this is correct
Context propagation is the mechanism that passes trace context, including trace ID and span ID, across service boundaries via headers or other carriers. It enables spans created in different services to be linked into a single distributed trace. Without it, each service would create isolated traces, so this concept directly addresses the need to correlate spans across microservices and understand end-to-end latency.
Go deeper
Related to this question
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.