/ OPENTELEMETRY, OBSERVABILITY, DEVOPS, CERTIFICATION

I passed the OpenTelemetry Certified Associate (OTCA) exam

It’s done: I passed the OpenTelemetry Certified Associate (OTCA), the certification delivered by the Linux Foundation and the CNCF around the OpenTelemetry project.

Michael's OpenTelemetry Certified Associate certificate

As usual with certifications, the badge itself is just a row in a database. What actually mattered to me was the excuse to go back over a technology I already used in production and check whether I really understood it, or whether I had simply learned to make my own setup work.

Spoiler: those are two different things, and the exam is quite good at telling them apart.

Why this certification

I didn’t come to OTCA as a beginner. I’ve designed and operated OpenTelemetry Collector deployments in an AWS VPC, multiple environments and projects sending telemetry into shared backends. That kind of work teaches you a lot about gateways, exporters, batching, memory limiters, and everything that goes wrong at 3 a.m.

But it also teaches you your pipeline. You end up with a very deep knowledge of the twenty percent of OpenTelemetry you actually deployed, and a vague idea of the rest. The SDK internals, the log signal, the details of context propagation, the parts of the spec I had never needed, all of that lived in a comfortable blur.

Preparing for a certification is a decent way to force yourself through the blur. You can’t skip the chapters you find boring, because the exam won’t.

What the exam actually looks like

Here’s the format, so you know what you’re signing up for:

Item Detail
Format Online, proctored, multiple choice
Duration 90 minutes
Price $250, with one free retake included
Validity 2 years
Level Beginner (officially)
Prerequisites None

The exam has 60 questions and a 75% passing score. From my experience, plan to be comfortable well above that threshold before you sit the exam.

What is official, and much more useful, is the domain breakdown:

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

Look at that 46% carefully, because it’s the whole story of my exam.

Where I struggled, and why it made sense

I’ll be honest about this, because it’s the most useful thing I can tell you.

I was comfortable every time a question moved toward infrastructure. Collector configuration, pipelines, deployment patterns, Kubernetes, what breaks and how you’d diagnose it, that felt like being asked about my own job. I read those questions once and moved on.

I struggled on the development-oriented parts. Tracer providers, span processors, the exact responsibilities of the SDK versus the API, how instrumentation is wired from inside application code. Not “no idea” territory, but the difference between knowing an answer and reconstructing it under a timer is enormous. I was reconstructing.

That asymmetry is perfectly coherent with my recent experience. I’ve spent the last few years on the platform side of OpenTelemetry: receiving telemetry, routing it, keeping the pipeline healthy. The application side, the part where a developer picks up the SDK and decides what to instrument and how. I had mostly consumed as an input, not written myself.

And here’s the trap: the domain I was strong on is worth 26%. The domain I was weak on is worth 46%. My instinct during preparation was to go deep on the Collector, because that’s the material I enjoy and where progress feels fast. That would have been a very comfortable way to fail.

💡 If you take one thing from this post: weight your revision by the exam’s own percentages, not by what you already enjoy. Your comfort zone is, almost by definition, the part you don’t need to revise.

OpenTelemetry is a world of its own

Going through this preparation confirmed something I’d been half-thinking for a while: “Observability Engineer” is not a made-up job title.

It’s easy to be dismissive about it, yet another specialisation, another line on a business card. But look at the actual surface area you need to cover to be credible on OpenTelemetry alone:

  • The infrastructure: deploying and sizing Collectors, agent versus gateway topologies, resilience, cost and cardinality control of a pipeline that can easily become the noisiest thing in your platform.
  • The integration and development: instrumenting applications, choosing between automatic and manual instrumentation, propagating context correctly across services and queues, knowing what the SDK does on your behalf and what it doesn’t.
  • The exploitation of the signals: and this is the part people skip. Collecting traces, metrics, and logs is not the goal. The goal is extracting something valuable out of them: for engineering (where is the latency, what actually broke, which dependency is degrading) and for the business (which user journeys fail, what does a degradation cost, which feature is worth the infrastructure it consumes).

Those three areas require genuinely different reflexes. A great Collector operator isn’t automatically good at instrumenting an application, and neither of them is automatically good at turning a pile of spans into something a product owner cares about. That’s a real specialisation, and the exam, with its deliberate split across those domains, is a fair reflection of it.

Preparation: LFS148

The main resource I used is the Linux Foundation’s own free course, Getting Started with OpenTelemetry (LFS148). It’s free; it’s about 8–10 hours of material; and you get 90 days of access.

The content is genuinely good. It alternates theory chapters with hands-on labs: automatic instrumentation, then manual instrumentation for traces, metrics, and logs one signal at a time, then Collector pipelines at the end. The progression matches the exam domains closely, which is not a coincidence.

Two honest caveats.

First: “8–10 hours” is the reading time, not the learning time. It took me a month. Not a month of daily work, a month of picking it up and putting it down, which is exactly the failure mode I want to warn you about. The only phase that produced real progress was the last week, when I committed to a consistent 2–3 hours per day. Everything before that was mostly re-reading things I had forgotten since the previous session.

If you can block one focused week rather than spreading it over four, do that. This material does not survive being touched for twenty minutes every few days.

Second: the labs need a proper environment. VS Code, Docker running, enough RAM. Half-doing the labs, reading the code without running it, is tempting when your setup is fighting you, and it’s the fastest way to end up with theoretical knowledge that evaporates under exam pressure. Sort out the environment before you start the lab chapters, not during them.

Building my own practice material instead of buying it

This is the part of my preparation I find most interesting in hindsight, and it has little to do with OpenTelemetry.

I started the usual way: reading feedback from people who had already taken the exam. There’s a decent amount of it now: Medium write-ups, the Splunk community blog, various posts from the past year. Half an hour of that tells you which topics keep coming up and which ones candidates consistently underestimate. It’s how I confirmed that the SDK side really is as heavy in practice as it is on paper.

Then I did something I wouldn’t have done a couple of years ago: I built my own quiz project to train on.

Think about how this used to work. Before Claude, preparing for a certification meant heading to Udemy or another paid platform to buy someone else’s practice exams. That’s what I did for the CKA and for the AWS SAA: buy the course, buy the practice tests, grind through them. This time I produced the material myself and trained on it.

The value went well beyond having questions to answer. Writing them, or rather, reviewing and challenging the ones being generated, turned out to be an excellent way to probe how relevant a question actually is. When you’re forced to judge whether a question is fair, whether the distractors are plausible, whether it tests understanding or just recall; you engage with the underlying topic far more deeply than by ticking a box. Producing a good question about samplers requires understanding samplers considerably better than answering one does.

And unlike a static question bank, it pushed back. Being asked why an answer is right, and having to defend a vague explanation out loud, exposes gaps much faster than re-reading a chapter. When you can’t explain it, you don’t know it.

The other payoff was measurement. I organised the question bank by the four official domains and scored each run per domain. After a few sessions the pattern was unambiguous, and it’s exactly the one I described earlier: solid on Collector and fundamentals, wobbly on SDK details.

The exam simulator: Waterfall

The project is live at waterfall.smartbamboo.net, go and try it. I’ll dedicate a follow-up article to how it’s built; it deserves more than a paragraph. The short version:

The tedious manual work, searching online for sample questions, collecting feedback from people who took the certification, distilling it all into usable material, is handled by the agent. From that it produces a set of 150 questions covering the OTCA domains. On top sits a small React web app with two modes: flashcards for quick repetition, and exam conditions for full timed runs with per-domain scoring.

The cherry on top: the engine is generic. The question bank is just data, so the same solution is reusable to prepare future certifications in the same style. Which, given how many exams I seem to keep signing up for, might end up being the most valuable outcome of this whole thing.

Stay tuned. I’ll walk through the architecture in the next post.

Would I recommend it?

Yes, with a clear idea of who it’s for.

If you’re new to observability, OTCA is a genuinely well-designed entry point. The domains cover the right things in roughly the right proportions, and LFS148 plus real lab time is a coherent path from zero to certified.

If you already run OpenTelemetry in production, the honest pitch is different: it won’t teach you your job. What it will do is systematically find the parts of the spec you’ve been working around for two years without noticing. For me, that was the application side, and it was worth the $250 and the month, because I now reach for parts of the SDK I used to treat as a black box.

A few practical tips to close:

  • Weight your revision by the domain percentages. The API and SDK domain is 46%. Act accordingly, especially if you come from the platform side.
  • Know the API/SDK separation cold. Why it exists, what lives on each side, what a no-op implementation means for library authors. It underpins a lot of questions.
  • Actually run the labs. Reading the instrumentation code is not the same as watching a trace come out the other end.
  • Do at least one full timed run before the real thing. 90 minutes for ~60 questions is comfortable, but only if you’ve felt the pace once.
  • Book a date early. Nothing focuses preparation like a deadline you’ve already paid for, and the free retake means the downside is small.

Next on my list is going deeper into the Collector internals, custom processors and the OTTL transform language, which is where my day job keeps pushing me anyway.

Good luck if you’re preparing for it!

Acknowledgments

Many thanks to Claude K. and Xavier G. for carefully reviewing drafts of this post and the Waterfall simulator; your feedback shaped both significantly. And to my wife: thank you for the support each time I needed to focus and prepare for certifications. This wouldn’t have happened without you.

References: