OTCA Practice Questions

Twenty-five single-best-answer questions, built the way the real OTCA builds them: a stem, four options, exactly one option that answers this stem better than the other three. They are split across all four domains from the OTCA blueprint in rough proportion to their weight — eleven on the API & SDK, seven on the Collector, five on Fundamentals of Observability, and two on Maintaining & Debugging Pipelines — so a strong or weak score in one section tells you something real about where your marks would actually land. This page is untimed and open-book on purpose: work through it slowly, read every explanation even for questions you got right, and only once these twenty-five stop surprising you should you move on to the two full, weighted, timed papers — Mock Exam · Set 1 and Mock Exam · Set 2. For the fuller walkthrough this bank is drawn from, see the sibling coverage at Platform Engineering's OTCA guide.

How this bank is built

☺ Like you're 10: The biggest pile of questions covers the biggest part of the real test. Study in that order and you're spending your time where the marks actually are.

The OTCA curriculum weights its four domains 46 / 26 / 18 / 10, and this bank mirrors that shape rather than splitting twenty-five questions evenly into piles. The API & SDK alone gets nearly half the bank, because it's nearly half the real paper; Maintaining & Debugging Pipelines — the domain candidates most often skim, because it sounds like an afterthought next to "the data model" — still earns two full questions, because a fixed, answerable toolkit is exactly what a small weighted domain should feel like.

The OpenTelemetry API & SDK — 11 questions

☺ Like you're 10: One half of this is the rulebook every recording device has to follow. The other half is the actual recorder someone has to plug in and turn on — and nothing gets written down until they do.

Forty-six percent of the real exam sits here, and it rewards concrete recall over abstract description: the API/SDK split, the three signals and their exact fields, the pipeline you configure at start-up, context propagation, and the environment-variable surface that controls all of it without touching code. Notice as you go that Context Propagation is the one competency the curriculum names twice — once here, once again in the 10% debugging domain — because a trace that breaks at a service boundary is the signature failure this exam is built to catch.

Q1. Which statement most precisely describes the relationship between the OpenTelemetry API and the OpenTelemetry SDK?

• A. The API and SDK are two names for the same package; there is no meaningful difference.
• B. The API is the interface instrumentation code calls against and is a no-op until an SDK is registered; the SDK is the concrete implementation — providers, processors, samplers, exporters — that a process registers at start-up.
• C. The SDK is what library authors depend on; the API is used only by application authors, never by libraries.
• D. The API generates telemetry data on its own; the SDK's only job is deciding where to send it.

Q2. A team wants to know, for a given span, which instrumentation library emitted it and which version of that library, separately from which service produced it. Which layer of OpenTelemetry's three-layer data shape holds that information?

• A. Resource — it names the service that produced the data, such as service.name and service.version.
• B. InstrumentationScope — it names the library that emitted the record and that library's own version, independent of the service's version.
• C. The signal record itself — spans, metrics and logs have no concept of "which library."
• D. Baggage — user-defined context propagated across service boundaries.

Q3. A span reports status: unset even though the HTTP call it represents returned a 500. Which span field is specifically meant to reflect that the operation the span represents failed?

• A. SpanKind
• B. status (unset / ok / error)
• C. links
• D. events

Q4. Which OpenTelemetry metric instrument has no asynchronous, observable, callback-driven form?

• A. Counter
• B. UpDownCounter
• C. Gauge
• D. Histogram

Q5. Two services in different languages both emit HTTP server spans using the attribute name http.request.method, with the same value shape. What does this specifically buy a dashboard built against that attribute?

• A. Nothing — semantic conventions are advisory naming suggestions with no practical effect.
• B. The dashboard works unmodified against any conformant service emitting the same conventional name, regardless of language or framework, because the attribute name and value shape are standardized rather than left to each team's preference.
• C. It guarantees both services run the identical SDK version.
• D. It replaces the need for a Resource attribute such as service.name.

Q6. In a typical SDK trace pipeline — provider, sampler, processor, exporter — which single component decides, before a span is even completed, whether that span will ultimately be exported at all?

• A. The exporter
• B. The processor
• C. The sampler
• D. The propagator

Q7. Service A samples with ParentBased(TraceIDRatioBased(0.1)). Service B, downstream of A, uses a plain TraceIDRatioBased(0.5) — five times more permissive, and not deferring to the incoming decision at all. For a trace where Service A decided not to sample, what is the most likely consequence?

• A. No consequence — the 10% and 50% ratios never interact with each other.
• B. Service B may still independently decide to record and export its own spans for that same trace, producing a fragment for a trace Service A intentionally dropped — because Service B's sampler does not honor the parent's sampled flag.
• C. The trace is automatically discarded by the Collector because the two ratios don't match.
• D. Service A retroactively re-samples the trace once it observes Service B's decision.

Q8. A short-lived batch job creates a TracerProvider, records several spans, then calls os.Exit(0) without calling the provider's Shutdown method first. What happens to spans still sitting in the batch processor's buffer?

• A. They are flushed automatically by the language runtime's exit handler before the process actually terminates.
• B. They are lost — the batch processor only sends buffered spans on its timer or when explicitly flushed, and an abrupt exit gives it no chance to do either.
• C. They are written to local disk automatically for the next process to pick up.
• D. The OTLP exporter retries them once the process restarts.

Q9. A service is configured with these environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability:4317
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

Telemetry from this service never arrives at the Collector, and the application logs show no error. What is the most likely cause?

• A. The Collector is down.
• B. The port and the protocol disagree — 4317 is the gRPC port, but the protocol is set to http/protobuf; HTTP listens on 4318 — and this class of mismatch tends to fail silently rather than raise an application-visible error.
• C. OTEL_EXPORTER_OTLP_ENDPOINT is spelled incorrectly and is being silently ignored.
• D. Environment variables are never read for OTLP configuration; only code-based configuration works.

Q10. Which four pieces of information does a W3C traceparent header carry?

• A. Trace ID, span ID, service name, and sample rate.
• B. Version, trace ID, span ID (the "parent ID" from the receiver's point of view), and trace flags — including the sampled bit.
• C. Trace ID, baggage, tracestate, and status code.
• D. Service name, span kind, resource attributes, and timestamp.

Q11. An engineer proposes putting a customer's email address into OpenTelemetry baggage so every downstream service in a call chain can look it up without a database call. What is wrong with this plan?

• A. Nothing — baggage is encrypted in transit by default, so this is a safe pattern.
• B. Baggage rides in plaintext headers to every downstream service in the call chain — including third-party services outside your own systems — and is not automatically attached to spans, so it is meant for routing hints and tenant labels, never secrets or personal data.
• C. Baggage has a hard 16-byte size limit, so an email address would not fit.
• D. Baggage can only be read by the service that originally set it, so downstream services couldn't use it anyway.

The OpenTelemetry Collector — 7 questions

☺ Like you're 10: One box, five kinds of Lego brick inside it, and a strict rule: a brick nobody actually plugged into the model doesn't do anything, no matter how carefully you built it.

Twenty-six percent of the paper, and almost all of it is one binary: what receives data, what changes it in flight, what sends it on, and the strict wiring rule that governs all three. Get the five component types and the pipeline-referencing rule solid before anything else here.

Q12. Which of the following is NOT one of the OpenTelemetry Collector's five component types?

• A. Receivers
• B. Processors
• C. Samplers
• D. Connectors

Q13. In the config below, the batch processor is defined under processors: but is not listed in the traces pipeline's processor list:

processors:
  memory_limiter: { check_interval: 1s, limit_percentage: 80 }
  batch: { timeout: 5s, send_batch_size: 8192 }

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter]
      exporters: [otlp/backend]

What happens to the batch processor at runtime?

• A. The Collector refuses to start, rejecting an unreferenced component.
• B. It still runs in the background and batches everything anyway.
• C. It is simply never instantiated for that pipeline — it does nothing, silently, with no warning or error.
• D. The Collector automatically appends it to the end of the pipeline for safety.

Q14. Why is memory_limiter conventionally placed first in a Collector pipeline's processor list, with batch placed last?

• A. Processor order in the list has no runtime effect; it's purely a documentation convention.
• B. Processors run in the order listed. memory_limiter needs to shed load before the Collector's heap is threatened, so it goes first; batch should run after any filtering or sampling has already reduced the data, so it wastes no work batching data that gets dropped anyway.
• C. Alphabetical order is required by the Collector's configuration schema.
• D. batch must run first so memory_limiter has already-batched data to measure against.

Q15. A platform team wants to delete the http.request.header.authorization attribute from every span before it leaves the cluster, and mark any span with a 500-or-above response status as an error — without redeploying a single application. Which Collector component is built for exactly this?

• A. The batch processor
• B. The transform processor, using OTTL statements
• C. The memory_limiter processor
• D. The health_check extension

Q16. A platform runs one Collector as a DaemonSet on every node — an "agent" deployment — and nothing else. What can adding a separate "gateway" Collector — a scalable Deployment the agents forward to — do that the agent-only setup cannot?

• A. Nothing — agent and gateway Collectors are functionally identical.
• B. Give the fleet a single, cross-node place to do expensive, fleet-wide work such as tail sampling and per-tenant routing, which a per-node agent structurally cannot do because it only ever sees the spans that happen to land on its own node.
• C. Receive telemetry over OTLP — a capability only gateways support.
• D. Automatically rotate exporter credentials.

Q17. A platform runs three gateway Collector replicas behind a Service, load-balanced round-robin at the network layer, each independently running tail_sampling. Traces intermittently come out incomplete. What is the most likely cause?

• A. tail_sampling is fundamentally incompatible with the Collector and should never be used.
• B. Round-robin network balancing can send different spans of the same trace to different replicas; tail_sampling needs every span of a trace in one instance to make its decision, which requires routing by trace ID — the job of the loadbalancing exporter — rather than plain network round-robin.
• C. The receivers are misconfigured to accept only HTTP, not gRPC.
• D. batch is missing from the pipeline, causing spans to arrive out of order.

Q18. Which statement correctly describes a Collector connector, such as spanmetrics?

• A. A connector is a special kind of receiver that can only accept OTLP.
• B. A connector joins two pipelines together — acting as the exporter of one and the receiver of the next — letting one signal, such as traces, derive another, such as RED metrics, inline in the Collector.
• C. A connector is an authentication extension used to secure the Collector's own admin endpoints.
• D. A connector is a client library used inside application code, not a Collector component at all.

Fundamentals of Observability — 5 questions

☺ Like you're 10: This is the smallest pile on the test, and it's small on purpose — it's the "why," and the exam mostly wants the "how."

Eighteen percent, covering Telemetry Data, Semantic Conventions, Instrumentation, and Analysis and Outcomes. Reading about observability in the abstract — the three pillars, golden signals, RED and USE — prepares you for this domain and roughly nothing else; 72% of the paper is the two pieces of concrete software above it.

Q19. A candidate studies only the "three pillars of observability," RED, and USE — without touching real SDK setup or Collector config. Which best describes why that candidate is under-prepared for the exam as a whole?

• A. Because Fundamentals of Observability is actually the largest domain, not the smallest.
• B. Because 72% of the paper is the API/SDK and the Collector — two pieces of concrete, configurable software — so reading about observability in the abstract prepares a candidate for, at most, the smallest single domain.
• C. Because the exam contains no fundamentals questions at all.
• D. Because Fundamentals questions are asked only as a tiebreaker for candidates on the pass/fail boundary.

Q20. A team is deciding whether to build long-lived dashboards and alerts against a particular OpenTelemetry semantic convention attribute. What should they check first?

• A. Whether the attribute name is alphabetically before "m," since conventions are sorted for stability.
• B. The attribute's published stability level — conventions are versioned, and not every attribute carries the same stability guarantee, so building on an unstable one risks a rename or shape change underneath you.
• C. Whether the attribute is used by Argo CD, since that determines convention stability.
• D. Nothing — all semantic convention attributes are permanently frozen the moment they're published.

Q21. A platform team wants every service in the cluster to emit traces immediately, without asking any application team to change a line of code. Which approach fits, and what does it cost compared to hand-written instrumentation?

• A. Manual instrumentation using the SDK directly in each service's source code — there is no way to get traces without code changes.
• B. Zero-code, automatic instrumentation — a Java -javaagent, Python's opentelemetry-instrument, or, on Kubernetes, the OpenTelemetry Operator injecting an agent from a pod annotation — which produces traces for common libraries out of the box, but cannot capture custom, business-specific spans that only a developer deliberately adding a span would think to create.
• C. The debug exporter, which instruments application code automatically as a side effect of being configured.
• D. A memory_limiter processor set to 100%, which enables full automatic instrumentation.

Q22. A latency dashboard shows a sharp spike in p99 request duration at 14:02. Which OpenTelemetry metric feature is specifically designed to let an engineer jump directly from that spike to one of the actual slow traces that caused it?

• A. Aggregation temporality
• B. Exemplars — individual metric data points that carry a trace ID, linking a statistical spike directly to a specific, concrete trace.
• C. Views
• D. The InstrumentationScope

Q23. OpenTelemetry is sometimes summarized as unifying the "three pillars" of observability. Once traces, metrics and logs share the same Resource and correlated trace-context fields, what actually changes compared to collecting each pillar with an unrelated, uncorrelated tool?

• A. The three pillars become a single signal type, and the distinction between traces, metrics and logs disappears entirely.
• B. An engineer can move directly between a log line, its enclosing span, and a metric spike for the same request, because a shared Resource identifies the same source across all three and correlated fields — a trace ID on a log line, an exemplar on a metric point — tie them together, rather than reasoning across three unrelated tools by hand.
• C. Correlation eliminates the need for sampling on traces, since metrics now supply complete trace data.
• D. Correlation is only possible if all three signals are stored in the same physical database.

Maintaining & Debugging Observability Pipelines — 2 questions

☺ Like you're 10: The smallest pile of all — and it's a fixed toolbox question, not a trivia question. What do you reach for, and what happens when a pipeline gets overwhelmed?

Ten percent, but a fixed, learnable toolkit: backpressure and loss under pressure, and how telemetry stays queryable across a slow, staggered migration of convention versions.

Q24. A Collector's OTLP exporter is configured with sending_queue: { enabled: true, queue_size: 5000 } and no file_storage extension. The downstream backend goes down for twenty minutes and the queue fills completely. What happens to new spans arriving during that period?

• A. They are held indefinitely in the Collector's process memory until the backend recovers, however long that takes.
• B. Once the queue is full, further spans are dropped — the sending queue buffers in memory by default with no durability unless backed by a file_storage extension, and a Collector that accepted unlimited data while a backend was down would eventually be OOMKilled instead.
• C. They are automatically rerouted to the debug exporter as a fallback.
• D. The Collector pauses its receivers entirely until the backend comes back.

Q25. OpenTelemetry semantic conventions rename an attribute between one version and the next. A fleet has some services still emitting the old attribute name and some already emitting the new one. What mechanism lets both be queried together without a coordinated flag-day migration?

• A. The schema URL recorded on telemetry, paired with OpenTelemetry's published, machine-readable schema files describing the transformation between convention versions.
• B. The memory_limiter processor, which normalizes attribute names automatically.
• C. Nothing — every service in the fleet must be redeployed simultaneously the moment a convention changes.
• D. The health_check extension, which reports which schema version each service is running.

Scoring yourself, and what to do with a miss

☺ Like you're 10: Getting it wrong isn't the problem — not knowing why you got it wrong is. Every miss fits into one of four boxes, and each box has its own fix.

Count your correct answers and divide by 25 to get a rough percentage — this bank is too small to be a statistically precise rehearsal of the real paper, but it's plenty large enough to tell you whether a domain needs more reading before you attempt Mock Exam · Set 1.

When you miss one, resist the urge to just note the correct letter and move on — that teaches you almost nothing. File it instead:

Whichever domain produced the most misses, weigh that against its blueprint weight before deciding where to spend the next study session — a rough score in the 46%-weighted API & SDK domain costs far more than the same rough score in the 10%-weighted debugging domain. The OTCA study plan lays out exactly how to sequence reading, this bank, and the two mock exams across the days you have.