Certifications · OTCA · Mock Exam · Set 2

OTCA Mock Exam · Set 2

Fifty more multiple-choice questions, weighted question-for-question to the same four domains of the official OTCA curriculum as Set 1 — twenty-three on the API and SDK, thirteen on the Collector, nine on Fundamentals of Observability, five on Maintaining and Debugging Observability Pipelines. This is the second of two papers, and it assumes Set 1's baseline is already solid: instead of testing one fact per question, most items here hand you a short scenario — a pipeline that's valid YAML and does nothing, a sampler that's correctly parent-based but still shreds a trace, a Collector that reconciles cleanly and reconciles the wrong thing — and make you notice the one detail that changes the answer. None of these fifty repeat Set 1's questions. The OTCA is a knowledge-based exam — no cluster, no terminal, nothing to break — so this is a question paper you sit cold, in one block, with no notes open. Answer first, then read the explanation directly beneath your choice; it is doing as much teaching as the question itself, and the domain tag on every item tells you exactly which page to reread if you miss it.

How this paper is weighted

☺ Like you're 10: Same split as last time — the biggest chapter still gets the most questions, in the same nice round numbers.

Like Set 1, this paper's fifty questions divide the OTCA's four official domain weights — 46, 26, 18, 10 — with no rounding at all: 23, 13, 9, 5. Keeping the same split across both papers is deliberate, not just tidy: it's what makes a Set 1 score and a Set 2 score directly comparable domain for domain, rather than two numbers on unrelated scales. If the Collector cost you points on Set 1 and costs you points again here, that is not the same mistake happening twice by chance — it's the same real gap, confirmed.

Sit it like the real thing

☺ Like you're 10: Same rules as Set 1 — no notes, no open tabs, one sitting, straight through, never leave a question blank.

Sit this exactly like Set 1: closed-book, one timer, one sitting, no documentation allowance — there's no terminal here for a "browse the docs" concession to apply to in the first place, unlike the hands-on Kubernetes exams this course assumes you've already cleared. The scenario questions in this paper reward reading the whole stem before committing — several are built so that an answer which looks right after the first sentence turns out wrong once you reach the second clue, the same trap Set 1 warned about but sharper here. Slow down by a few seconds per question rather than pattern-matching to the nearest question you remember from Set 1; these are new, and a couple are deliberately shaped to resemble a Set 1 question while testing something different. Never leave a question blank.

The paper — 50 questions across three blocks

☺ Like you're 10: Fifty questions, three blocks, every domain mixed into every block — but more of these stories have two things going on at once, so read the whole thing before you answer.

Each question names its domain in parentheses so you can total your score by domain afterward — the real exam won't label them. A few questions are marked (Select TWO), and a few others deliberately describe a scenario where "nothing is actually wrong" is itself the correct answer — don't assume every stem is hiding a misconfiguration just because the last several were.

Block 1 — Q1–17

Q1 (API and SDK). A span carries service.name=checkout as an attribute directly on the span itself, rather than on the Resource. What's the practical problem with this placement, compared to the same value set correctly on the Resource?

• A. There is no practical difference — spans and Resources share one flat attribute namespace
• B. Nothing describing "what produced this telemetry" travels with metrics or logs from the same process, because the Resource — not a per-span attribute — is the layer shared identically across every signal a process emits; a per-span attribute has to be repeated by hand on every single span, metric and log record instead of being attached once
• C. It causes the SDK to silently discard the span at export time
• D. It automatically becomes the InstrumentationScope's name instead

Check the answer

B. Resource identity is attached once, to the provider, and every signal that provider emits inherits it — that's the entire point of the layer existing separately from per-record attributes.

Q2 (Collector). A Collector config file declares blocks under receivers, processors, exporters, extensions and connectors. Which of these five is correctly described as acting as the exporter of one pipeline and the receiver of the next, joining two pipelines together?

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

Check the answer

C. A connector like spanmetrics sits between two pipelines by definition — exporter on one side, receiver on the other, inside the same config.

Q3 (API and SDK). A service places an outbound call onto a message queue for another service to consume asynchronously, with no synchronous response expected. Which SpanKind most accurately models the sending side of that call?

• A. SERVER
• B. CLIENT
• C. PRODUCER
• D. INTERNAL

Check the answer

C. PRODUCER (with CONSUMER on the receiving side) models fire-and-forget messaging; CLIENT/SERVER model synchronous request/response, and INTERNAL models work with no remote call at all.

Q4 (Fundamentals of Observability). A team says: "We have full observability — we collect traces and metrics from every service." What is most likely still missing from that claim, and why might it matter for correlating an outage?

• A. Nothing — traces and metrics alone constitute complete observability by definition
• B. Logs — the record type that most often carries free-form detail a stack trace or an error message that traces and metrics don't capture, and structured log correlation via trace ID is what lets you jump from "this trace is slow" to "here's the exact log line explaining why"
• C. Profiling, which OpenTelemetry does not support in any form
• D. Baggage, which is itself a signal type alongside traces, metrics and logs

Check the answer

B. Logs fill in exactly the free-form detail traces and metrics are structurally bad at carrying. (Profiling is a genuine, if newer, fourth signal — not unsupported — and baggage is context, not a signal, which is why C and D are both wrong for different reasons.)

Q5 (Collector). A Collector config defines a filter processor under processors: with statements dropping health-check spans, and the engineer confirms the config is syntactically valid. Spans matching the filter still appear in the backend. What is the single most likely explanation?

• A. The filter processor cannot drop spans, only metrics and logs
• B. The processor is defined but not listed inside the traces pipeline's processors array under service.pipelines, so it's never invoked — a valid config has no bearing on whether a component actually runs
• C. Config validation silently disables any processor it flags as risky
• D. Filter processors only take effect after a Collector restart, and the config was hot-reloaded instead

Check the answer

B. The classic trap: definition and wiring are two separate steps, and only the second one makes a component actually touch data.

Q6 (API and SDK). A developer adds tracing calls to a new microservice, deploys it, and confirms in a debugger that a span-start call executes without error on every request. No spans ever reach the backend. What is the most likely root cause?

• A. The API call itself always requires network access to succeed, and the network call is failing silently
• B. No SDK was ever registered as the global TracerProvider, so the API calls are executing against the default no-op implementation — spans are created and immediately discarded, by design, with no error
• C. The backend is down, which always prevents the API from executing at all
• D. The span-start call only logs locally and was never intended to export anywhere

Check the answer

B. A no-op API executing without error is exactly what "no-op by default" looks like from the inside — nothing is broken, nothing was ever wired up.

Q7 (Maintaining and Debugging Pipelines). Spans stop arriving at a backend an hour after a Collector redeploy, with no application-side errors reported. Before touching any exporter config, what is the single fastest first diagnostic step, and why?

• A. Re-instrument every application service from scratch, since the fault is almost always the SDK
• B. Check the Collector's own telemetry for accepted, refused and dropped counts per receiver and exporter — it localizes the fault to receiver, processor or exporter in one look, before you touch any application code
• C. Delete and recreate the Collector's Kubernetes namespace
• D. Assume the backend's ingestion API changed and immediately open a support ticket with the vendor

Check the answer

B. The Collector's self-telemetry is the fastest, cheapest signal available, and it tells you which stage of the pipeline to look at next.

Q8 (API and SDK). A team wants an asynchronous, callback-driven instrument reporting request-latency distribution once per collection interval, matching the pattern they already use for an observable gauge reporting queue depth. Which OpenTelemetry metric instrument supports that asynchronous form?

• A. Histogram — every instrument has both a synchronous and an asynchronous form
• B. None of the four instruments support an asynchronous form for distributions
• C. There is no asynchronous histogram — counter, up-down counter and gauge each have an observable/asynchronous form, but histogram is synchronous only, so a latency distribution has to be recorded synchronously, at the point of measurement
• D. Only an observable counter supports distributions

Check the answer

C. The sync-only histogram is the classic asymmetry the exam tests — it's the one instrument with no observable counterpart.

Q9 (Collector). A Collector's traces pipeline lists its processors as [batch, memory_limiter]. Under sustained high load, what's the most likely consequence of this ordering compared to [memory_limiter, batch]?

• A. None — processor order inside a pipeline's list has no effect on behavior
• B. memory_limiter runs after batch has already buffered data in memory, so the load-shedding meant to protect the Collector's heap only engages after memory pressure has already built up from batching — the opposite of the intended "shed early" behavior
• C. batch silently ignores its position and always runs last regardless of list order
• D. This ordering doubles export throughput

Check the answer

B. memory_limiter belongs first precisely so it can shed load before anything downstream — including batch — gets a chance to consume more memory.

Q10 (Fundamentals of Observability). Two teams instrument their own services independently using different attribute names for the same HTTP concepts. A shared dashboard built against one naming scheme silently shows zero data for the other team's service. What does this scenario demonstrate about the purpose of semantic conventions?

• A. Semantic conventions are purely cosmetic and this failure is unrelated to them
• B. Agreed, standard attribute names are what let one dashboard or alert work unmodified against any conformant service — without them, every consumer of the data has to know and handle each producer's private naming choices
• C. This proves semantic conventions apply only to metrics, never to traces
• D. The fix is always to rename the older team's attributes, since newer names are automatically correct

Check the answer

B. Shared naming is the entire value proposition — a dashboard written against conventional names should work regardless of which conformant service produced the data.

Q11 (API and SDK). A team debugging a flaky exporter in a local dev environment temporarily swaps their production batch span processor for a simple span processor. What trade-off are they making, and why is this the right call for debugging specifically, not production?

• A. None — the two processors behave identically in every environment
• B. The simple processor exports each span synchronously and individually as it ends, trading throughput and batching efficiency for immediate, one-to-one visibility into exactly what's being exported — valuable for a debugging session, costly at production volume
• C. The simple processor is strictly newer and should replace the batch processor everywhere
• D. The simple processor buffers spans until shutdown, unlike the batch processor

Check the answer

B. One-at-a-time, synchronous export is exactly what you want while debugging and exactly what you don't want at production volume.

Q12 (Collector). A Collector's otlp receiver block only defines a grpc: key under protocols:, with no http: key present. An application configured to speak OTLP over HTTP pointed at this Collector fails to connect. What's the most direct explanation?

• A. The otlp receiver always accepts both protocols regardless of what's declared under protocols:
• B. Only the protocols explicitly declared under the receiver's protocols: block are enabled — since no http: key is present, the Collector isn't listening for HTTP OTLP at all, independent of any port number the application might be using
• C. HTTP and gRPC always share the same listener automatically
• D. The mismatch is unrelated to receiver configuration and is purely a firewall issue

Check the answer

B. A protocol not listed under protocols: is a protocol the receiver simply isn't listening for.

Q13 (API and SDK). Service A calls Service B calls Service C. All three use a parent-based ratio sampler at 10%. Service A's request is the trace root and gets sampled in. What sampling decision do B and C make for their spans in that same trace, and why?

• A. Each independently re-rolls its own 10% ratio decision, so B or C may drop their spans even though A's was sampled
• B. Because the sampler is parent-based, B and C honor A's already-made sampled decision and also sample in — the ratio only applies when there is no parent context to defer to, such as at the trace root
• C. B and C always sample out regardless of A's decision, since ratio sampling only applies to root spans
• D. Parent-based sampling ignores the parent entirely and applies the ratio independently at every hop

Check the answer

B. This is exactly why parent-based sampling exists — an independent per-service ratio decision is what shreds traces into fragments; deferring to the parent is what keeps a trace whole end to end.

Q14 (Maintaining and Debugging Pipelines). A Collector's otlp/backend exporter has a bounded in-memory sending queue with no file_storage extension configured, and retries enabled. The backend goes down for six hours. What happens to telemetry received during that outage, once the queue fills?

• A. It's held indefinitely in memory until the backend recovers, however long that takes
• B. The in-memory queue is bounded and not persisted to disk without a file_storage extension backing it — once full, and once retries are exhausted for the oldest items, further data for that exporter is dropped, not held forever
• C. It's automatically rerouted to the debug exporter as a fallback
• D. The Collector crashes and restarts to clear the backlog

Check the answer

B. Telemetry pipelines are lossy by design under sustained backpressure; the choice is where you accept the loss, not whether you can avoid it entirely without persistent backing.

Q15 (Fundamentals of Observability). An engineer adds a customer email address as a span attribute on every HTTP request span, reasoning it will make it easy to filter traces per customer. What's the most likely operational problem this introduces?

• A. None — more attributes always improve query flexibility with no downside
• B. A high-cardinality, effectively-unique-per-request attribute value inflates the number of distinct attribute combinations a backend has to index, which can blow up storage and query cost — separate from the fact that putting personal data into telemetry is also a data-handling problem in its own right
• C. Span attributes have a hard length limit that this value would violate
• D. It causes the SDK to reject the span at creation time

Check the answer

B. Unbounded, near-unique attribute values are the textbook cardinality failure — and instrumentation quality is exactly what this competency is checking.

Q16 (API and SDK). An application sets its OTLP endpoint to port 4317 and its OTLP protocol to HTTP/protobuf. Telemetry never arrives, with no error surfaced to the application. What's the most likely cause?

• A. Port 4317 is conventionally the gRPC OTLP port; an HTTP protobuf exporter pointed at it is talking the wrong protocol to whatever's listening on that port, and the mismatch fails silently from the application's point of view
• B. 4317 is invalid for any OTLP protocol and the SDK would raise a startup error
• C. The endpoint and protocol settings are mutually exclusive and one is simply ignored, with no consequence
• D. OTLP over HTTP does not exist as a valid exporter protocol

Check the answer

A. Endpoint and protocol are two separate settings that must agree; a mismatch like this is one of the most common real-world (and exam) misconfigurations.

Q17 (API and SDK, Select TWO). Which TWO statements accurately describe how OpenTelemetry's logging support differs from its tracing and metrics support?

• A. OpenTelemetry ships no user-facing logging API of its own — it's designed to bridge whatever logging library an application already uses, rather than replace it
• B. A LogRecord can carry trace-context fields, which is what lets a specific log line be correlated back to the exact span that was active when it was written
• C. Logs are the only signal that cannot be exported over OTLP
• D. Logs require their own separate Resource, entirely disconnected from the Resource used by that process's traces and metrics
• E. LogRecord has no timestamp field, only a severity field

Check the answer

A and B. The bridge design and the trace-correlation fields are the two defining, testable facts about logs specifically. Logs export over OTLP like any other signal (C is wrong), share the same Resource layer as everything else from that process (D is wrong), and carry both a timestamp and an observed timestamp (E is wrong).

Block 2 — Q18–34

Q18 (API and SDK). A support engineer captures a traceparent header ending in the two hex characters 01. Which field of the header does that final byte represent, and what does the value shown indicate?

• A. The trace ID's sampling seed, encoded at the start of the string
• B. The trace-flags field — bit 0 set (01) means the sampled flag is on for this trace
• C. The 16-byte segment in the middle, which is itself the sampling decision encoded as hex
• D. There is no sampling information in traceparent; it lives exclusively in tracestate

Check the answer

B. Version, trace ID, span ID, then trace flags — the last field, where the low bit is the sampled flag.

Q19 (Fundamentals of Observability). An SRE team wants to know, from telemetry alone, whether a service is currently healthy enough to keep taking traffic. Per the RED method commonly cited under Analysis and Outcomes, which three signals do they look at together, and why not just one?

• A. CPU, memory and disk — because infrastructure metrics alone define service health
• B. Rate, Errors and Duration — because a service can look fine on any one of the three (high rate but also high errors, or low errors but high latency) while still failing users, so the three are read together rather than in isolation
• C. Only Errors, since error rate alone always implies rate and duration are fine
• D. Rate and Errors only; Duration belongs to a completely unrelated framework

Check the answer

B. Each of the three can individually look healthy while masking a real problem visible only in one of the others — that's exactly why RED reads them together.

Q20 (Collector). A platform team wants every pod's traces enriched with pod- and node-level metadata, with the lowest possible network hop before that enrichment happens. Which Collector deployment shape most directly supports that, and which component actually adds those attributes?

• A. A single centralized gateway Collector, using the batch processor
• B. An agent Collector — DaemonSet or sidecar, running local to the workload — using the k8sattributes processor, which attaches pod- and node-level metadata before the data leaves that node
• C. No Collector at all; the application SDK always knows its own node name automatically
• D. A gateway-only deployment using the routing connector

Check the answer

B. Local enrichment is exactly what an agent architecture is for, and k8sattributes is the component that does the enriching.

Q21 (API and SDK). A team wants to track the current number of in-flight requests a service is handling, read via a callback at each collection interval rather than incremented and decremented inline in request-handling code. Which instrument fits, and why not a plain synchronous counter?

• A. A synchronous counter, because counters can decrease as well as increase
• B. An asynchronous (observable) up-down counter — its value can go up or down, unlike a plain counter which is monotonic, and the async form lets a callback report the current in-flight count at collection time instead of requiring an increment/decrement call at every request boundary
• C. A histogram, since in-flight count is a distribution
• D. An asynchronous gauge is the only instrument that supports negative deltas

Check the answer

B. Non-monotonic value, reported by callback rather than inline calls — that's precisely the observable up-down counter's use case.

Q22 (Collector). A security team wants PII redaction applied consistently to telemetry from four hundred microservices, in one place, rather than replicated into every application's SDK configuration. Which Collector deployment shape suits this, and what's the corresponding cost?

• A. Running redaction only in each application's SDK, which is simpler and has no downside
• B. A gateway Collector running the redaction logic centrally, behind agents that forward to it — the cost is that a bug or outage in that one gateway now affects every one of those four hundred services at once, rather than being isolated to one
• C. There is no way to centralize redaction; it must always happen in application code
• D. Agents alone, with no gateway, achieve the same centralization

Check the answer

B. A gateway is exactly the right place to centralize fleet-wide policy — and centralizing anything also centralizes the blast radius.

Q23 (API and SDK). A team merges a base Resource carrying service.name with a second Resource built from environment variables carrying deployment.environment.name and service.version. What does the merged Resource end up describing, and where does that merged identity attach?

• A. Nothing changes — resources cannot be merged after creation
• B. A single combined Resource attached once to the provider, so every signal that provider emits carries the same combined identity without repeating it per span or metric
• C. Two separate, independently-exported Resources, one per source
• D. The environment-variable values silently overwrite and discard the explicit code-level values in all cases

Check the answer

B. Resources merge into one combined identity, attached once — that single attachment point is the whole reason the layer is useful.

Q24 (Maintaining and Debugging Pipelines). A request handler places a job onto an internal in-memory queue for a background worker pool to process later, with no explicit context carried alongside the job. When the worker eventually processes it and creates a span, what happens to that span's place in the original trace, and what's the standard fix?

• A. Nothing — the worker's span automatically finds its way back into the original trace with no extra work
• B. The worker's span starts a brand-new, unrelated trace, because Context — including the active span — lives in-process and isn't automatically carried across a queue hand-off; the fix is to explicitly capture and pass the context alongside the job and either continue it or attach a span link when processing it
• C. This scenario is impossible; SDKs propagate context across any queue automatically by default
• D. The fix is always to disable sampling for background workers

Check the answer

B. Async boundaries are one of the classic places a trace snaps in two — context has to be explicitly carried, it isn't ambient.

Q25 (Fundamentals of Observability). A team wants traces for an off-the-shelf third-party HTTP client library they don't control the source of, with minimal engineering effort, accepting slightly less precise span boundaries than hand-written instrumentation would give. Which general instrumentation approach fits, and what's the trade-off?

• A. Manual instrumentation — hand-writing spans inside the library's source is always less effort
• B. Automatic (zero-code) instrumentation — it hooks into common libraries without source changes and gets you working spans fast, at the cost of the fine-grained, business-specific span shape hand-written manual instrumentation gives you inside your own code
• C. There's no way to instrument code you don't control at all
• D. Automatic instrumentation only ever works for logs, never for traces

Check the answer

B. Speed and coverage versus precision is exactly the trade-off zero-code instrumentation makes.

Q26 (API and SDK). A team needs to export spans to an internal, proprietary telemetry ingestion API that has no existing OpenTelemetry exporter. What does OpenTelemetry's composability model let them do about it, without forking the SDK?

• A. Nothing — only officially bundled exporters can ever be used with an OpenTelemetry SDK
• B. Implement a custom exporter against the SDK's exporter interface and register it with a span processor exactly as they would a bundled one — exporters, like samplers and processors, are a defined extension point precisely so a proprietary backend doesn't require modifying OpenTelemetry itself
• C. Custom exporters are supported only for metrics, never for traces
• D. They would need to run a second, entirely separate SDK alongside the first

Check the answer

B. Pluggable interfaces at every stage of the pipeline are the whole point of the Composability and Extension competency.

Q27 (Collector). A platform team wants RED-style request-rate and error-rate metrics derived automatically from trace data, without instrumenting every service a second time just for metrics. Which Collector component is purpose-built for this, and how does it fit into the pipeline model?

• A. The batch processor, configured with a metrics flag
• B. The spanmetrics connector — it acts as the exporter of the traces pipeline and the receiver of a metrics pipeline in the same config, deriving metrics from spans as they pass through, rather than requiring a second round of application instrumentation
• C. A second full OpenTelemetry SDK deployed exclusively for metrics
• D. The health_check extension, which exposes derived metrics as a side effect

Check the answer

B. A connector deriving metrics from an existing trace pipeline is exactly the "RED metrics for free from traces" pattern.

Q28 (API and SDK). A platform team wants every pod in a namespace with a given annotation to receive Java zero-code instrumentation automatically, without editing each application's Deployment spec by hand. What OpenTelemetry Kubernetes mechanism achieves this, and where does the triggering annotation actually go?

• A. A ConfigMap mounted into every pod, edited manually per service
• B. The OpenTelemetry Operator, via an Instrumentation custom resource plus an injection annotation placed on the pod template — not the Deployment's own top-level metadata — where the Operator's mutating webhook adds an init container that copies the agent in and sets the required environment variables
• C. A sidecar container manually added to every Deployment YAML
• D. Zero-code injection is not possible on Kubernetes under any mechanism

Check the answer

B. The pod-template annotation, not top-level Deployment metadata, is the detail this exact question is designed to catch you on.

Q29 (Fundamentals of Observability). A metric, a span, and a log record from the same process all carry the same attribute key, using the same value and semantics in each. What does this consistency demonstrate about semantic conventions as a competency?

• A. Semantic conventions apply exclusively to traces, so this consistency is coincidental
• B. Semantic conventions are cross-signal by design — the same agreed name and meaning for an attribute is meant to hold whether it appears on a span, a metric data point, or a log record, which is exactly what makes correlating the three around one request possible
• C. Attribute names are randomly assigned per signal and any overlap is accidental
• D. This consistency only happens if all three signals are exported through the same Collector pipeline

Check the answer

B. One shared vocabulary across all three signals is what lets you correlate them at all — that's the design, not a coincidence.

Q30 (Collector). A gateway tier runs three Collector replicas behind a plain round-robin load balancer, each running tail sampling. Spans of the same trace often arrive at different replicas, and the tail-sampling decisions come out inconsistent per trace. What's the architectural fix, and why does plain round-robin fail here?

• A. Increase the exporter's queue size; that alone resolves the inconsistency
• B. Replace the round-robin tier with a loadbalancing exporter routing by trace ID upstream of the tail-sampling replicas, so every span belonging to one trace lands on the same replica — tail sampling needs the whole trace in one place to decide, and plain round-robin scatters a single trace's spans across replicas with no such guarantee
• C. Tail sampling is inherently incompatible with any multi-replica Collector deployment
• D. Switch from tail sampling to the batch processor, which has no affinity requirement

Check the answer

B. Trace-ID-based routing to a consistent downstream replica is the standard fix for exactly this stateful-processing affinity problem.

Q31 (API and SDK). During a migration, half of a fleet's services still run an older tracing library that only understands B3 headers, while the newer half uses W3C Trace Context. A team configures the newly-migrated services' propagators to accept both formats. What does this achieve?

• A. It disables propagation entirely, since only one propagator can be active at a time
• B. It lets the newly-migrated services extract and inject both header formats simultaneously, so traces stay unbroken across the boundary between not-yet-migrated (B3) and migrated (W3C) services during the transition
• C. Only a single propagator value is ever valid; a combined configuration is invalid
• D. It forces every downstream service to also adopt B3 regardless of its own configuration

Check the answer

B. Speaking both formats during a migration window is exactly why a propagator list, not a single value, is supported.

Q32 (Maintaining and Debugging Pipelines). An organization renames an attribute across its semantic conventions and rolls the change out gradually over several months. Old telemetry recorded before the rollout and new telemetry recorded after it both need to remain queryable together on the same dashboard. What OpenTelemetry mechanism exists specifically to support this kind of transition?

• A. There is no such mechanism; old and new telemetry can never coexist and old data must be deleted
• B. A schema URL recorded on the Resource identifies which convention version a given batch of telemetry was produced against, and OpenTelemetry publishes machine-readable schema files describing the transformation between versions — letting tooling translate between old and new names instead of forcing a flag-day rename across the whole fleet
• C. The Collector automatically renames every attribute to the latest convention with no configuration required
• D. Schema versioning applies only to metrics, never to traces or logs

Check the answer

B. Schema URL plus published schema files is the whole mechanism — it's what lets a fleet migrate gradually instead of all at once.

Q33 (API and SDK). A span representing an HTTP request has a five-second gap in the middle where it's waiting on a rate limiter, and separately the request was triggered as a side effect of a completely different, earlier trace that isn't its direct parent. Which two span features are the right fit for annotating each of these, respectively?

• A. Both should use span links — links can represent gaps in time
• B. An event, timestamped mid-span, for the rate-limiter wait — a note attached to a moment inside the span's own lifetime — and a link, connecting to the earlier, causally-related but non-parent trace, since links join a span to a related trace outside strict parent-child structure
• C. Both should be modeled as separate child spans with zero duration
• D. Neither can be represented; OpenTelemetry only supports linear parent-child spans

Check the answer

B. Events are timestamped notes inside a span's own lifetime; links join a span to a causally related trace when parent-child doesn't fit — two different tools for two different problems.

Q34 (API and SDK). A latency dashboard shows a sharp spike in a histogram's p99 bucket. Without exemplars, an engineer would need to search logs and traces around that timestamp by hand to find a matching slow request. What do exemplars add to the metric data point that removes that manual search step?

• A. A screenshot of the dashboard at the moment of the spike
• B. A trace ID (and span ID) attached directly to the metric data point that fell into that bucket, letting the engineer click straight from the spike into the exact trace that produced it, with no timestamp-based guessing
• C. An automatically-generated root-cause explanation in plain English
• D. A second, duplicate copy of the histogram at higher resolution

Check the answer

B. A trace ID carried on the metric point is exactly what turns "click the spike" into "land in the trace."

Block 3 — Q35–50

Q35 (API and SDK). Two Resource objects, each carrying a different schema URL, are merged, and the SDK raises a schema URL conflict rather than silently picking one. What is the SDK protecting against by refusing to resolve this automatically?

• A. Nothing real — this is an arbitrary restriction with no purpose
• B. Silently picking one schema version could misattribute the meaning of attributes drawn from the version that got discarded — the conflict forces an explicit resolution rather than quietly producing telemetry whose Resource claims one schema version while actually mixing conventions from two
• C. Schema URLs are purely cosmetic metadata with no semantic meaning attached to conflicts
• D. The merge always silently prefers whichever Resource was created first

Check the answer

B. A schema URL is a claim about what an attribute means — silently mixing two claims is exactly the failure a hard conflict prevents.

Q36 (Collector). A Collector fleet uses the prometheus receiver to scrape a large, dynamic set of Kubernetes pods across multiple Collector replicas. Without any additional coordination, what problem arises, and what OpenTelemetry Operator feature addresses it?

• A. No problem arises; the prometheus receiver automatically deduplicates scrapes across replicas with no configuration
• B. Every replica would scrape every discovered target independently, producing duplicate data — the Operator's target allocator addresses this by sharding the set of scrape targets across replicas, so each pod is scraped by exactly one replica
• C. The fix is to run only a single Collector replica for Prometheus scraping, permanently
• D. This is solved entirely by the batch processor, unrelated to scrape target assignment

Check the answer

B. Sharding scrape targets is the mirror image of the tail-sampling affinity problem — here you want targets split apart, not spans kept together.

Q37 (Fundamentals of Observability). A team defines an SLO: "99.9% of checkout requests complete in under 400ms over a rolling 30 days," derived from telemetry already being collected. What is the SLI in this statement, precisely, and how does it differ from the SLO itself?

• A. They're the same thing under two different names
• B. The SLI is the underlying measurement being tracked — the proportion of checkout requests completing under 400ms; the SLO is the target threshold applied to that measurement (99.9%) over a defined window — the SLI is what you measure, the SLO is the bar you've set for it
• C. The SLI is the 30-day window; the SLO is the 400ms figure
• D. SLIs apply only to availability, never to latency

Check the answer

B. Measurement versus target is the exact distinction — and it's a distinction the exam expects you to hold precisely, not gesture at.

Q38 (API and SDK). A short-lived batch job creates several hundred spans, finishes its work, and exits the process immediately without flushing the SDK first. What is the most likely outcome for those spans, and why?

• A. All spans are guaranteed to export regardless, since the batch processor flushes automatically on any process exit
• B. Whatever spans were still sitting in the batch processor's in-memory buffer, not yet flushed to the exporter, are lost — the buffering that makes batching efficient in steady state is exactly what makes an abrupt, unflushed exit lossy
• C. Spans are written synchronously to disk the instant they're created, so exit timing is irrelevant
• D. This only affects metrics, never traces

Check the answer

B. An unflushed exit is the single most common way a short-lived process loses its own telemetry.

Q39 (Collector). A transform processor rewrites a specific attribute value to a redacted placeholder whenever it matches a given condition, and the pipeline correctly lists transform in its processors array. What should an engineer expect to see downstream, for a span whose attribute matches that exact condition?

• A. Nothing changes — OTTL conditions cannot reference span attributes
• B. That span's attribute value is rewritten before export, since the condition matches and the statement is inside a correctly-wired pipeline; spans whose attribute doesn't match pass through unchanged
• C. The entire span is dropped, not just the one attribute
• D. transform can only modify resource attributes, never span attributes

Check the answer

B. A correctly-wired, matching OTTL statement does exactly what it says — rewrites the matched value and leaves everything else alone.

Q40 (API and SDK). Service X runs with only the W3C Trace Context propagator configured. Service Y, which X calls, runs with only B3 configured. What happens to the trace when X calls Y?

• A. They negotiate automatically and settle on a shared format at connection time
• B. X injects a traceparent header; Y, configured only for B3, doesn't know how to extract that header format and fails to find an incoming context, so Y starts a brand-new trace — the trace effectively snaps in two at that boundary, even though both sides are individually configured correctly for their own protocol
• C. The call fails outright with a network-level error
• D. B3 and W3C Trace Context are actually the same wire format under different names, so this causes no issue

Check the answer

B. Two individually-correct configurations can still produce a broken trace when they don't agree on a propagator — that's the point of this scenario.

Q41 (Collector). A filter processor is configured to drop spans whose target path is exactly /healthz, and it's correctly wired into the pipeline. A separate, unrelated span still shows up in the backend, but its actual target path is /health — no trailing "z". What explains this?

• A. The filter processor is broken and needs to be replaced with transform
• B. The condition simply didn't match — OTTL conditions compare exact values, and /health is not equal to /healthz; the span was correctly retained because the filter's own logic says it should be
• C. Filter processors only match on span names, never on attributes
• D. This is the classic unwired-component trap from earlier in the paper

Check the answer

B. Nothing is misconfigured here — an exact-match condition simply didn't match a different string. Not every scenario on this paper is a bug.

Q42 (Fundamentals of Observability). A Collector's k8sattributes processor adds pod, namespace and node identity to incoming telemetry. Which layer of the data model do these attributes correctly belong to, and why does that placement matter for correlating logs, metrics and traces from the same pod?

• A. Span attributes — because only traces need to know their own pod
• B. The Resource — describing "what produced this telemetry" — because attaching it there, once, applies identically to every trace, metric and log record that process emits, rather than needing to be repeated per individual record
• C. InstrumentationScope, since it identifies the instrumenting library
• D. It doesn't matter; any layer works identically for correlation purposes

Check the answer

B. Pod/node identity is "what produced this," which is precisely the Resource layer's job — and exactly why it's attached once rather than per record.

Q43 (API and SDK). An operations team needs to disable telemetry export for one specific service during an active incident, without touching application code beyond restarting it with a new setting. Which environment variable achieves this, and what's the scope of its effect?

• A. A sampler set to "always off," which permanently deletes the sampler configuration
• B. The SDK-wide kill switch, set per process, that disables telemetry generation without requiring a code change beyond restarting with the new environment variable set
• C. There is no way to disable an SDK without redeploying new code
• D. A propagator set to "none," which only affects context propagation, not telemetry generation

Check the answer

B. A per-process, environment-driven kill switch is exactly the tool for "turn this off right now, everywhere this process runs," without a code change.

Q44 (Collector). A platform team wants to run the same Collector configuration as a per-node DaemonSet for local telemetry collection, and separately as a horizontally-scalable gateway Deployment, without hand-writing two entirely separate sets of Kubernetes manifests. What lets them express this declaratively?

• A. This isn't possible; DaemonSet and Deployment Collectors must always be configured as fully separate, unrelated resources
• B. The OpenTelemetry Operator's Collector custom resource, which accepts a mode field — among others, DaemonSet and Deployment — so the same declarative config shape can be applied to either deployment topology
• C. Only Helm, never a CRD, can express this
• D. DaemonSets cannot run the OpenTelemetry Collector under any circumstances

Check the answer

B. The Operator's Collector CRD is exactly what separates "what to run" from "what shape to run it in."

Q45 (API and SDK). A metrics backend expects each exported data point to represent the total accumulated count since the process started, rather than just the increment since the last export. Which aggregation temporality setting matches that expectation, and what's the risk of using the other one against this backend?

• A. Delta — because delta always means "since start"
• B. Cumulative — each point already contains the running total since start; exporting delta temporality to a backend expecting cumulative would make each data point represent only the recent increment, which that backend would likely misinterpret as the new running total, badly undercounting
• C. Temporality has no effect on how a backend interprets counter values
• D. Both settings always produce identical values at the backend

Check the answer

B. Matching temporality to what the backend expects is not cosmetic — get it backwards and every number the backend shows is wrong.

Q46 (Fundamentals of Observability). A candidate assumes OpenTelemetry's four signals — traces, metrics, logs and profiles — are all equally mature and stable, since they're all part of "the same project." What's the more accurate picture?

• A. All four signals reached stability on the exact same release
• B. OpenTelemetry's signals mature at different rates — tracing and metrics have been stable longest, logs stabilized later, and profiling is the newest arrival, meaning its API surface and stability guarantees are still less settled than the older three
• C. Profiling was deprecated and removed from OpenTelemetry entirely
• D. Metrics is the least mature of the four signals

Check the answer

B. Uneven maturity across signals is a real, current fact about the project — not a detail worth assuming away.

Q47 (Collector). A team adds a health-check endpoint and a profiling endpoint under a Collector's extensions: block, and separately lists memory_limiter and batch under processors:. What's the fundamental distinction between what these two categories of component do?

• A. There is no real distinction; extensions and processors are interchangeable terms for the same thing
• B. Processors sit inline in a telemetry pipeline and touch the data flowing through it; extensions provide capabilities that live outside any data path entirely and never see a span, metric, or log record pass through them
• C. Extensions can only be used with the logs pipeline
• D. Processors run once at startup; extensions run continuously

Check the answer

B. "In the data path" versus "outside any data path" is precisely the line that separates processors from extensions.

Q48 (API and SDK). A team's default histogram for request duration uses bucket boundaries poorly suited to their service, which is consistently fast — most data points land in one oversized bucket, making the histogram nearly useless. Without changing any application code, how can they fix the bucket boundaries?

• A. This requires rewriting every call site that records the histogram measurement
• B. A view, configured at the SDK level, can re-aggregate an existing instrument — including specifying custom histogram bucket boundaries — without touching the instrumentation code that creates the measurements in the first place
• C. Bucket boundaries are fixed permanently at instrument-creation time and can never be changed afterward
• D. Only renaming an instrument is possible via a view; bucket boundaries are out of scope

Check the answer

B. Views exist specifically so a poor default like this can be fixed at the SDK configuration layer, with zero instrumentation-code changes.

Q49 (Maintaining and Debugging Pipelines). An engineer suspects a specific attributes processor is silently corrupting span attribute values somewhere mid-pipeline, but every downstream backend just shows the final, already-wrong result. Which two Collector-native tools let them inspect the pipeline's actual live behavior directly, without waiting on backend ingestion?

• A. Only application-side logging; the Collector itself offers no direct inspection tools
• B. The debug exporter at detailed verbosity, added temporarily to the pipeline to print exactly what's being exported at that stage, and zpages, which exposes live in-process pipeline and component state over its own web page — both let you look at data inside the Collector directly, rather than inferring backward from what a backend eventually shows
• C. Only health_check, which reports readiness but nothing about pipeline content
• D. Restarting the Collector repeatedly until the bug happens to not reproduce

Check the answer

B. These are the two purpose-built, in-process debugging tools — reach for them before guessing from backend symptoms.

Q50 (API and SDK). A team configures a service's exporter endpoint via an environment variable in one environment, and via an explicit constructor argument in code in another. Assuming no other conflicting settings, what should the observed behavior be across the two environments?

• A. The code-level setting is always silently ignored in favor of environment variables
• B. Functionally equivalent behavior — most of the SDK's configuration surface is deliberately exposed both ways, precisely so the same application can be configured without a code change in one environment and with explicit control in another; an explicit code-level argument, where provided, generally takes precedence over the environment variable for that same setting
• C. Environment variables only work for the Collector, never for an application SDK
• D. The two mechanisms configure entirely unrelated settings with no overlap

Check the answer

B. Env-var and code-level configuration are meant to be two doors into the same room — that's what makes the SDK deployable without a rebuild in most environments.

Score yourself

☺ Like you're 10: Count your correct answers out of fifty, turn it into a percentage against the real 75% pass mark, then look at which domain cost you the most points — that second part is the part that actually helps.

The Linux Foundation's Multiple Choice Exam FAQ states that a score of 75% or above is required to pass any LF multiple-choice exam, and the OTCA is one. Treat 75% here as a target to clear comfortably, not a calibrated prediction of the real sitting — this paper's wording is ours, not the CNCF's, and it isn't tuned to match the real exam's difficulty.

Whatever you scored, sort your misses into two piles before you move on, because on a paper like this one they mean different things. A question you got wrong because you genuinely didn't know the fact or the mechanism is a real content gap — reread the linked domain page and redo that exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, or missed the second clue in a layered stem under time pressure — is a confidence and reading-speed problem, not a knowledge gap, and the fix is more timed reps, not rereading content you already have. Either way, don't retake this exact paper minutes later; go read first, then come back.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages. Go back to the page, not to the wider internet.

Nothing in this paper examines anything that isn't covered somewhere on this course. The API/SDK and Collector pages carry most of the weight, since they carry most of the exam; Fundamentals leans on the metrics vocabulary PCA covers in depth, and Maintaining & Debugging is mostly the trap-and-toolkit material already inside OTCA — the exam itself.

Beyond the domain pages, the wider revision kit still applies: flashcards for the vocabulary, the self-check quiz for mixed recall, the glossary for anything a question assumed you already knew, and the OTCA study plan for how to sequence all of this against your remaining prep time.

Check your answers

1. The OpenTelemetry API and SDK 46%; The OpenTelemetry Collector 26%; Fundamentals of Observability 18%; Maintaining and Debugging Observability Pipelines 10%.
2. It must be listed inside a pipeline under service.pipelines, for the relevant signal. A component defined but not referenced there parses fine and simply never runs — no warning, no log line.
3. The API is the interface instrumentation calls and is a no-op by default; the SDK is the implementation you register at start-up, holding the provider, sampler, processor(s) and exporter. Instrument without registering an SDK and every span is discarded at creation — no telemetry is produced, and no error is raised.
4. Counter, up-down counter and gauge are each collected by a callback at export time and so naturally support an asynchronous form; a histogram's distribution has to be built up from individual measurements as they happen, which only makes sense recorded synchronously — there is no meaningful "observe a distribution" callback.
5. A service fails to extract an incoming context (starting a fresh trace), or neighbouring services use different propagators that can't read each other's headers; an async boundary where context isn't explicitly carried forward is a third.
6. Both are stateful across the spans of one trace — a tail-sampling decision needs the whole trace, and span-derived metrics need consistent aggregation. The loadbalancing exporter routes by trace ID so all of a trace's spans reach the same downstream Collector replica.
7. Officially published: the 90-minute duration and the 75% pass mark (from the Linux Foundation's Multiple Choice Exam FAQ). Not published: the real question count — any third-party figure for it is unverified. Confirm both, and everything else, on the official Linux Foundation OTCA page and the CNCF certification page before you register.

That's both papers. If you're clearing 75% or better on Set 1 and Set 2 alike, with no domain sagging on both, you have real, cross-checked evidence you're ready — not just one good day. If a domain still sags on both, reread it properly, give it a day to settle, and only then book the real thing.