Free OTCA Mock Exam Sample Questions

10 OTCA practice questions with full explanations on every option. Original questions written against the current CNCF curriculum.

Fundamentals of Observability

Q1. Which statement best describes an SLI (Service Level Indicator)?

Reveal answer and explanations
  1. A A vendor-specific metric format pushed by an in-process agent library configured per service

    Incorrect. SLIs are conceptual measurements, independent of any vendor's metric format.

  2. B A quantitative measurement of service behavior such as latency or error rate

    Correct. An SLI is a measured aspect of service behavior such as request latency, availability, or error rate, used as the basis for SLOs.

  3. C A contractual financial penalty triggered when a service is unavailable

    Incorrect. Penalties for missed targets are part of SLAs, not SLIs.

  4. D A specialized type of OpenTelemetry exporter for reliability data

    Incorrect. SLI is a reliability concept, not an OpenTelemetry component.

Fundamentals of Observability

Q2. Which of the following is the strongest argument for OpenTelemetry's unified data model over the historical "three pillars" framing?

Reveal answer and explanations
  1. A Traces, metrics, and logs share resource attributes and trace context, enabling cross-signal correlation

    Correct. By giving all three signals a shared `Resource` and W3C trace context, OpenTelemetry enables joining a metric spike to its log lines and underlying span without the per-tool reconciliation that the pillars framing forced.

  2. B The unified model eliminates the need for sampling because every signal is captured

    Incorrect. Sampling remains a first-class feature in the unified model.

  3. C The unified model removes the need for backends because OTLP can render dashboards directly

    Incorrect. Backends and visualization are out of scope; OpenTelemetry focuses on instrumentation and transport.

  4. D The unified model reduces network bandwidth by emitting a single combined record per request instead of three

    Incorrect. The three signals are still emitted independently; bandwidth savings come from compression, not from collapsing signals.

Fundamentals of Observability

Q3. Why is high cardinality in metrics labels a concern for observability backends?

Reveal answer and explanations
  1. A It always violates GDPR data protection rules regardless of which user data the labels capture

    Incorrect. Cardinality is a cost and scalability problem; GDPR concerns are independent of cardinality.

  2. B It is forbidden by the OpenTelemetry metrics SDK specification

    Incorrect. The specification does not forbid high cardinality; it is a deployment trade-off.

  3. C It forces metrics to be re-encoded as log records inside OTLP

    Incorrect. OTLP supports high-cardinality metrics; encoding does not change with cardinality.

  4. D It causes a time-series explosion that drives memory and storage costs up

    Correct. Each unique combination of label values creates a new time series, so unbounded label values can blow up memory and storage in TSDBs.

Fundamentals of Observability

Q4. A dashboard cannot correlate requests because two services use different keys for the same concept (`http.method` versus `http.request.method`). Which OpenTelemetry concept is designed to prevent this drift?

Reveal answer and explanations
  1. A Span kinds

    Incorrect. Span kinds describe the role of a span, not attribute naming.

  2. B Semantic conventions

    Correct. Semantic conventions define standard attribute names (e.g., `http.request.method`) so different producers do not invent overlapping keys, keeping signals from divergent services correlatable; the example reflects the migration from older `http.method` to the stable `http.request.method`.

  3. C Span links

    Incorrect. Span links connect spans; they do not unify attribute keys.

  4. D Periodic exporting metric reader

    Incorrect. The metric reader controls export cadence, not attribute naming.

Fundamentals of Observability

Q5. What does MTTR most commonly stand for in SRE contexts?

Reveal answer and explanations
  1. A Mean Time To Recovery (or Repair)

    Correct. MTTR is the average time it takes to recover from (or repair) an incident, a key reliability metric that observability aims to reduce.

  2. B Maximum Tolerable Threshold of Requests

    Incorrect. This is not a recognized acronym in SRE literature.

  3. C Mean Throughput Time Ratio

    Incorrect. Throughput-related ratios are not the meaning of MTTR.

  4. D Minimum Time To Release

    Incorrect. This is unrelated to the standard MTTR definition.

Fundamentals of Observability

Q6. In the OpenTelemetry log data model, what is the numeric range of the `SeverityNumber` field, and how is severity organized within it?

Reveal answer and explanations
  1. A `0` to `99`, with each integer representing a single distinct severity level defined by the spec

    Incorrect. The data model does not allocate one integer per level; it uses banded ranges.

  2. B An enum-only field with named members; there is no numeric encoding in OTLP

    Incorrect. `SeverityNumber` is a numeric field with an associated optional `SeverityText`.

  3. C `0` to `255`, mapping byte-for-byte to the numeric severity used by syslog

    Incorrect. The model is not aligned with the syslog severity encoding.

  4. D `1` to `24`, in groups of four (TRACE, DEBUG, INFO, WARN, ERROR, FATAL) with gradations

    Correct. `SeverityNumber` ranges from `1` (TRACE) to `24` (FATAL4) in groups of four, so TRACE is `1`-`4`, DEBUG is `5`-`8`, INFO is `9`-`12`, WARN is `13`-`16`, ERROR is `17`-`20`, FATAL is `21`-`24`.

The OpenTelemetry API and SDK

Q7. Which of the following is NOT a defined OpenTelemetry span kind?

Reveal answer and explanations
  1. A `SERVER`

    Incorrect. `SERVER` is a defined span kind for the receiving side of synchronous calls.

  2. B `CLIENT`

    Incorrect. `CLIENT` is a defined span kind for the calling side of synchronous calls.

  3. C `PRODUCER`

    Incorrect. `PRODUCER` is a defined span kind for asynchronous messaging producers.

  4. D `SCHEDULER`

    Correct. `SCHEDULER` is not a span kind; the defined kinds are `INTERNAL`, `SERVER`, `CLIENT`, `PRODUCER`, and `CONSUMER`.

The OpenTelemetry API and SDK

Q8. When is `SimpleSpanProcessor` an appropriate choice in production?

Reveal answer and explanations
  1. A When you want maximum throughput because each span is exported asynchronously

    Incorrect. `SimpleSpanProcessor` is synchronous, which lowers throughput and adds latency on the hot path.

  2. B When essentially never; it exports each span synchronously and blocks the caller

    Correct. `SimpleSpanProcessor` exports each span synchronously without batching or queueing, which makes it suitable for tests and debugging but inappropriate for production where it adds latency and amplifies exporter failures.

  3. C Whenever the exporter is OTLP/gRPC because gRPC streams remove the synchronous penalty

    Incorrect. The transport does not change the synchronous semantics of the processor itself.

  4. D When the application is single-threaded so synchronous export costs are negligible

    Incorrect. Even single-threaded apps pay the latency tax on every span finish.

The OpenTelemetry API and SDK

Q9. Why does OpenTelemetry separate the API from the SDK?

Reveal answer and explanations
  1. A Because it lets library authors instrument code without forcing a specific SDK choice

    Correct. The API/SDK split lets library authors emit telemetry against a stable API; the application owner chooses if and how to wire up an SDK at runtime.

  2. B Because the API and SDK are deliberately written in different languages

    Incorrect. The API and SDK are typically published in the same language and ecosystem.

  3. C To require application owners to install two separate runtime binaries before any telemetry is produced

    Incorrect. The split is a code-level architecture, not a packaging requirement for the user.

  4. D Because the API is proprietary while the SDK is open source software

    Incorrect. Both the API and SDK are open source under the OpenTelemetry project.

The OpenTelemetry API and SDK

Q10. A service runs `BatchSpanProcessor` with `maxQueueSize=2048`, `maxExportBatchSize=512`, `scheduledDelayMillis=5000`, `exportTimeoutMillis=30000`. The exporter becomes unresponsive while traffic continues. What happens next?

Reveal answer and explanations
  1. A Once the queue fills, newly produced spans are dropped and the SDK records lost telemetry

    Correct. When in-flight exports stall and the bounded queue (`maxQueueSize`) fills, `BatchSpanProcessor` discards incoming spans rather than blocking the application; this is observable via SDK self-metrics but is otherwise silent.

  2. B Each new span blocks the application until the export succeeds

    Incorrect. `BatchSpanProcessor` is asynchronous; it does not block the calling thread when full.

  3. C The processor automatically falls back to `SimpleSpanProcessor` semantics until the exporter recovers

    Incorrect. There is no automatic processor downgrade; the BSP behavior is to drop on backpressure.

  4. D All in-memory spans are flushed to local disk under `/tmp` until the exporter recovers

    Incorrect. The standard SDK does not write spans to local disk; persistent buffering is a Collector queue feature.

Take the full timed OTCA mock exam90 minutes · free with account