← OTCA hub

OTCA — The OpenTelemetry API and SDK

46% of the OTCA exam. Sample questions below; the full library has 56 questions tagged to this domain.

Sample questions on The OpenTelemetry API and SDK

The OpenTelemetry API and SDK

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

Reveal answer and explanations
  1. A To let 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

Q2. 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.

The OpenTelemetry API and SDK

Q3. 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

Q4. 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 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

Q5. What is the primary purpose of `baggage` in OpenTelemetry?

Reveal answer and explanations
  1. A To compress and signature-verify span payloads before they leave the SDK boundary

    Incorrect. Compression is a transport concern, unrelated to baggage.

  2. B To buffer spans in memory during transient exporter outages

    Incorrect. Buffering during outages is the role of the exporter's sending queue, not baggage.

  3. C To carry user-defined key-value pairs along the request path to downstream services

    Correct. Baggage is a propagation mechanism for arbitrary key-value pairs that travel with the context across service boundaries.

  4. D To declare the schema URL applied to span attributes

    Incorrect. Schema URLs are independent of baggage.

Drill The OpenTelemetry API and SDK with the full bankDomain Drill mode targets your weak areas — paid feature

How this domain is tested

The OpenTelemetry API and SDK accounts for 46% of the OTCA exam. Expect questions that test recall of terminology and the ability to read short scenarios — not deep configuration. Use the sample questions above as difficulty calibration; if any feel hard, the rest of our 56-question domain bank will close those gaps.