Passing the OTCA With 83: Half the Exam Is the SDK Pipeline

I wrote the longer version, with everything I read and what wasted my time, on my blog.

You can run Prometheus perfectly in production and still fail the OTCA.

If you've turned on auto-instrumentation or shipped telemetry to a Collector sidecar, you were inside the OpenTelemetry pipeline without ever being tested on how it works. The OpenTelemetry Certified Associate tests what happens inside it. I passed with 83 on the first attempt, one of the 15 CNCF certifications I did on the way to Golden Kubestronaut.

Format and weights

60 multiple-choice questions, 90 minutes, pass at 75%.

Domain	Weight
The OpenTelemetry API and SDK	46%
The OpenTelemetry Collector	26%
Fundamentals of Observability	18%
Maintaining and Debugging Observability Pipelines	10%

Nearly half the exam is SDK internals, the part most people never read because the library works once you add it.

Don't study backends

Prometheus, Grafana and Jaeger are out of scope. OTCA covers the layer in front of them: how code produces a span, where it travels inside the SDK, and what the Collector does with it next. It's language-agnostic too, so no Go or Python syntax. The OTel Operator gets a mention, but I didn't see it tested in depth.

The SDK domain

Fundamentals (18%) is cheap points if you know what a trace is, what a metric data point looks like and why semantic conventions exist.

The SDK domain is harder in a specific way. Questions ask which layer owns a behavior, and the wrong options are real OTel concepts placed one layer up or one layer down. The model I'd build first:

1. Providers. TracerProvider, MeterProvider, LoggerProvider, one entry point per signal.
2. Processors transform or batch data. Know BatchSpanProcessor versus SimpleSpanProcessor.
3. Exporters (OTLP, Console, Zipkin) are where data leaves the SDK.

Then the API versus SDK split from the specification overview: the API defines interfaces, the SDK implements them. I had been treating them as one thing, and that costs a handful of easy questions.

File-based SDK configuration is tested as well. Provider contains processor contains exporter, and once you see that nesting the config questions get much easier.

Context propagation

I think people skip this, and it shows up more than you'd expect. In-process, Baggage and SpanContext flow through the language's Context API. Across processes it's W3C Trace Context: the traceparent header and what each field holds. B3 is older and still appears in questions, so learn it even if you've never configured it.

The Collector is a full pipeline

26% of the exam, and most engineers treat the Collector as something you drop in and forget. Receivers accept data, processors transform it, exporters send it, all wired as named pipelines under service.pipelines. One config can hold separate pipelines for traces, metrics and logs.

Processor order is a real topic:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

memory_limiter goes first so the Collector can shed load before it gets OOM-killed. batch goes last before export to cut outbound requests. Flip them and the config can fall over under load. I got those questions right only because I had read the Collector configuration docs.

Know agent mode (one Collector per node, DaemonSet or sidecar) and gateway mode (a central cluster aggregating from agents or SDKs). Tail sampling in gateway mode needs careful routing, because related spans must land on the same instance.

Debugging (10%) is small. Learn the common patterns and move on.

What worked and what didn't

I started with LFS148, the free Linux Foundation OpenTelemetry course. That's where API versus SDK finally clicked. Then the official docs with a notepad, writing down what each component owns: about six hours over three sessions.

The OTel Demo app is underrated for this. Running it locally and reading its SDK configs taught me more about the Collector than any tutorial.

Two things wasted my time. Language-specific SDK examples cost me two hours on an exam with no syntax in it. Third-party Collector scaling articles were the other, since some referenced patterns that changed between versions.

Where my 83 came from

Mostly SDK pipeline questions, where I spent the most time, plus Collector processor ordering. If you want to check where you stand before booking, the OTCA practice test I built during prep covers every topic above. Tests for other CNCF exams are at yetmike.com/tests, and the rest of my study links are in awesome-kubestronaut.

I still feel shaky on Collector scaling. I passed, but I'm not convinced the third-party material I read on it was current.

---

Originally published on yetmike.com