OTCA Study Plan
The OTCA blueprint lays out what the exam covers. This page turns that into a calendar: three weeks, cut by domain weight rather than domain count, because OTCA's four domains are nowhere near equal. The OpenTelemetry API & SDK (46%) and The Collector (26%) alone are 72% of the paper — two pieces of running software, not two things a highlighter gets you through. Fundamentals of Observability (18%) and Maintaining & Debugging Pipelines (10%) fill the rest, and one competency — Context Propagation — is named inside both the biggest domain and the smallest, which is the curriculum telling you exactly where real pipelines break. Twenty-one days, a day-by-day schedule, an hours budget by weight, a study loop borrowed from the exam's own subject, and a timed mock before you book.
Say you're getting ready for a big camping trip, and almost three-quarters of your packing list is two things: your tent and your stove. You could spend the whole week reading brochures about tents in general — but that doesn't teach you which pole goes where at midnight in the rain. This study plan makes you actually pitch the tent (write real code that makes telemetry) and actually light the stove (run a real Collector and watch data flow through it) before test day, because that's what almost three-quarters of the questions are really asking about. The rest of the list — how camping works in general, and what to do when the stove won't light — still matters. It just gets less of the calendar.
Spend the three weeks where the marks are
☺ Like you're 10: Don't give every domain the same number of days. Give the two big ones — the code that makes the data, and the machine that moves it — most of the calendar.
The OTCA curriculum publishes four domains, twenty competencies, and weights that sum to exactly 100% — and this plan does nothing cleverer than turning that percentage straight into a day count and an hours budget. Read the full domain table and every competency worked out in detail on the OTCA blueprint first if you haven't already — this page assumes you know what each domain covers and focuses purely on pacing it.
Turn those percentages into an actual hours budget and the shape gets concrete. Assume roughly 30 hours of pure domain study across eighteen days (leaving the final three days for revision and a timed mock, which isn't itself a scored domain), split by weight: 46% of 30h is 13.8h, 26% is 7.8h, 18% is 5.4h, 10% is 3h. Rounded to whole hours for a plannable week:
| Domain | Weight | Days | Hours (approx.) |
|---|---|---|---|
| OpenTelemetry API & SDK | 46% | 8 | ~14h |
| The Collector | 26% | 5 | ~8h |
| Fundamentals of Observability | 18% | 3 | ~5h |
| Maintaining & Debugging Pipelines | 10% | 2 | ~3h |
| Revision & timed mock | cross-cutting | 3 | ~5h |
72% of the calendar above — days 1 through 13 — belongs to two pieces of running software: the SDK you configure inside an application, and the Collector you deploy as infrastructure. If your plan for those thirteen days is "read about OpenTelemetry," you've prepared for roughly a quarter of the exam. The other consequence: Context Propagation is the one competency named in two different domains — inside the API & SDK domain and again inside Maintaining & Debugging Pipelines — which is why it gets its own dedicated close-up below rather than being folded quietly into a bigger block.
A quick readiness check before day one
☺ Like you're 10: Twenty-one days is a guess that fits most people. If you already run this stuff at work, you can go faster. If none of it is familiar yet, give yourself more.
Three quick checks before you commit to this exact calendar. If you already instrument your own services with the OpenTelemetry SDK and run a Collector in production, you can likely compress this to fourteen days — most of the API & SDK domain and a good chunk of the Collector domain is muscle memory you already have, so reclaim those days for Fundamentals and Maintaining & Debugging instead, the two domains you're least likely to have hands-on time with day to day. If OpenTelemetry is a name you've heard but never wired into an application, stretch days 1–8 to eleven or twelve rather than eight — the resource/scope/record data model and the API/SDK split need to feel obvious, not just recognized, before Collector configuration will make sense stacked on top of it. If you've never deployed anything to Kubernetes, the Collector's deployment-shapes competency (agent, gateway, the Operator's zero-code injection) will read like a foreign language at first — this plan doesn't assume Kubernetes experience, because none of OTCA's four domains require it directly, but a short detour through the sibling Kubernetes course for Deployments, DaemonSets and Services pays for itself before day 9.
The 21-day schedule
☺ Like you're 10: Here's the whole three weeks on one strip — which days belong to which topic, at a glance.
The bar below is the table beneath it, drawn to scale. Block width is day count, not domain count — the same rule as the hours budget above.
| Days | Focus | What to do |
|---|---|---|
| 1–3 | Data model & signals | Draw the Resource → InstrumentationScope → record sandwich from memory, then list every Span field, every metric instrument, and every LogRecord field without notes. |
| 4–6 | SDK pipeline & configuration | Wire one real service by hand: provider, sampler, batch processor, OTLP exporter, shutdown. Then do it again with environment variables only and confirm the behavior matches. |
| 7–8 | Context propagation | Two services, one call between them. Print the traceparent on both sides, then break it on purpose three separate ways. |
| 9–13 | The Collector (26%) | Write an agent config and a gateway config from scratch and validate them; drill the five component types until you can name examples of each cold. |
| 14–16 | Fundamentals of Observability | Semantic conventions, manual vs. automatic instrumentation, golden signals, RED/USE, SLIs and SLOs — mostly a recognition pass over vocabulary you likely half-know already. |
| 17–18 | Maintaining & Debugging Pipelines | The debugging toolkit, error handling under backpressure, and schema management — a small domain with a fixed, learnable toolkit. |
| 19 | Revision — practice bank | Work the practice question bank untimed. Log every miss by domain, not by question. |
| 20 | Timed mock — Set 1 | Sit Mock Exam · Set 1 under real time pressure, no notes, no pausing. |
| 21 | Patch & decide | Re-drill whichever domain the mock exposed. If the score was close to the line, sit Mock Exam · Set 2 before you book. |
Days 1–8 close-up — the data model and the SDK pipeline
☺ Like you're 10: This is the single biggest slice of the exam — how the data is shaped, and how the code that makes it is wired together.
Days 1–3 — the data model, cold
Every piece of OpenTelemetry data shares the same three-layer shape: a Resource (what produced this — service.name, service.version, k8s.pod.name), an InstrumentationScope (which library emitted it), then the signal record itself. Read that sandwich until you can draw it from memory, then drill the fields of each signal — Span (trace ID, span ID, parent span ID, SpanKind, events, links, status), the four metric instruments (counter, up-down counter, histogram, gauge — histogram is the one instrument with no asynchronous form, a favorite distractor), and LogRecord (timestamp, severity, body, and the trace-context fields that correlate a line with its span).
MY ANSWER (write this first, closed-book) ASK YOURSELF
____________________________________________________ What are the three layers every record shares?
____________________________________________________ Which layer holds service.name?
____________________________________________________ Name all 8 Span fields.
____________________________________________________ Which metric instrument has NO async form?
____________________________________________________ What does a metric exemplar carry?
____________________________________________________ What field lets old and new telemetry stay
queryable together across a convention rename?Every blank you can't fill without peeking is tomorrow's five-minute patch, not a reason to re-read the whole page.
Days 4–6 — the SDK pipeline, wired twice
The single highest-yield idea on this exam: the API is what instrumentation calls, and it's a no-op until an SDK is registered; the SDK is the implementation — provider, sampler, processor, exporter — that you configure at start-up. Wire one pipeline by hand in whichever language you use daily:
resource = Resource.create({"service.name": "checkout", "service.version": "1.4.3"})
exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317") # gRPC endpoint, port 4317
provider = TracerProvider(
resource=resource,
sampler=ParentBased(TraceIdRatioBased(0.1)), # honor the parent, else sample 10%
)
provider.add_span_processor(BatchSpanProcessor(exporter)) # batch: the production default
trace.set_tracer_provider(provider) # register the SDK behind the API
set_global_textmap(CompositePropagator(
[TraceContextTextMapPropagator(), W3CBaggagePropagator()]))
# ... at shutdown:
provider.shutdown() # flush — skip this and you lose whatever hasn't been exported yetNow do it a second time with environment variables only, and confirm the two behave identically — that equivalence is exactly what the exam expects you to know cold:
OTEL_SERVICE_NAME=checkout OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 OTEL_EXPORTER_OTLP_PROTOCOL=grpc # must match the port: 4317 grpc, 4318 http OTEL_TRACES_SAMPLER=parentbased_traceidratio OTEL_TRACES_SAMPLER_ARG=0.1 OTEL_PROPAGATORS=tracecontext,baggage OTEL_SDK_DISABLED=false # the kill switch, per process
Endpoint and protocol are two settings that must agree — gRPC listens on 4317, HTTP on 4318, and a mismatched pair fails silently: no error, no telemetry, nothing to grep for. Build this into your own drill deliberately at least once — set the port to 4317 and the protocol to http/protobuf, run your service, and watch nothing arrive at the other end. Recognizing that failure signature on sight is worth more than memorizing the two port numbers.
Days 7–8 — context propagation, the competency named twice
Inside a process, a Context holds the active span and any baggage. Across a network hop, a propagator serializes it into headers and the receiver deserializes it — the default is W3C Trace Context:
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
| | | |
version trace-id (32 hex chars) span-id (16 hex) flags (01 = sampled)
baggage: user.tier=gold,tenant=acme # plaintext, rides every downstream hop — never secretsRun this two-service drill and break it on purpose three ways. Stop one service from extracting the incoming header — the trace splits into two unrelated halves. Give the two services different propagators (W3C on one side, B3 on the other) — the receiver can't read a header it doesn't understand. Move the second call onto a background queue without carrying context explicitly — the async hop loses it, which is exactly what span links exist to patch when strict parent-child doesn't fit.
Context Propagation is the only competency the curriculum names twice — once inside the 46% API & SDK domain, once inside the 10% Maintaining & Debugging domain. That's the exam telling you, in its own structure, exactly where real pipelines break: not inside one service, but at the seam between two.
Days 9–13 close-up — the Collector's five component types
☺ Like you're 10: The postal worker in the middle of the system has exactly five kinds of parts — learn what each one does and the Collector stops being a mystery box.
Five component types, and knowing them cold covers most of the 26%:
| Type | Job | Recognize these |
|---|---|---|
| Receivers | Get data in | otlp, prometheus, filelog, hostmetrics, k8s_cluster |
| Processors | Change data in flight, in pipeline order | memory_limiter, batch, k8sattributes, transform, tail_sampling |
| Exporters | Send data out to a backend | otlp, otlphttp, prometheusremotewrite, loadbalancing, debug |
| Extensions | Capabilities off the data path | health_check, zpages, file_storage |
| Connectors | Join two pipelines — exporter of one, receiver of the next | spanmetrics, routing, forward |
Write an agent config (DaemonSet-shaped: a light local receiver, minimal processing, forward to a gateway) and a gateway config (heavier processing, real backend exporters) from scratch, no reference open. Then wire this deliberately, delete one line, and predict what breaks before you check:
receivers:
otlp:
protocols: { grpc: { endpoint: 0.0.0.0:4317 } }
processors:
memory_limiter: { check_interval: 1s, limit_percentage: 80, spike_limit_percentage: 25 } # FIRST
k8sattributes: {}
batch: { timeout: 5s, send_batch_size: 8192 } # LAST — batch after filtering, not before
exporters:
otlp/backend: { endpoint: tempo.observability:4317 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, k8sattributes, batch]
exporters: [otlp/backend]A component configured but never listed in a pipeline under service.pipelines simply doesn't run — no warning, no error, no data. Delete batch from the processors: list above but leave its block configured, and nothing about the pipeline's behavior changes at all. This single fact is worth its own flashcard.
Three deployment shapes, and you should be able to argue the trade-off for each. No Collector — SDKs export straight to a backend: simplest, but every service then owns retries and credentials. Agent — one Collector per node or per pod: local, low-latency, the only place that sees pod-level context. Gateway — a scalable Deployment behind a Service: the right place for fleet-wide work like tail sampling and redaction. Most real platforms run both agent and gateway together. One scaling rule is non-obvious and worth memorizing on its own: tail sampling and the spanmetrics connector both need every span of one trace inside a single Collector instance to work correctly — which is exactly what the loadbalancing exporter is for, routing by trace ID to a consistent downstream instance.
Days 14–18 close-up — fundamentals, then maintaining & debugging
☺ Like you're 10: The smallest two domains — but they're about knowing why the data matters, and what to do the moment a pipeline goes quiet.
Days 14–16 — Fundamentals of Observability
Semantic conventions are the agreed names for attributes — service.name, http.request.method, error.type — with published stability levels, and they're the entire value proposition: a dashboard written against conventional names works on any conformant service. Instrumentation splits into manual (you write the spans yourself) and automatic, or zero-code (an agent injects it — Java's -javaagent, Python's opentelemetry-instrument, or the Kubernetes Operator's pod-annotation injection). Analysis and outcomes is where the classic observability vocabulary lives — golden signals (latency, traffic, errors, saturation), RED (rate, errors, duration) for services, USE (utilization, saturation, errors) for resources, and SLIs, SLOs and error budgets for deciding when a number actually means "page someone." Skim this domain fast; it's the one most working engineers already half-know from the job.
Days 17–18 — Maintaining & Debugging Pipelines
Debugging starts with the Collector's own telemetry — counters for accepted, refused and dropped spans localize a fault to receiver, processor or exporter at a glance — then the debug exporter at verbosity: detailed, zpages for live component state, and health_check for readiness. Error handling is about where you accept loss under pressure: the exporter's sending_queue buffers and then drops when full, unless it's backed by the file_storage extension; retry_on_failure retries transient failures with backoff; memory_limiter refuses data outright rather than let the process get OOMKilled. Schema management is the competency almost nobody has met before this exam: telemetry carries a schema URL naming the convention version it was produced against, so a fleet mid-migration can query old and new attribute names together instead of forcing a flag-day rename.
The daily study pipeline — receive, process, export, patch
☺ Like you're 10: Study the same way the exam's own subject works: take material in, process it, check what actually came out the other end, then fix only the broken part.
Rather than inventing a separate technique, this plan points OpenTelemetry's own shape at your memory instead of a pipeline. A well-built Collector doesn't drop data quietly — every component that matters is wired into a pipeline, and anything left unreferenced simply doesn't run. Treat a forgotten fact the same way: find exactly which link is broken, and patch only that.
In practice: read a section once, close the tab, then attempt a blank-page recall or a flashcard pass. Whatever comes out wrong is your dropped span. The next session patches only that gap — not a full re-read — which is the entire efficiency gain a pipeline-shaped loop buys you over passively re-reading everything every night.
On a throwaway cluster (kind or minikube is enough), install a Collector with an otlp receiver and only the debug exporter at verbosity: detailed. Send it traffic and watch spans print to the log. Then run four small experiments and name which competency each one demonstrates: remove batch from the processors list but leave it configured (nothing changes — pipelines); point your sender at port 4317 with the HTTP protocol (silent failure — configuration); add a second Collector as a gateway and forward agent → gateway (deployment); add a transform processor that deletes an attribute with OTTL and confirm it's gone downstream (transforming data). Half an hour, four competencies, in your own hands instead of on a page.
Final three days — revision and a timed mock
☺ Like you're 10: The last three days aren't for learning anything new. They're for finding out, honestly, whether the first eighteen days actually worked.
Day 19: work the OTCA practice question bank at a relaxed pace, untimed, and log every miss by domain rather than by question — a cluster of misses in one domain tells you exactly where day 21's patching should go. Day 20: sit Mock Exam · Set 1 under real conditions — timed, no notes, no pausing — then mark it honestly against the 75% pass mark published for every Linux Foundation multiple-choice exam. Day 21: patch whichever domain the mock exposed, and if the score landed close to the line rather than comfortably above it, sit Mock Exam · Set 2 before you book anything. One score near the line is noise; two consistent scores above it is signal.
"I ran this exact plan and nearly went straight to booking after day 20 — my mock landed at 79%, technically a pass. Then I looked back at the day 19 miss log and saw every single Collector-scaling question wrong, all four of them, just averaged out by a strong SDK section. One more evening on the loadbalancing exporter and tail-sampling affinity, and Set 2 came back clean across every domain. A pass on one mock isn't the same thing as being ready in every domain the exam actually tests."
(Composite, illustrative account — not a specific person's story.)
Exam-day logistics — and what to verify before you book
☺ Like you're 10: Once your three weeks are done, here's what booking the real thing involves — and a reminder to double-check every number before you pay.
These figures match the OTCA blueprint's own logistics table and come from the Linux Foundation's and CNCF's official OTCA pages, read in 2026.
| Item | Detail |
|---|---|
| Format | Knowledge-based, multiple-choice. No cluster, no terminal, no performance tasks. |
| Delivery | Online, remote-proctored from your own machine — system check, room scan, government-issued photo ID. |
| Blueprint | Four weighted domains, 20 competencies — as tabulated above, from the official CNCF curriculum. |
| Prerequisites | None. No prior certification is required, and OTCA doesn't gate anything else in this course's ladder. |
| Pass mark | 75%, per the Linux Foundation's Multiple Choice Exam FAQ — this plan's day-20 mock target matches it exactly. |
| Duration, price, question count, eligibility & validity | Not stated as confirmed for OTCA specifically here — see the warning below before you plan around any of these numbers. |
This is an independent, unofficial study resource — not affiliated with the CNCF or The Linux Foundation. Sibling associate exams (KCNA, KCSA, CGOA) have historically clustered around a 90-minute sitting and a list price near US$250 with one free retake, but that's an observed pattern across those exams, not a published promise about OTCA specifically — and the question count is genuinely unpublished for all of them. Before you register or pay for anything, read the current official Linux Foundation OTCA page and candidate handbook yourself. If anything on this page disagrees with them, they are right and this page is stale.
↗ Official OTCA page — Linux Foundation ◆ CNCF certification page ◆ Multiple Choice Exam FAQ (pass mark)
Foxy: It's multiple-choice, right? No cluster, no terminal — can't I just read the OpenTelemetry docs cover to cover and call it a plan?
Ellie: Read them twice if you like, Foxy — but 72% of this paper is two pieces of running software. Reading about a sampler isn't the same as watching one drop nine spans out of ten.
Gizmo: Or skip the boring config entirely — just memorize "Collector equals middleman" and move on. Nobody actually checks whether you've wired a real pipeline. 😈
Timmy: A component you never reference in service.pipelines never runs, Gizmo — no warning, no data, no error. That exact gap is the exam's favorite trap, and "middleman" won't catch it.
Benny: Which is why I build every example in this plan before I trust it. Twenty minutes with a throwaway Collector taught me more about memory_limiter than a week of reading ever did.
Nutty: And I've filed every one of the twenty competencies by domain. Context Propagation shows up twice — once in the 46% column, once in the 10% column. That's not a coincidence, that's where people fail.
1. Which two OTCA domains together make up 72% of the exam, and what does this plan do differently across days 1–13 because of that? 2. Why does context propagation get its own dedicated close-up on days 7–8 instead of being folded into the rest of the API & SDK block? 3. What is the difference between the OpenTelemetry API and the SDK, and what happens if you instrument code but never register an SDK? 4. In the Collector, what happens to a processor, receiver, or exporter that's configured but never listed inside service.pipelines? 5. Name the four stages of this plan's daily study loop, and which OpenTelemetry idea the loop is modeled on. 6. What score should day 20's mock clear before you book the real exam, and what should you do if it lands right at that line? 7. Which exam-day details does this page decline to state as confirmed facts for OTCA, and why?
Check your answers
- The OpenTelemetry API & SDK (46%) and The Collector (26%) — 72% combined. Because both are real running software, days 1–13 spend most of their time building and deliberately breaking real pipelines by hand, not just reading about them.
- It's the only competency the curriculum names in two different domains — inside the 46% API & SDK domain and again inside the 10% Maintaining & Debugging domain — which signals it's exactly where real pipelines most often break, so it earns its own focused two days rather than a passing mention.
- The API is what instrumentation calls and is a no-op by default; the SDK is the registered implementation — provider, sampler, processor, exporter — that actually produces telemetry. Instrument code without registering an SDK and no telemetry is emitted at all.
- It is never instantiated — it silently does nothing, with no warning and no error, even though its configuration block is sitting right there in the file.
- Receive, Process, Export, Patch — modeled on a Collector pipeline, and specifically on the idea that a well-wired pipeline shouldn't drop data quietly, so a forgotten fact gets found and patched instead of silently staying missed.
- Comfortably above the published 75% pass mark, not just at it. If a mock lands close to the line, patch the exposed domain and sit Mock Exam · Set 2 before committing to a date — one score near the line is noise, two consistent scores above it is signal.
- Duration, price, question count, and the eligibility/validity windows — the Linux Foundation hasn't published them specifically for OTCA. What's stated for sibling exams here is only an observed pattern, and the one number this page does treat as confirmed, the 75% pass mark, comes from an official source: the Multiple Choice Exam FAQ.