OTCA Practice Test

OTCA practice test: what's covered

• Traces
• Metrics
• Logs
• Collector
• OTLP
• Instrumentation

Free OTCA sample questions

1. A platform team can alert when CPU is high but cannot explain why a specific user's checkout request was slow last Tuesday without shipping new code. Which capability are they missing that observability is meant to provide?

   • A. The ability to ask arbitrary new questions of unknown failure modes from existing high-cardinality telemetry
   • B. A faster polling interval for the existing CPU and memory dashboards on the cluster
   • C. An additional uptime monitor that pings the checkout endpoint every thirty seconds
   • D. A larger retention window for the predefined infrastructure alert thresholds
   Show answer

   Correct: A. Observability means you can explore unknown-unknowns by asking new questions of rich telemetry after the fact, without deploying new instrumentation. Faster polling, an extra uptime monitor, and longer retention are all classic monitoring of known signals; they do not let you reconstruct one request's path, so they are not the missing capability here.

2. During an incident review an engineer wants to describe the three primary telemetry signals that OpenTelemetry standardizes end to end. Which set correctly lists those signals?

   • A. Traces, metrics, and logs as the core observability signals
   • B. Alerts, dashboards, and runbooks for incident response
   • C. CPU, memory, and disk as the core resource counters
   • D. Profiles, screenshots, and synthetic checks for monitoring
   Show answer

   Correct: A. OpenTelemetry's three established signals are traces, metrics, and logs (profiling is emerging but still experimental). Alerts/dashboards/runbooks are tooling built on top of signals, CPU/memory/disk are specific metrics not signal categories, and screenshots/synthetic checks are not OpenTelemetry signals, so those options are wrong.

3. A team is justifying a move from traditional monitoring to an observability practice built on OpenTelemetry. Which statements correctly distinguish observability from classic monitoring? (Choose TWO)

   • A. Observability emphasizes exploring unknown-unknowns from rich, high-cardinality telemetry
   • B. Monitoring typically watches predefined metrics and thresholds for known failure modes
   • C. Monitoring inherently forbids collecting any metrics from production systems
   • D. Observability removes the need to ever define alerts or service-level objectives
   • E. Observability means storing only sampled error logs and discarding all traces
   Show answer

   Correct: A and B. Observability is about investigating unknown failure modes from rich telemetry, while monitoring tracks predefined known metrics and thresholds. Monitoring does not forbid metrics, observability does not eliminate alerts or SLOs, and observability never implies discarding traces, so those three statements are wrong.

4. A backend records a single timestamped operation that has a name, start time, duration, and attributes, and it nests inside a larger distributed request. In OpenTelemetry tracing terminology, what is this unit called?

   • A. A span representing one operation within a trace
   • B. A gauge sampling the current operation value
   • C. A resource describing the producing entity
   • D. A propagator carrying context across a boundary
   Show answer

   Correct: A. A span is the fundamental building block of a trace: a named, timed operation with attributes, events, and status. A gauge is a metric instrument, a resource describes the entity producing telemetry, and a propagator injects or extracts context across boundaries, so none of those describe a single timed operation.

5. An engineer needs spans from a producer service to be associated with the consumer span that processes a message off a queue, but the two are not in a strict parent-child relationship within one trace. Which span feature should they use?

   • A. A span link referencing the related span context
   • B. A span event recording a point-in-time message
   • C. A resource attribute naming the queue host
   • D. A baggage entry copying the customer identifier
   Show answer

   Correct: A. Span links associate a span with one or more other spans by their span context, ideal for fan-in/fan-out and async messaging where strict parent-child nesting does not apply. Span events mark a timestamped moment inside one span, resource attributes describe the producing entity, and baggage carries key-value context, so they do not link causally related spans.

Last updated: 2026-10-19

OTCA practice test FAQ