OpenTelemetry Certified Associate (OTCA)
The OpenTelemetry Certified Associate (OTCA) is the CNCF and Linux Foundation's associate-level credential for OpenTelemetry — the vendor-neutral instrumentation standard this course already covers on its own OpenTelemetry tool page. It's a knowledge-based, multiple-choice exam, not a live cluster, and it certifies something narrower and more useful than "knows what tracing is": that you understand the API/SDK split, the Collector's pipeline architecture, OTLP, and — the part most SRE-flavored study guides skip — semantic conventions, the shared vocabulary that decides whether five teams' telemetry can actually be queried as one fleet or just sits next to each other in the same database. This page covers what the OTCA tests, honest logistics to verify before you pay, and specifically why it matters if your job right now is standardizing an organization's telemetry pipeline rather than just running one service's dashboard.
Imagine five kids each keep a diary about the same treehouse, but one writes "the ladder broke" and another writes "stairs busted" and a third just draws a sad face. A grown-up trying to figure out what's wrong with the treehouse has to translate five different languages before they can even start. Semantic conventions are everyone agreeing, in advance, to write "ladder.status: broken" the exact same way, every time, no matter who's holding the pencil. The OTCA is the badge that says you know the agreed words — and the postal system (the Collector) that carries the diary pages to wherever someone's actually going to read them.
What the OTCA is, and who it's for
☺ Like you're 10: It's an online quiz about the shared language telemetry speaks — no terminal, no cluster, no vendor dashboard, just the standard underneath all of them.
The OTCA is issued by the CNCF and the Linux Foundation as an associate-tier, knowledge-based, multiple-choice exam — closed-book, remote-proctored, no live terminal and no cluster to fix. That puts it in a different family from this course's cluster-operations certifications like CKA and CKS, which grade you on the state of a real cluster. The OTCA instead grades whether you hold a correct model of a specification: OpenTelemetry's data model, its API/SDK split, its Collector pipeline, and the semantic conventions that name everything consistently. It exists because OpenTelemetry itself has quietly become the plumbing under nearly every modern observability stack — traces, metrics, and logs, produced once against a vendor-neutral API and shipped wherever a Collector's exporter block points — and until this exam, there was no credential that tested the standard on its own terms rather than through the lens of whichever backend vendor was selling the course.
OTCA tests the spec, not a product. Nowhere does the exam ask you to navigate a specific vendor's console. What it asks is whether you understand the shape of a Span, what a Collector processor does to data in flight, and whether http.request.method means the same thing on every conformant service regardless of who wrote it. For an SRE, that's precisely the layer worth certifying separately from any one tool: dashboards and alerting rules get rebuilt every time an org changes vendor, but a fleet that agrees on semantic conventions keeps working across that change without anyone touching a query.
Format, cost, and prerequisites — verify before you book
☺ Like you're 10: Here's roughly what it costs and how it runs, but exam details move without warning, so check the real page before you pay anyone.
The numbers below split into two kinds: structural facts that are safe to state, and moving logistics that the Linux Foundation revises without much announcement. Treat this table as a planning aid, not a source of truth to quote back at anyone.
| Item | What's generally published |
|---|---|
| Provider | CNCF & The Linux Foundation |
| Format | Knowledge-based, multiple-choice. Online, remote-proctored — a system check, webcam room scan, and government-issued photo ID against your registration. No terminal, no live cluster. |
| Level | Associate — the same tier as this course's own CKA-adjacent knowledge exams, and the CNCF's broader associate tier (KCNA, KCSA, CGOA and the project-specific associates) |
| Blueprint | Four weighted domains, twenty published competencies, summing to exactly 100% |
| Passing score | The Linux Foundation's Multiple Choice Exam FAQ states a score of 75% or above is required to pass any of its multiple-choice exams, the OTCA included — published, if not always on the product page itself |
| Duration & price | Not fixed here deliberately. The CNCF's other associate exams 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 sibling exams, not a confirmed promise for this one specifically |
| Validity & eligibility window | Sibling associate exams have historically carried a 12-month window to sit after purchase and a 2-year certification validity — verify both for OTCA on the vendor's own page |
| Prerequisites | None formally required. OTCA doesn't gate anything else, and nothing gates it |
| Permitted resources | Closed-book — no documentation tab, unlike this course's performance-based Kubernetes exams |
Duration, question count, price, retake policy, eligibility window, and certification validity all change without much notice, and question count in particular has never been consistently published. This page is an independent, unofficial snapshot as of August 2026. Confirm current details on the Linux Foundation OTCA page and the CNCF certification page before you register, and cross-check the domain weights against the current curriculum at github.com/cncf/curriculum — if it disagrees with anything below, it's right and this page is stale.
↗ Official OTCA page — Linux Foundation ◆ The OpenTelemetry specification
The four domains, briefly
☺ Like you're 10: Four topics, wildly unequal — almost half the whole test is just "how does the code that produces the data actually work."
The CNCF's published curriculum weights four domains to exactly 100%. The shape rewards exactly the muscle a pipeline-standardization project needs: 72% of the exam is two pieces of software — the SDK a team configures inside a service, and the Collector a platform team runs as shared infrastructure — with Fundamentals of Observability, home to the semantic-conventions competency, sitting at 18%.
That's the whole domain picture this page needs to give you. The full twenty-competency breakdown, worked Go and YAML examples for every domain, and a three-week study plan already exist — written for exactly this exam at the depth it deserves — on this course's companion Platform Engineering course's OTCA page. Duplicating that here would just be a worse copy; go there once you've decided the exam is worth your time.
Semantic conventions: the part a pipeline-standardization project actually lives or dies on
☺ Like you're 10: It's not enough for every team to send telemetry — they have to call the same things by the same names, or the fleet-wide dashboard nobody can build.
This course's own OpenTelemetry page covers the API/SDK split and the Collector's pipeline architecture in real depth, so this page won't repeat that. What it hasn't covered yet — and what the OTCA's Fundamentals of Observability domain names as its own competency — is semantic conventions: the published, versioned agreement on what an attribute is called and what values it can hold, so that service.name, http.request.method, and db.system.name mean the identical thing whether the service emitting them was written in Go last month or Java five years ago. This is the actual mechanism behind "standardize the org's telemetry pipeline" — not a policy document, a wire-level agreement every SDK enforces the same way.
| Namespace | Example attribute | What it standardizes |
|---|---|---|
service.* | service.name, service.version | Which service, which build — the identity every other attribute hangs off |
http.* | http.request.method, http.response.status_code | One name for a request method across every language's HTTP library, instead of five different casings and abbreviations |
db.* | db.system.name, db.query.summary | A consistent way to say "this span touched a database" regardless of driver |
k8s.* | k8s.pod.name, k8s.namespace.name | Cluster context attached the same way whether the Collector's k8sattributes processor added it or the SDK did |
error.* | error.type | One field to filter or alert on across the whole fleet, instead of parsing a different exception format per language |
Two details the OTCA expects and most SRE-flavored reading skips entirely. First, conventions carry a stability level — stable, experimental, or deprecated — and a schema URL stamped onto the resource, naming exactly which version of the conventions a piece of telemetry was produced against; OpenTelemetry publishes machine-readable schema files describing the renames between versions, which is what lets old and new telemetry stay queryable together while a fleet migrates gradually instead of on a single flag day. Second, conventions carry cardinality guidance, not just names: an attribute like http.route is designed to be low-cardinality and safe on a metric, while something like a raw url.full or a user ID is high-cardinality and belongs on a span or log only — the same distinction this course's OpenTelemetry page flags as a common cause of a blown-up metrics bill, now traced back to its actual source: the convention itself telling you where an attribute is safe to put.
A fleet where half the services instrument against an older, since-renamed convention and half against the current one doesn't error — it just silently stops being comparable. A dashboard built on http.method (the old name) goes blank for every service that upgraded to http.request.method, and nothing in either service's logs says why. Standardizing a pipeline means picking one schema version as the fleet's baseline and tracking upgrades deliberately, not letting each team update whenever their SDK happens to bump a minor version.
Why this matters for an SRE, specifically
☺ Like you're 10: This isn't a developer-only badge — every place this course teaches you to watch a system or answer a page assumes the telemetry underneath is comparable in the first place.
Three places in this course's own curriculum lean on exactly what the OTCA certifies. Monitoring and observability assumes you can build one golden-signal dashboard that works across every service in a fleet — that's only true if every service's telemetry uses the same attribute names, which is the semantic-conventions competency in practice, not theory. Toil and automation treats zero-code auto-instrumentation as the default baseline precisely because it removes the recurring manual work of re-wiring each new service by hand — the OTCA's Agents competency, inside the 46% API-and-SDK domain, is that same zero-code instrumentation examined properly. And incident management and on-call depends on context propagation working end to end — an on-call engineer chasing a trace that mysteriously stops at a service boundary is debugging exactly the failure mode the OTCA's Context Propagation competency exists to catch, and it's named twice in the official curriculum for a reason: it's where most real pipelines actually break.
An SRE doesn't need the OTCA to page correctly during an incident — but an SRE standardizing a pipeline across a whole org needs the vocabulary the exam certifies, because a golden-signal dashboard, an SLO built on a shared metric, and a cross-service trace all silently assume every team is calling the same thing by the same name. That assumption is invisible until someone breaks it, and by then it's an outage postmortem instead of a design review.
Who should sit it — and who should skip it
☺ Like you're 10: If your job right now is getting five teams' telemetry to actually agree with each other, this is squarely for you. If you just consume dashboards someone else built, it probably isn't.
Sit it if you're the SRE, observability engineer, or platform lead actually responsible for an org's shared telemetry pipeline — you own the Collector fleet, you're the one who gets asked "why doesn't this new service show up on the standard dashboard," or you're choosing between letting every team instrument however they like versus enforcing one shared SDK configuration and one set of conventions. It's also worth sitting for anyone building the shared Instrumentation resource or auto-instrumentation baseline that every other team inherits — the exam's weight matches that responsibility almost exactly, with 72% of it being the two pieces of software (the SDK and the Collector) that decision actually touches.
Skip it, or at least deprioritize it, if any of these describe you. You're an application developer who imports whatever telemetry library the platform team already standardized on — the API-and-SDK domain is your daily reality, but the exam's return on a resume is narrow, and a broader credential like this course's own SRE Practitioner profile carries more weight for a general SRE career path. Your organization already runs a single proprietary vendor agent everywhere and has no plan to change that — the concepts transfer, but you'd be studying a pipeline you don't operate, and retention on unused knowledge is poor. Or you're new to observability entirely — start with this course's own monitoring and observability page and the OpenTelemetry tool page first; the OTCA rewards someone who has already looked at real SDK config and real Collector YAML, not someone meeting either for the first time on exam day.
Go deeper: this course's OpenTelemetry page and the Platform Engineering course's full study guide
☺ Like you're 10: This page told you whether to care and gave you the one piece — semantic conventions — this course hadn't covered yet. The other pages teach you everything else, properly.
This page exists to answer one question for an SRE — is the OTCA worth your time, and what does it add beyond what this course already teaches — not to be a complete study guide. For the mechanics themselves, this course's own OpenTelemetry page already covers the API/SDK split, OTLP's two transports, the Collector's receiver-processor-exporter pipeline with a real production-shaped config, manual versus auto-instrumentation, and the exact gotchas — a component declared but never wired into service.pipelines, a port-and-protocol mismatch, broken context propagation — that account for most real pipeline failures. Every one of those maps directly onto OTCA competencies.
For the full twenty-competency breakdown domain by domain, worked Go SDK code, a complete Collector config with OTTL transforms, the Operator's zero-code injection CRDs, and a three-week study plan built for this exact exam, go to the companion Platform Engineering course's OTCA page — written at the depth a candidate actually needs, rather than duplicated here at a worse depth. Once you hold it, the natural pairing on the metrics side is this course's own Prometheus Certified Associate (PCA) profile — PCA covers PromQL and alerting rules, OTCA covers the vendor-neutral instrumentation and Collector pipeline that can feed a Prometheus backend or any other. Together they're the two CNCF associate credentials that most directly certify the observability plane this course's SRE toolchain page catalogues.
Ellie the Elephant: We finally got all twelve services onto the OTel SDK. Every one of them emits OTLP now.
Foxy: So the fleet-wide dashboard just works now? All twelve show up the same way?
Ellie the Elephant: Nine of them. Three teams shipped before we agreed on conventions, so their spans still call it httpMethod instead of http.request.method. Same idea, different name, and the dashboard can't reconcile it.
Nutty the Squirrel: That's exactly why I catalogue vocabulary, not just tools. A shared SDK doesn't buy you a shared fleet if nobody agreed on the words first — semantic conventions are the actual standardization, the SDK's just the delivery mechanism.
Benny the Beaver: I'll write a Collector-side transform processor to rename the old attributes in flight — buys us time without asking three teams to redeploy this week.
Timmy the Turtle: Buys time, doesn't fix it. Put a deadline on that transform and a ticket to migrate the three services properly — a patch at the Collector that quietly becomes permanent is exactly the kind of thing I don't trust.
Ellie the Elephant: Fair. And this is the whole argument for the OTCA in one incident — nobody on those three teams got the standard's vocabulary wrong out of carelessness. Nobody had actually studied it.
1. What kind of exam is the OTCA — performance-based like the CKA, or something else — and what does that mean for how you prepare? 2. Name the four OTCA domains and roughly how their weights compare. 3. What are semantic conventions, and give one concrete example of an attribute name they standardize. 4. Why can a fleet where some services use an old convention name and some use the renamed current one fail silently instead of erroring? 5. Name one place in this course's own curriculum that quietly assumes semantic conventions are already standardized across a fleet. 6. Give one situation where an SRE should skip the OTCA.
Check your answers
- It's knowledge-based and multiple-choice, not performance-based — there's no live terminal or cluster to fix, unlike the CKA or CKS. Preparation means studying the specification and real config shapes closely enough to recognize them, not building speed on a live system under a clock.
- The OpenTelemetry API and SDK (46%), the Collector (26%), Fundamentals of Observability (18%), and Maintaining & Debugging Observability Pipelines (10%). The first two alone are 72% of the exam — both concrete software with concrete configuration.
- Semantic conventions are the published, versioned agreement on what a telemetry attribute is called and what values it holds, so the same concept means the same thing across every service regardless of language or team. Example:
http.request.methodstandardizes how an HTTP verb is named, instead of every language's library using its own casing or abbreviation. - Because nothing rejects the mismatch — both the old and new attribute names are syntactically valid telemetry. A dashboard or query built against one name simply returns nothing for services still using the other, with no error anywhere to point at the cause.
- Any reasonable answer, e.g.: monitoring and observability assumes one golden-signal dashboard works across every service, which requires shared attribute names; toil and automation's zero-code auto-instrumentation baseline is the OTCA's Agents competency in practice; or incident management and on-call depends on context propagation working end to end across service boundaries.
- Any of: you're an application developer using a telemetry setup the platform team already standardized, and a broader credential like SRE Practitioner would carry more weight; your org runs one proprietary vendor agent everywhere with no plan to change; or you're new to observability entirely and should study monitoring and observability and the OpenTelemetry tool page first.