KCNA Cloud Native Observability Practice Question
A site reliability engineer is investigating high latency in a microservices application. They have distributed tracing enabled with OpenTelemetry and traces exported to a backend. They want to correlate a specific slow trace with the logs generated by the involved services. Which practice best enables this correlation?
⚠ Common exam trap
The trap here is thinking that increasing log detail or sampling rates enables correlation, when the essential requirement is propagating trace context into logs.
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
✓
Include the trace ID and span ID in the log entries of each service.
Correlating traces and logs requires a shared identifier. By injecting the trace ID and span ID into log records, each log line can be tied to the exact trace and span that produced it. This allows an engineer to take a slow trace, extract its trace ID, and query logs for that ID to see all related events across services. Other options do not provide this direct linkage.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable debug logging on all services and increase log verbosity.
Why it's wrong here
Increasing log verbosity may provide more detail but does not establish a link between logs and traces. Without trace context, correlating a specific trace to its logs remains manual and error-prone. Debug logging can also generate excessive noise and performance overhead, making it harder to isolate the relevant events for the slow trace.
- ✗
Configure the OpenTelemetry Collector to sample all traces at 100%.
Why it's wrong here
Sampling all traces ensures no trace is dropped, but it does not create a link between traces and logs. Even with complete trace data, without trace IDs in logs, the engineer cannot easily find the corresponding log entries. Sampling affects data volume and completeness, not correlation, so this is not the best practice for the stated goal.
- ✗
Use a separate logging backend that is different from the tracing backend.
Why it's wrong here
Using separate backends does not inherently enable correlation; it may even complicate it because data resides in different systems. Correlation requires shared identifiers, not backend separation. While some organizations use different backends, the key is to propagate trace context into logs regardless of where they are stored, so this choice does not solve the problem.
- ✓
Include the trace ID and span ID in the log entries of each service.
Why this is correct
Including the trace ID and span ID in log entries allows logs to be directly linked to the corresponding trace. When investigating a slow trace, the engineer can search logs for that trace ID and see all related log lines across services. This is a standard practice in cloud native observability and is supported by OpenTelemetry's logging integration, enabling efficient root cause analysis.
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.