Certifications · OTCA · Mock Exam · Set 1

OTCA Mock Exam · Set 1

A complete 45-question OTCA practice paper, weighted question-for-question to the four domains of the official OTCA curriculum — 21 on the OpenTelemetry API & SDK, 12 on the Collector, 8 on Fundamentals of Observability, 4 on Maintaining & Debugging Pipelines. The real exam's question count isn't published by the Linux Foundation, so 45 is this course's own study convention rather than a promise about the real paper's length — what matters is that it's sat under the real published 90-minute budget and scored against the real published 75% pass mark, so the pacing and the bar both mean something. Every question below is followed immediately by a worked explanation, and every wrong answer names the trap it was built to catch — endpoint/protocol mismatches, a component defined but never wired into a pipeline, a sampler applied without ParentBased, and the rest of the failure modes that show up again and again once you've run OpenTelemetry for real. Sit it cold, in one sitting, then use the domain breakdown at the end to find out exactly which quarter of the syllabus needs another pass.

Where Set 1 sits in your OTCA prep

☺ Like you're 10: Read the syllabus first, drill the questions second, sit the full mock third — in that order, not backwards.

The sensible sequence on this course is: read OTCA — the exam end to end for the four domains, the SDK pipeline, and the Collector's wiring trap; follow the OTCA study plan so that reading is paced rather than crammed into a weekend; work the practice question bank to learn the shape of a question and its common distractors in isolation; then sit this paper cold, as a single measurement of the whole syllabus at once, under a real clock. This paper deliberately assigns questions to each domain in the same proportion the CNCF assigns marks on the real exam — 46% API & SDK, 26% Collector, 18% Fundamentals, 10% Debugging — so a weak result in one domain here is unusually actionable: it names the exact page to reread, not just a vague sense of "did badly."

This is Set 1 of two on this course. Once this paper is solid, Set 2 covers the same four domains in the same proportion with an entirely different question set, so treat the two as two honest sittings rather than one paper read twice — repeating this exact set a second time mostly measures whether you memorized which letter you clicked last time, not whether you know the material.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, ninety minutes — and if you're not sure, guess anyway, because a blank answer can't possibly score better than a guess.

The OTCA is delivered online, remote-proctored, and closed-book: no documentation, no second monitor, no colleague, no AI assistant once the clock starts. Sit this practice paper under the same restriction rather than quietly loosening it "just this once" — close every other tab, and treat the 45 questions below exactly as you would in a locked-down proctored session. The Linux Foundation's Multiple Choice Exam FAQ doesn't publish a separate penalty for a wrong guess beyond simply not earning the point — nothing there suggests a blank answer is ever safer than a considered guess. Treat that as the reasonable working assumption it is, confirm it on the official page before you rely on it for real, and either way the strategy is unambiguous: never leave a question unanswered. Eliminate what you can rule out, then commit to your best remaining option.

Your 90-minute budget

☺ Like you're 10: Forty-five questions, ninety minutes — that's exactly two minutes each, split into three half-hour blocks so you can check your pace roughly every thirty minutes instead of guessing.

Forty-five questions across 90 minutes divides cleanly into 2 minutes per question, and this paper is split into three 30-minute, 15-question blocks so you have a clean checkpoint every half hour rather than discovering with ten minutes left that you're only on question 20. No single block leans on one domain — every block mixes API & SDK, Collector, Fundamentals, and Debugging questions in roughly the same proportion as the paper overall, which is exactly how a real associate-level exam is assembled.

If a question runs past two minutes without a confident answer, don't stall on it: eliminate what you can, commit to your best remaining option, and move on. Each question's explanation sits directly underneath it — treat opening it before you've committed to an answer as a spoiler that defeats the entire point of a timed sitting.

The paper — 45 questions in exam order

☺ Like you're 10: Read the stem once, pick one answer, then check yourself before moving on — every question is tagged with its domain so you can total your score by domain afterward.

Each question is tagged with its domain in parentheses; the real exam won't give you that label, so once you've sat this paper for the first time, consider a second read-through with the tags covered to see how many you can still place correctly on content alone. Two questions are marked (Select TWO) — full credit there requires both correct letters, exactly as a Linux Foundation multiple-response item is scored.

Block 1 — Q1–15 (minutes 0–30)

Q1 (API & SDK). A developer adds OpenTelemetry instrumentation calls throughout a service's request-handling code, but never sets up an SDK or registers a TracerProvider. What happens when the service runs?

• A. The API automatically falls back to a default in-memory exporter, so spans appear in local logs
• B. Every span created by the instrumentation is discarded immediately, because the API is a no-op until an SDK is registered — no data is produced and no error is raised
• C. The application throws a fatal error at start-up because no TracerProvider is configured
• D. Spans are buffered indefinitely in memory until an SDK is eventually registered, however long that takes

Check the answer

B. The OpenTelemetry API is a no-op by design until an SDK is registered behind it — instrumentation compiles and runs fine, but spans are simply thrown away as they're created, silently. This is the single most common "why is nothing showing up" root cause.

Q2 (Collector). Which list correctly names all five of the OpenTelemetry Collector's component types?

• A. Receivers, processors, exporters, extensions, connectors
• B. Receivers, transformers, exporters, plugins, aggregators
• C. Inputs, filters, outputs, sinks, bridges
• D. Receivers, processors, forwarders, extensions, adapters

Check the answer

A. Receivers get data in, processors change it in flight, exporters send it out, extensions add capabilities outside any data path, and connectors join two pipelines together. Knowing these five cold covers most of the Collector domain.

Q3 (Fundamentals). Every piece of OpenTelemetry telemetry shares the same three-layer shape. Which set correctly names those layers, from outermost to innermost?

• A. Provider, Processor, Exporter
• B. Resource, InstrumentationScope, the signal record itself (Span, metric data point, or LogRecord)
• C. Service, Namespace, Instance
• D. Trace, Span, Event

Check the answer

B. Resource describes what produced the telemetry (like service.name), InstrumentationScope names the library and version that emitted it, and the record itself carries the signal-specific fields. D describes structure inside a trace only, not the shape every signal shares.

Q4 (API & SDK). In a trace SDK pipeline, which four components does a TracerProvider typically assemble to turn API calls into exported telemetry?

• A. A resource, a sampler, one or more span processors, and an exporter
• B. A receiver, a processor, an extension, and a connector
• C. A propagator, a baggage store, a context, and a scope
• D. A collector, a backend, a dashboard, and an alert

Check the answer

A. Option B lists Collector components, not SDK components — a common confusion since the two pipelines sound similar but sit on opposite sides of the wire: one inside your application, one as separate infrastructure.

Q5 (Debugging). A team suspects their Collector is silently dropping spans somewhere in the pipeline, but doesn't yet know whether the fault is at the receiver, a processor, or the exporter. What's the recommended first diagnostic step?

• A. Immediately restart the Collector and hope the problem clears
• B. Enable and inspect the Collector's own internal telemetry metrics — counters for accepted, refused, and dropped spans, and for failed exports — to localize the fault to a specific stage
• C. Delete the pipeline configuration and rebuild it from scratch
• D. Switch every exporter to the debug exporter permanently in production

Check the answer

B. The Collector emits its own metrics describing what each pipeline stage is doing (service.telemetry.metrics). Reading those first localizes a fault to receiver, processor, or exporter before you touch config or restart anything — the fastest way to bisect the problem.

Q6 (API & SDK). Which OpenTelemetry metric instrument has no asynchronous (observable, callback-driven) counterpart in the specification?

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

Check the answer

C. Counter, UpDownCounter, and Gauge each have a synchronous and an asynchronous/observable form; Histogram is synchronous-only, because its per-event bucket recording has no meaningful callback-driven equivalent. That asymmetry is a favorite exam distractor.

Q7 (Collector). A Collector config defines a transform processor under the top-level processors: block, fully and correctly, but the traces pipeline's processors: list only names [memory_limiter, batch]. What happens to transform when the Collector starts?

• A. The Collector refuses to start and logs a configuration error
• B. The Collector starts cleanly, but transform is never invoked — it's valid YAML that simply does nothing, with no warning
• C. transform runs automatically on every pipeline by default, since it's defined at the top level
• D. The Collector applies transform only to metrics and logs, skipping traces

Check the answer

B. A component must be listed inside a pipeline's receivers, processors, or exporters array to run at all — defining it elsewhere in the file is necessary but not sufficient, and the Collector gives no error or warning when a defined-but-unreferenced component sits inert.

Q8 (Fundamentals). What problem do OpenTelemetry semantic conventions — agreed names like service.name, http.request.method, and error.type — actually solve?

• A. They compress telemetry payloads to reduce network bandwidth
• B. They let a dashboard or query written against a conventional attribute name work against any conformant service, in any language, with no per-service customization
• C. They encrypt sensitive attribute values before export
• D. They determine which sampler an SDK uses by default

Check the answer

B. Semantic conventions are purely a naming and value agreement — the interoperability payoff is that tooling built against those names works everywhere, which is why they're a whole competency and not a footnote.

Q9 (API & SDK). What is the practical difference between a simple span processor and a batch span processor in the SDK?

• A. A simple processor samples 100% of spans; a batch processor samples 10% by default
• B. A simple processor exports each span synchronously, one at a time, as it ends — useful mainly for debugging; a batch processor buffers spans and exports them in batches, the production-appropriate choice
• C. They are functionally identical; the names only affect logging verbosity
• D. Batch processors are only available for metrics, not traces

Check the answer

B. Simple processors export inline, per span, adding latency and overhead unsuited to production load. Batch processors buffer and flush on a schedule or size threshold, trading a small delay for far better throughput.

Q10 (Collector). In a Collector pipeline's processor list, why is memory_limiter conventionally placed first, ahead of batch and any other processors?

• A. Processor order has no effect on behavior; it's purely stylistic
• B. So it can shed incoming load and refuse data before the Collector's memory is exhausted, protecting the process before any other, more expensive processing happens
• C. Because processors execute in reverse of the order listed
• D. memory_limiter must run last so it can measure the final batch size before export

Check the answer

B. Processors run in exactly the order listed. Putting memory_limiter first lets it reject or shed data under pressure before the Collector spends CPU and memory on later processors — protecting the process rather than reacting after the fact.

Q11 (API & SDK). An SDK's sampler is configured as ParentBased(TraceIdRatioBased(0.1)). A span arrives that already has an active, sampled parent context. What does the sampler do?

• A. It ignores the parent's decision and applies the 10% ratio fresh at every span
• B. It respects the parent's sampling decision — since the parent was sampled, this span is sampled too, regardless of the 10% ratio
• C. It always samples exactly 10% of child spans regardless of the parent
• D. It rejects the span, because ParentBased and TraceIdRatioBased cannot be combined

Check the answer

B. ParentBased defers to whatever decision the incoming context already carries when one exists, falling back to the wrapped sampler (here, a 10% ratio) only when there's no parent to defer to — this is what keeps a whole trace sampled, or not, consistently end to end.

Q12 (Fundamentals). A team wants one signal that tells them, at a glance, whether users are currently experiencing a problem with a service, before diving into any specific metric. Which observability practice is built around exactly that question?

• A. Recording VPC-level packet counts
• B. The "golden signals" (or RED/USE-style) approach — a small, standard set of signals like latency, traffic, errors, and saturation, read together as an at-a-glance health check
• C. Increasing log retention to 90 days
• D. Renaming every metric to include a UUID

Check the answer

B. Golden-signal-style frameworks exist precisely to compress a service's health into a handful of standard, comparable signals — this is the "Analysis and Outcomes" competency, a reading practice rather than a feature of any one tool.

Q13 (API & SDK). An SDK is configured with OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 and OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf. What is most likely to happen?

• A. The exporter automatically detects the mismatch and corrects the port
• B. Telemetry export fails silently from the application's point of view, because port 4317 is the gRPC OTLP port while the protocol is set to HTTP — the endpoint and the protocol must agree
• C. Nothing is affected; OTLP treats gRPC and HTTP identically on any port
• D. The SDK refuses to start until the values are corrected

Check the answer

B. gRPC listens on 4317 and HTTP on 4318 by convention. Mismatching the port against the configured protocol is a classic, silent failure — the application sees no error, only missing telemetry downstream.

Q14 (Collector). A Collector's otlp receiver is configured with both a grpc and an http protocol block. Which default ports does the OpenTelemetry ecosystem conventionally use for each?

• A. gRPC on 4317, HTTP on 4318
• B. gRPC on 4318, HTTP on 4317
• C. Both protocols share port 4317 by default
• D. gRPC on 8080, HTTP on 8443

Check the answer

A. 4317 for gRPC and 4318 for HTTP is the OTLP convention across the whole ecosystem — SDK exporters, the Collector's receiver, and most documentation all assume this pairing unless explicitly overridden.

Q15 (API & SDK). An attribute service.name is attached to telemetry. Which layer of the OpenTelemetry data model does it belong to?

• A. The Resource — it describes what produced the telemetry, not the specific library or the individual record
• B. The InstrumentationScope — it names the library that emitted the data
• C. The span's own attributes, alongside request-specific values like http.route
• D. The exporter's configuration, not the data model at all

Check the answer

A. service.name describes the entity producing the telemetry (the Resource), set once per process and shared across every span, metric, and log record it emits — unlike InstrumentationScope (per-library) or span attributes (per-record).

Block 2 — Q16–30 (minutes 30–60)

Q16 (API & SDK). How does OpenTelemetry's logging support differ structurally from its tracing and metrics support?

• A. OpenTelemetry ships no user-facing logging API of its own; instead it bridges the logging library an application already uses, attaching trace context to existing log output
• B. Logs are the only signal collected without an SDK, using a separate zero-configuration mechanism
• C. Logs cannot be exported via OTLP, only traces and metrics can
• D. LogRecord objects require a completely separate Collector binary to process

Check the answer

A. Rather than asking every application to rip out its existing logger, OpenTelemetry provides a bridge/appender that plugs into the logging framework already in use, correlating each log line with the active trace and span IDs.

Q17 (Collector). A platform team wants a Collector to scrape host-level CPU, memory, and disk metrics directly from the node it's running on. Which receiver is purpose-built for this?

• A. otlp
• B. filelog
• C. hostmetrics
• D. jaeger

Check the answer

C. hostmetrics collects operating-system-level metrics from the host the Collector runs on. otlp receives already-formatted telemetry pushed to it, filelog tails log files, and jaeger is a legacy trace-format receiver.

Q18 (Fundamentals). An engineer wants to add a user.email attribute to every span in a checkout service, to make debugging individual customer issues easier. What is the main instrumentation-quality concern with this?

• A. It has no downside — more attributes always make debugging easier
• B. Email addresses are both high-cardinality and personally identifying, so attaching them as span attributes risks both a cost/cardinality explosion in the backend and a data-protection problem
• C. Span attributes can only be integers, so a string value would be rejected outright
• D. Only Resource-level attributes are allowed to contain PII

Check the answer

B. Good instrumentation weighs cardinality (does this attribute value blow up storage and query cost?) and sensitivity (should this ever leave the process at all?) — a raw email address fails both tests; a hashed or tokenized ID is the usual compromise.

Q19 (API & SDK). A team stores a customer's session ID in OpenTelemetry baggage so every downstream service can log it. What should they keep in mind about baggage?

• A. Baggage values are automatically attached as attributes on every span, so nothing else needs to be done
• B. Baggage rides in a plaintext HTTP header to every downstream hop, is not automatically copied onto spans, and should never carry secrets or sensitive personal data
• C. Baggage is encrypted end to end by default, making it safe for any data
• D. Baggage only propagates within a single process and never crosses a network boundary

Check the answer

B. Baggage is genuinely useful for routing hints and correlation IDs, but it travels as a plaintext header to every service in the call chain — including third-party ones — and doesn't attach itself to spans automatically, which is why it comes with a recurring "don't put secrets here" warning.

Q20 (Debugging). An OTLP exporter's backend becomes slow, and the exporter's sending_queue starts filling up. Without any additional configuration, what happens once the queue is full?

• A. The Collector blocks all other pipeline processing indefinitely until the backend recovers
• B. New data is dropped once the queue is full, unless the queue is backed by the file_storage extension, which can persist buffered data across restarts and queue-full conditions
• C. The Collector automatically switches to a different exporter
• D. The sending_queue grows without bound, and memory usage is unaffected

Check the answer

B. sending_queue buffers export attempts and retries transient failures, but it's finite — once full, new data is dropped unless it's backed by durable storage via file_storage. Telemetry pipelines are deliberately lossy under sustained pressure; the choice is where the loss happens.

Q21 (API & SDK). A platform team wants Java services running in a Kubernetes cluster to get distributed tracing without any application code changes. Which mechanism, backed by the OpenTelemetry Operator, achieves this?

• A. Manually editing every service's source code to add OpenTelemetry API calls
• B. An Instrumentation custom resource plus a pod annotation (e.g. instrumentation.opentelemetry.io/inject-java), which the Operator uses to inject a zero-code Java agent via an init container
• C. Running a second copy of the application compiled with tracing enabled
• D. Configuring the Collector's otlp receiver to auto-generate spans from raw network traffic

Check the answer

B. Zero-code (automatic) instrumentation is the "Agents" competency, which sits inside the API & SDK domain. On Kubernetes, the Operator reads an Instrumentation CR and a workload's pod-template annotation to inject the right language agent with no source changes.

Q22 (Collector). A Collector config includes a spanmetrics connector. What role does a connector play in a Collector's pipeline topology?

• A. It only adds authentication to receivers, like an extension does
• B. It acts as the exporter of one pipeline and the receiver of the next, letting it derive new telemetry (like metrics computed from spans) and feed it into a second pipeline
• C. It replaces the need for any receiver or exporter entirely
• D. It only runs at Collector start-up, not during normal operation

Check the answer

B. Connectors bridge two pipelines — spanmetrics sits as the exporter of a traces pipeline and the receiver of a metrics pipeline, deriving RED-style metrics from span data as it flows through.

Q23 (Fundamentals). A team wants to answer "exactly where did the time go across these four downstream calls, for this one slow request?" Which signal is purpose-built for that question?

• A. Metrics, because they're the cheapest signal to store
• B. Traces, because a single trace's spans show the timed breakdown of a request across every service it touched
• C. Logs, because they contain the most raw detail
• D. None of the three signals can answer a per-request timing question

Check the answer

B. Traces exist specifically to answer per-request, cross-service timing questions; metrics aggregate across many requests and lose per-request detail, and raw logs require manual correlation to reconstruct a timeline traces give you natively.

Q24 (API & SDK). Which of the following is a valid value for a Span's SpanKind?

• A. SYNCHRONOUS
• B. PRODUCER
• C. BATCHED
• D. ROOT

Check the answer

B. The five defined SpanKind values are INTERNAL, SERVER, CLIENT, PRODUCER, and CONSUMER — describing the span's relationship to a remote call, not its sampling state or its position in the trace tree.

Q25 (Collector). A Collector fleet runs tail_sampling behind a load balancer that could route different spans of the same trace to different Collector replicas. Why is this a problem, and what fixes it?

• A. It isn't a problem — tail_sampling works correctly no matter which replica handles which span
• B. tail_sampling needs to see every span of a trace in one place to make its keep/drop decision, so spans must be routed consistently to the same replica — typically via a loadbalancing exporter that routes by trace ID
• C. The fix is to disable batching on every processor
• D. The fix is to run exactly one Collector replica for the entire fleet

Check the answer

B. Tail-based sampling is inherently stateful — it can't decide whether to keep a trace until it has seen the whole thing — so a naive load balancer that splits one trace across replicas breaks it. Routing consistently by trace ID (what loadbalancing does) keeps every span of a given trace together.

Q26 (API & SDK, Select TWO). OpenTelemetry's SDK is deliberately built around pluggable interfaces. Which TWO of the following are legitimate, spec-supported ways to extend or customize SDK behavior without forking the specification itself?

• A. Registering a custom Sampler implementing your own sampling logic
• B. Registering a custom SpanProcessor or exporter to change how spans are buffered or where they're sent
• C. Editing the wire format of OTLP itself to add proprietary fields
• D. Replacing traceparent with a private header format inside your own services only, with no propagator change
• E. Hand-patching the compiled SDK binary to change instrument behavior

Check the answer

A and B. Samplers, processors, and exporters are explicit, documented extension points — the "Composability and Extension" competency. Changing the wire protocol (C) or silently swapping header formats without registering a matching propagator (D) breaks interoperability rather than extending it within the spec, and patching a binary (E) isn't a supported mechanism at all.

Q27 (Fundamentals). A dashboard shows a sudden spike in p99 latency on a metric graph. What OpenTelemetry feature lets an engineer click that spike and land directly in one of the actual slow traces that caused it?

• A. Semantic conventions
• B. Exemplars — trace IDs attached to specific metric data points, linking an aggregate spike back to an individual trace
• C. The InstrumentationScope
• D. The memory_limiter processor

Check the answer

B. Exemplars are the explicit bridge between the aggregate world of metrics and the per-request world of traces — a metric data point carries a sampled trace ID as an exemplar, so a spike on a graph can point straight at one concrete example of it.

Q28 (API & SDK). An application process calls its SDK's shutdown method before exiting. What does skipping this step risk?

• A. Nothing — spans are always written to disk immediately regardless of shutdown
• B. Whatever spans the batch processor is still holding in its buffer, not yet flushed to the exporter, are lost when the process exits
• C. The process will fail to exit until shutdown is called
• D. Skipping shutdown only affects metrics, never traces

Check the answer

B. A batch processor buffers spans in memory and flushes on a timer or size threshold. If the process exits before that flush happens and shutdown was never called to force one, whatever was still buffered is gone — a quiet way to lose exactly the last few seconds of telemetry before a crash or an unflushed exit.

Q29 (Collector, Select TWO). OTTL (the OpenTelemetry Transformation Language) is used to write conditional statements that reshape telemetry in flight. Which TWO Collector components are OTTL-based?

• A. The transform processor
• B. The filter processor
• C. The memory_limiter processor
• D. The batch processor
• E. The health_check extension

Check the answer

A and B. transform and filter both accept OTTL statements to modify or drop records based on conditions evaluated against the data itself. memory_limiter and batch operate on resource pressure and buffering rather than record content, and health_check is a non-data-path extension entirely.

Q30 (API & SDK). A team needs to disable all OpenTelemetry instrumentation in one specific service instance, without redeploying or changing any code, as a quick kill switch during an incident. Which environment variable does this?

• A. OTEL_TRACES_SAMPLER_ARG=0
• B. OTEL_SDK_DISABLED=true
• C. OTEL_PROPAGATORS=none
• D. OTEL_METRIC_EXPORT_INTERVAL=0

Check the answer

B. OTEL_SDK_DISABLED is the dedicated, documented kill switch — set at the process level with no code change or redeploy needed. Zeroing the sampler ratio (A) still runs the SDK pipeline and only affects traces, not the other signals.

Block 3 — Q31–45 (minutes 60–90)

Q31 (API & SDK). A metrics SDK is configured with an aggregation temporality. What does this setting actually control?

• A. Whether a metric is exported as a delta (the change since the last export) or cumulative (the running total since the process started)
• B. How many decimal places a metric value is rounded to
• C. Whether the metric is a Counter or a Histogram
• D. The time zone used to timestamp exported data points

Check the answer

A. Temporality is specifically about whether consecutive exports represent independent deltas or a running cumulative sum — a backend needs to know which it's receiving to aggregate correctly, and mismatched assumptions here is a common source of doubled- or halved-looking totals.

Q32 (Collector). In a Collector pipeline's processor list, batch is conventionally placed near the end, after filtering and sampling processors rather than before them. Why?

• A. Because batch must always run before memory_limiter
• B. Because batching data that will just be filtered or sampled out afterward wastes work — filtering first, then batching only what's actually going to be exported, is more efficient
• C. batch position has no effect on efficiency, only on log verbosity
• D. Because the Collector enforces batch as the last processor and rejects configs that place it elsewhere

Check the answer

B. Processor order is execution order, so batching before you've dropped unwanted data means bundling records you're about to throw away. Putting filtering/sampling processors earlier and batch later avoids that wasted work.

Q33 (Fundamentals). Semantic conventions are published with stability levels, such as experimental and stable. Why does this matter to someone building dashboards or alerts on top of an attribute name?

• A. Stability levels only affect which programming languages support the attribute
• B. An experimental attribute's name or meaning may still change in a future release, so building a permanent dashboard or alert against it carries a real risk of silent breakage later; stable attributes carry a durability guarantee
• C. Stability levels determine how the attribute is encrypted in transit
• D. They have no practical effect — all attributes behave identically regardless of stability level

Check the answer

B. The stability marker is a promise (or lack of one) about whether the name and semantics will hold going forward — treating an experimental attribute as a permanent contract is how dashboards quietly break on a semantic-convention upgrade.

Q34 (API & SDK). What is the primary design reason the OpenTelemetry API is a no-op by default, separate from the SDK that actually implements it?

• A. To reduce the binary size of the SDK
• B. So a library author can instrument their library against the API alone, without forcing every consumer of that library to pull in a specific telemetry vendor or SDK dependency
• C. Because the API and SDK must always ship as two separate language runtimes
• D. To make the API compatible with non-OTLP wire protocols only

Check the answer

B. The API/SDK split exists so instrumentation can be embedded deep in shared libraries without imposing a telemetry backend choice on every application that imports them — the SDK is opt-in, wired up once by the application itself.

Q35 (Debugging). A trace that should span three services shows two separate, disconnected traces instead — one covering the first service, and a brand-new one starting at the second. What is the most likely root cause?

• A. The second service is using a sampler with too low a ratio
• B. The second service failed to extract the incoming trace context from the request it received, so it started a fresh trace instead of continuing the existing one
• C. The first service's exporter queue is full
• D. The Collector's batch processor split the trace into two exports

Check the answer

B. A trace "snapping" at a service boundary is the signature symptom of a missing or failed context extraction — the receiving service never read the incoming traceparent, so its instrumentation had nothing to attach to and started a new root span instead.

Q36 (API & SDK). An SDK's propagator list is left unconfigured. What does OpenTelemetry use by default?

• A. B3 single-header propagation only
• B. W3C Trace Context and W3C Baggage (tracecontext,baggage)
• C. No propagator is enabled by default; one must always be explicitly configured
• D. Jaeger's proprietary propagation format

Check the answer

B. The spec's default OTEL_PROPAGATORS value is tracecontext,baggage — W3C Trace Context for the trace itself and W3C Baggage for user-defined context. b3 and others are opt-in additions, typically added during a migration off an older tracing system.

Q37 (Collector). Which of the following is an example of a Collector extension, as distinct from a receiver, processor, exporter, or connector?

• A. otlp
• B. batch
• C. health_check
• D. spanmetrics

Check the answer

C. Extensions add capabilities outside any data path — health_check exposes a readiness/liveness endpoint, unlike otlp (a receiver), batch (a processor), or spanmetrics (a connector), all of which sit directly in a pipeline's flow of records.

Q38 (Fundamentals). A team is choosing between manually adding OpenTelemetry API calls throughout their code and using zero-code/automatic instrumentation. What is the main trade-off?

• A. Zero-code instrumentation is always strictly better in every way, with no downside
• B. Manual instrumentation gives finer control over exactly which operations and attributes are captured, at the cost of developer effort; zero-code instrumentation is faster to deploy broadly but generally captures a more generic, library-boundary view
• C. Manual instrumentation cannot use the OpenTelemetry API at all
• D. Zero-code instrumentation only works for metrics, never for traces

Check the answer

B. Both are legitimate and commonly combined — automatic instrumentation gets broad, immediate coverage of library boundaries (HTTP frameworks, database clients) with near-zero effort, while manual spans and attributes capture business-specific detail automatic instrumentation can't know about.

Q39 (API & SDK). A background job picks up a message from a queue and needs to continue the trace of the request that originally enqueued it, potentially minutes later. What OpenTelemetry mechanism is designed for this kind of asynchronous, non-parent-child relationship between spans?

• A. Baggage
• B. A span link, connecting the new span to the causally related trace without making it a strict parent-child relationship
• C. The memory_limiter processor
• D. Increasing the sampler's ratio

Check the answer

B. Links exist for exactly this case — async boundaries like queues and background jobs, where strict parent-child nesting doesn't fit the timing, but the two spans are still causally related and worth connecting.

Q40 (Collector). A Collector fleet uses the prometheus receiver across multiple replicas, scraping thousands of targets. Naively, every replica would scrape every target redundantly. What OpenTelemetry Operator feature solves this by sharding scrape targets across replicas?

• A. The loadbalancing exporter
• B. The target allocator
• C. tail_sampling
• D. The k8sattributes processor

Check the answer

B. The target allocator is the Operator component built specifically for this problem — it shards the set of scrape targets across Collector replicas so each target is scraped once, not once per replica. loadbalancing solves a related but distinct problem: routing spans of the same trace to the same replica.

Q41 (API & SDK). A Resource attached to a TracerProvider carries a schema_url. What is the practical purpose of that field?

• A. It's the URL the exporter sends telemetry to
• B. It identifies which version of the semantic conventions the telemetry's attribute names and values follow, so downstream tooling can interpret them correctly even as conventions evolve
• C. It's a required field with no functional effect, kept only for documentation
• D. It specifies which Collector receiver must process this data

Check the answer

B. Schema URLs are where schema management starts — as attribute names and meanings evolve across convention versions, the schema URL tells a consumer which version's rules to apply, letting old and new telemetry stay interpretable side by side during a migration.

Q42 (Debugging). A fleet is mid-migration between two versions of the semantic conventions, with some services still emitting the old attribute names and others already emitting the new ones. What does OpenTelemetry provide to keep both generations of telemetry queryable together during that transition?

• A. Nothing — every service must be upgraded simultaneously in a single flag-day cutover
• B. Machine-readable schema files describing the transformations between convention versions, referenced via each Resource's schema URL, letting tooling translate between old and new names
• C. The memory_limiter processor, which automatically rewrites old attribute names
• D. A manual spreadsheet mapping old names to new ones that engineers must consult by hand

Check the answer

B. OpenTelemetry publishes versioned, machine-readable schema files describing exactly how attributes changed between convention versions. Combined with the schema URL on each Resource, tooling can translate telemetry produced under an old version into the new shape without forcing every service to upgrade at once.

Q43 (API & SDK). An asynchronous (observable) metric instrument, such as an ObservableGauge, is registered with a callback function. When does that callback actually run?

• A. Once, at process start-up, and never again
• B. On every single method call in the application, regardless of export timing
• C. At export time — the SDK invokes the callback to collect the current value(s) each time metrics are being exported, not continuously
• D. Only when a human manually triggers it via an API call

Check the answer

C. Asynchronous instruments are callback-driven precisely so the SDK can pull a current value only when it's actually about to export — avoiding the overhead of the application pushing a value on every change, which is the synchronous instruments' job instead.

Q44 (Collector). A platform team wants a Collector instance with direct, low-latency access to node- and pod-level metadata — for a k8sattributes processor to enrich telemetry with k8s.pod.name and k8s.node.name before anything leaves the node. Which deployment shape fits best?

• A. No Collector at all — SDKs exporting straight to the backend
• B. Agent deployment — a Collector per node (DaemonSet) or per pod (sidecar), close to the workloads it's enriching
• C. A single centralized gateway Collector, with no per-node presence
• D. Running the Collector only inside the CI/CD pipeline

Check the answer

B. An agent-shaped Collector — DaemonSet or sidecar — is the only deployment mode with direct, low-latency access to node- and pod-level context. A central gateway is the right place for fleet-wide work like tail sampling and redaction, but it doesn't sit close enough to the workload to attach that local metadata cheaply.

Q45 (API & SDK). Two microservices in the same call chain are each independently configured with TraceIdRatioBased(0.1) as their sampler — neither wrapped in ParentBased. What is the likely consequence for a single end-to-end trace?

• A. Nothing — both services will always make the same sampling decision for the same trace, because the ratio is identical
• B. Each service makes its own independent sampling decision on the same trace ID, so a trace can easily end up sampled in one service and dropped in the next, fragmenting it
• C. The trace is guaranteed to be sampled in full, because at least one of the two services will keep it
• D. TraceIdRatioBased cannot be used without ParentBased, so the SDK will refuse to start

Check the answer

B. Without ParentBased, each service evaluates the ratio independently rather than deferring to the parent's decision — for a single trace this can mean service A samples it and service B doesn't (or vice versa), leaving a trace that's whole in one place and missing in the next. Wrapping in ParentBased is what keeps a decision consistent end to end.

Score yourself

☺ Like you're 10: Count your correct answers out of 45, compare against the real 75% pass mark, then look at which of the four systems cost you the most points — that second part is the useful part.

The Linux Foundation's Multiple Choice Exam FAQ states plainly that "a score of 75% or above must be earned to pass the Multiple Choice Exam," and that requirement covers every LF multiple-choice exam, OTCA included. On a 45-question paper, 75% of 45 is 33.75 — so 34 out of 45 (75.6%) is the number to clear, and clearing it by more than a hair is the sensible target, because this paper's difficulty is not calibrated to the real one: the wording is ours, not the CNCF's, and 75% here is not the same event as 75% there.

Before you total anything: the domain split below — 21 / 12 / 8 / 4 — comes from applying the official 46/26/18/10% weights to 45 questions. The raw shares are 20.7, 11.7, 8.1, and 4.5, and only one of those rounds cleanly. API & SDK (20.7) and Collector (11.7) round up to 21 and 12; Fundamentals (8.1) rounds down to 8. That leaves Debugging's 4.5 as an exact tie — rounding it up would push the paper to 46 questions, so it's rounded down to 4 to land the total on exactly 45. There's nothing principled in that last call; it's the arithmetic of hitting the target length, and it's the same split this course's Set 2 paper uses, so the two scores stay directly comparable.

Turning a wrong answer into revision

☺ Like you're 10: For each one you missed, write down why your answer was wrong — not why the right one was right — then go read exactly the page that covers it.

This is the highest-value part of the exercise and almost nobody does it properly. Reading the correct answer produces recognition; writing down, in one sentence, why your own answer failed produces the discrimination that survives to exam day. Group your misses by domain when you're done — three misses in one domain is a revision session; three misses spread across all four is just a normal day. Beyond the domain pages linked in the table above, the practice question bank drills the same traps in isolation — endpoint/protocol mismatches, unwired Collector components, samplers applied without ParentBased — and the study plan turns a weak domain into a scheduled block of reading rather than a vague intention. Once this paper is genuinely solid, not just recently reviewed, move on to Set 2 for a second, independent measurement.

Check your answers

1. Because that's exactly how the CNCF builds the real paper's marks — 46% API & SDK, 26% Collector, 18% Fundamentals, 10% Debugging — so practicing (and scoring) in that same proportion is the closest a study paper can get to the real thing, and it makes a weak domain here point at a genuinely under-weighted revision gap rather than an artifact of even spacing.
2. Nothing published suggests a wrong guess is scored worse than a blank answer on a Linux Foundation multiple-choice exam — so the strategy is unambiguous: never leave a question unanswered. Eliminate what you can, then commit to your best remaining option.
3. Because the Linux Foundation has never published the OTCA's real question count. The 45 here is a study convention calibrated to the one figure that is published — the 90-minute duration — not a stand-in for a number the CNCF has actually stated.
4. Because a flat 75.6% hides where the real gap sits. A domain score of 1/4 is a small sample, but combined with the 10% weight it's still a concentrated, nameable content gap fixable by rereading one page — while the headline average alone wouldn't tell you where to focus at all.
5. Duration, question count, pass mark, price, retake policy, eligibility window, certification validity — and, over a long enough period, the domain weights themselves. Confirm them on the official Linux Foundation OTCA page and the CNCF certification page before registering — they are the only authority.

That's the full sitting. Reset the clock, close every tab except this one, and let the 45 questions above show you exactly which of the four domains is still soft — then go fix precisely that, and nothing else, before you move on to Set 2.