OTCA — OpenTelemetry Certified Associate

The OpenTelemetry Certified Associate (OTCA) is the CNCF and Linux Foundation’s associate-level credential for the project that has quietly become the plumbing under every modern observability stack. Not a dashboard, not a database — the standard: one data model, one wire protocol, one set of attribute names, one Collector that receives, reshapes and routes everything. For a platform engineer it is the telemetry standard behind the CNPE’s Observability & Operations domain, and the only exam on the shelf that examines it properly. Here: what it is, whether it’s worth your money, the four official domains and weights from the CNCF curriculum, the substance behind each, and a study plan built from lessons already on this site.

What the OTCA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about one project — the one that collects and ships the data everything else draws pictures with. No cluster, no typing commands.

The OTCA is knowledge-based: multiple-choice questions in an online, remote-proctored session, with no terminal and no live cluster. It certifies that you understand OpenTelemetry’s data model, its API/SDK split, its configuration surface and its Collector well enough to design and operate a telemetry pipeline — not that your fingers can write instrumentation at speed.

Knowledge-based, but unusually concrete

What surprises people is where the weight sits. This is not a “three pillars of observability” quiz: fundamentals is the smallest of the three substantial domains at 18%, while nearly half the paper is the API and SDK and another quarter is the Collector. So the recall is concrete. You will be asked which processor belongs where in a pipeline, what a traceparent header contains, which environment variable sets the exporter endpoint, and what happens to a component that is declared but never referenced. Reading about OpenTelemetry is not enough — you need to have looked at real config and real SDK setup often enough that the shapes are familiar.

Who should sit it

• Platform and observability engineers who run a Collector fleet and want the model behind the YAML they maintain.
• SREs who live in traces and metrics during incidents and want to stop guessing why a trace stops at a service boundary.
• Application developers instrumenting their own services — the 46% API and SDK domain is literally your working day.
• Architects deciding on a telemetry strategy, especially anyone weighing vendor agents against a vendor-neutral pipeline.
• CNPE and CNPA candidates who want the observability domain to stop being the one they revise last.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: Part of this test is exactly what a platform person does all day. Another part is what an app developer does all day. Be honest about which you are.

Be honest about the return: OTCA is a narrow associate credential and nobody gets hired on it alone. Its value to a platform engineer is that OpenTelemetry is the one observability component you are almost certainly on the hook for — instrumentation belongs to app teams, backends belong to a vendor or an SRE group, and the pipeline in the middle belongs to the platform.

The overlap with the CNPE — real, but partial

The CNPE’s Domain 4 — Observability & Operations — is 20% of that exam, and OpenTelemetry is named in its tooling. What the CNPE wants is the platform half: deploy a Collector, wire a pipeline, get traces flowing to a backend, enrich telemetry with Kubernetes metadata, keep cardinality and cost under control. That maps cleanly onto the whole 26% Collector domain — configuration, deployment, scaling, pipelines, transforming data — plus the Agents competency over in the API and SDK domain, which is where zero-code instrumentation lives.

Most of the 46% does not map. Views, aggregation temporality, exemplars, the log bridge and exporter queue tuning are application-instrumentation concerns. They make you better at the job — you cannot debug someone else’s missing spans without knowing how their SDK batches them — but they are not on the CNPE blueprint. Treat OTCA as depth in one CNPE domain plus a large bonus, not as CNPE prep the way CGOA is.

When to skip it

Skip it if any of these are true. You already operate OpenTelemetry at scale — if you have tuned a tail-sampling gateway and debugged a dropped-spans metric at 3am, the badge will teach you only the SDK internals you deliberately delegate. You need one certification for a job filter — recruiters screen on CKA, CKAD and CKS, not on OTCA. Your organisation runs a proprietary agent end to end — the concepts transfer, but you will be studying a pipeline you do not have, and retention is poor. And if you are three weeks from the CNPE, this is a detour: 46% of your revision would be off-blueprint. Take it if telemetry is genuinely part of your remit and you want to stop cargo-culting Collector config. The certifications overview shows where it really sits on the shelf.

The four official domains & their weights

☺ Like you’re 10: The test has four parts and they are wildly unequal. Almost half of it is one part: how the code that produces the data works.

These come straight from the CNCF’s published OpenTelemetry Certified Associate (OTCA) Exam Curriculum — the domain names, the percentages and the competency lists below are that document, not a paraphrase. The four weights sum to exactly 100% (46 + 26 + 18 + 10), across 20 competencies in total — if a summary you read elsewhere does not add up, it has been garbled. They are shown here largest-first; the curriculum itself lists Fundamentals of Observability first, then the API and SDK, then the Collector, with Maintaining and Debugging in a second column. The bars are drawn to scale:

Every competency, domain by domain

The full curriculum — four domains, twenty competencies, exactly as the CNCF publishes them, with the pages here that cover each:

Reading the shape of this blueprint

Three things jump out. First: 72% of the paper is two pieces of software — the SDK you configure in an application, and the Collector you run as infrastructure. If your revision plan is “read about observability,” you have planned for 18% of the exam.

Second: Context Propagation is the only competency named twice, in both the 46% and the 10% domains. That is the curriculum telling you where candidates fail: a trace that breaks at a service boundary is the signature failure of a distributed pipeline, and you are expected to know both the mechanism and the debugging of it.

Third: Composability and Extension is doing quiet work. OpenTelemetry’s whole design is pluggable interfaces — swap a sampler, add a processor, register a custom exporter, build a Collector distribution with exactly the components you need. Questions phrased “how would you add X?” are asking which extension point you would reach for.

What you actually need to know

☺ Like you’re 10: Here’s the real substance — how the data is shaped, how the code that makes it is wired, how the trace gets carried between services, and what the postal worker in the middle does.

The data model, and the conventions that name everything

Every piece of OpenTelemetry data has the same three-layer shape: a Resource (attributes describing what produced this — service.name, service.version, k8s.pod.name), an InstrumentationScope (which library emitted it, and its version), then the signal record itself. Learn that sandwich — a surprising number of questions are really about which layer an attribute belongs to.

Semantic conventions are the agreed names and values for attributes — service.name, http.request.method, url.path, server.address, error.type — with stability levels so you know which are safe to build on. That is the whole value proposition: a dashboard written against conventional names works on any conformant service in any language, which is why conventions are a competency and not a footnote.

API vs SDK, and the pipeline you configure

This is the single highest-yield idea in the exam. The API is what instrumentation calls — libraries depend on it, and it is a no-op by default. The SDK is the implementation you register at start-up, holding the providers, processors, samplers and exporters that actually do something. That split is why a library can be instrumented without forcing a telemetry dependency on its users, and why “I added spans but nothing appears” is nearly always “no SDK was configured.”

Each signal has the same pipeline shape: a provider, one or more processors (for metrics, a reader), and an exporter, with a resource attached to the provider. Here is the trace pipeline in Go — read it as a diagram, not as code to memorise:

res, _ := resource.Merge(resource.Default(), resource.NewWithAttributes(
    semconv.SchemaURL,                       // schema URL: which convention version these names follow
    semconv.ServiceName("checkout"),
    semconv.ServiceVersion("1.4.3"),
))

exp, _ := otlptracegrpc.New(ctx)             // exporter: OTLP over gRPC (default :4317)

tp := sdktrace.NewTracerProvider(
    sdktrace.WithResource(res),
    sdktrace.WithSampler(                    // sampler: honour the parent, else sample 10%
        sdktrace.ParentBased(sdktrace.TraceIDRatioBased(0.1))),
    sdktrace.WithSpanProcessor(              // processor: buffer and export in batches
        sdktrace.NewBatchSpanProcessor(exp)),
)
otel.SetTracerProvider(tp)                   // register the SDK behind the global API
otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(
    propagation.TraceContext{}, propagation.Baggage{}))
defer tp.Shutdown(ctx)                       // flush: without this you lose the last batch

Four things there are exam material on their own. Sampler — parent-based respects the upstream decision so a trace is sampled consistently end to end; a ratio sampler applied independently per service shreds traces. Batch vs simple processor — batching is production, the simple processor exports one span at a time and exists for debugging. Shutdown — providers buffer, so a process that exits without flushing loses telemetry. And the resource, carrying a SchemaURL, which is where schema management starts. Almost all of it is settable without touching code, and that environment-variable surface is fair game:

OTEL_SERVICE_NAME=checkout
OTEL_RESOURCE_ATTRIBUTES=service.version=1.4.3,deployment.environment.name=prod
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf   # must match the port: 4317 grpc, 4318 http
OTEL_TRACES_SAMPLER=parentbased_traceidratio
OTEL_TRACES_SAMPLER_ARG=0.1
OTEL_PROPAGATORS=tracecontext,baggage       # the default; add b3 for legacy interop
OTEL_METRIC_EXPORT_INTERVAL=60000           # milliseconds
OTEL_SDK_DISABLED=false                     # the kill switch, per process

Context propagation — the competency named twice

Inside a process, OpenTelemetry carries a Context holding the active span (and any baggage). Across a boundary, a propagator serialises it into carrier headers and the receiver deserialises it. The default is W3C Trace Context:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             |  |                                |                |
          version  trace-id (16 bytes, 32 hex)   span-id (8 bytes) trace-flags (01 = sampled)

tracestate: vendorA=abc123,vendorB=xyz789     # vendor-specific, key-value, ordered
baggage:    user.tier=gold,tenant=acme        # user-defined context; NOT automatically
                                              # copied onto spans, and never for secrets

Three failure modes cover most of the questions. A service that does not extract the incoming context starts a brand-new trace, so the trace “breaks” at that hop. A service using a different propagator (B3, Jaeger) than its neighbour cannot read the header — which is why OTEL_PROPAGATORS takes a list, so you can speak both during a migration. And asynchronous work — a queue, a background task, a thread pool — loses context unless it is explicitly carried, which is what span links are for when strict parent-child does not fit. Baggage needs its own warning: it rides plaintext headers to every downstream service, so it is for routing hints and tenant labels, never credentials or personal data.

The Collector — five component types, and pipelines that must be wired

The Collector is one binary that receives telemetry, reshapes it and sends it on. It has exactly five component types, and knowing them cold is most of the 26%:

Pipelines are per-signal (traces, metrics, logs) and live under service.pipelines. The rule that catches everyone: a component that is configured but never referenced in a pipeline simply does not run — no warning, no data, no error. Transforming data is its own competency and is mostly OTTL, the OpenTelemetry Transformation Language used by the transform and filter processors and the routing connector:

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  memory_limiter:          # FIRST in every pipeline — sheds load before the heap dies
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  k8sattributes: {}        # enrich with k8s.pod.name, k8s.namespace.name, k8s.node.name
  transform:               # OTTL: redact and normalise before anything leaves the cluster
    trace_statements:
      - context: span
        statements:
          - delete_key(attributes, "http.request.header.authorization")
          - set(status.code, STATUS_CODE_ERROR) where attributes["http.response.status_code"] >= 500
  batch:                   # LAST — batching after sampling/filtering wastes less work
    timeout: 5s
    send_batch_size: 8192

exporters:
  otlp/backend:
    endpoint: tempo-distributor.observability:4317
    sending_queue: { enabled: true, queue_size: 5000 }
    retry_on_failure: { enabled: true, initial_interval: 5s, max_elapsed_time: 300s }
  debug:
    verbosity: detailed    # print telemetry to the Collector log — debugging only

extensions: [health_check, zpages]

service:
  extensions: [health_check, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, transform, batch]
      exporters: [otlp/backend]
  telemetry:
    metrics: { level: detailed }   # the Collector's own metrics — your first debugging tool

Deployment, scaling, and zero-code agents

Three deployment shapes, and the exam wants the trade-offs. No Collector — SDKs export straight to a backend: simplest, but every application then owns retries, credentials and backend coupling. Agent — a Collector per node (DaemonSet) or per pod (sidecar): local, low-latency, and the only place that can attach node- and pod-level context. Gateway — a scalable Deployment behind a Service that agents forward to: the right place for expensive fleet-wide work such as tail sampling, redaction and per-tenant routing. Most real platforms run both.

Scaling has one non-obvious rule: some processing is stateful and needs affinity. Tail sampling needs every span of a trace in one instance to decide, and spanmetrics needs the same to aggregate correctly — which is what the loadbalancing exporter is for, routing by trace ID to a consistent downstream Collector. Scraping with the prometheus receiver has the mirror problem, solved by the Operator’s target allocator, which shards scrape targets across replicas.

Agents in the instrumentation sense means zero-code instrumentation: the Java -javaagent, Python’s opentelemetry-instrument, Node’s --require hook, .NET’s automatic instrumentation. On Kubernetes the OpenTelemetry Operator injects them from an Instrumentation resource plus a pod annotation — the platform play, because app teams get traces with no code change:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: default
  namespace: observability
spec:
  exporter:
    endpoint: http://otel-collector.observability:4317
  propagators: [tracecontext, baggage]
  sampler:
    type: parentbased_traceidratio
    argument: "0.1"
---
# then, on the workload's POD template (not the Deployment metadata):
#   annotations:
#     instrumentation.opentelemetry.io/inject-java: "observability/default"
# the Operator adds an init container that copies the agent in and sets the env vars

Debugging pipelines, error handling, and schema management

The 10% domain is small but very answerable, because it is a fixed toolkit. Debugging starts with the Collector’s own telemetry — counters for accepted, refused and dropped spans and for failed exports, which localise a fault to receiver, processor or exporter at a glance. Then the debug exporter at verbosity: detailed, zpages for live component state, health_check for readiness, and config validation before you ship. Sending known-good traffic with telemetrygen to bisect “is it the app or the pipeline?” is the standard move.

Error handling is about backpressure and loss. The exporter’s sending_queue buffers when a backend is slow — and drops when full unless backed by the file_storage extension; retry_on_failure retries transient failures with backoff but must not retry permanent ones forever; memory_limiter refuses data rather than let the process get OOMKilled. The SDK equivalent is the batch processor’s queue, which drops spans silently when full. Telemetry pipelines are lossy by design under pressure; the choice is where you accept the loss.

Schema management is the competency most people have never met. Conventions evolve and attributes get renamed, so telemetry carries a schema URL naming the version it was produced against, and OpenTelemetry publishes machine-readable schema files describing the transformations between versions — which keeps old and new telemetry queryable together while a fleet migrates, instead of forcing a flag-day rename.

How to prepare using this site

☺ Like you’re 10: Most of this test already has a page here. Read them in weight order and you’ve read the syllabus.

This course was written for the CNPE, so its OpenTelemetry coverage is platform-shaped — strongest exactly where OTCA’s Collector domain is, and a good scaffold for the rest. Study in weight order: the API and SDK first, because everything downstream is easier once the data model is solid, then the Collector, then fundamentals and debugging.

Domain-by-domain study map

A three-week pace

Three focused weeks is a realistic plan for someone who has used OpenTelemetry; stretch to four if the SDK is new to you.

Exam logistics — and how to verify them

☺ Like you’re 10: It’s an online test you take from home with someone watching through your webcam. Prices and timings change, so always check the official page before you pay.

Some facts about the OTCA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This page separates the two deliberately.

What we can state with confidence

What you must check on the official page

The moving parts are duration, question count, pass mark, price, retake policy, eligibility window and certification validity. The CNCF’s other associate exams — KCNA, KCSA and CGOA — have historically clustered around a common shape: a 90-minute multiple-choice sitting, a list price around US$250 including one free retake, a 12-month window in which to sit it, and a credential valid for two years — and they are closed-book, with no documentation permitted. Those price and window figures are an observed pattern across sibling exams, not a published promise about this one. The pass mark is the exception, and it is not a pattern at all: the Linux Foundation’s Multiple Choice Exam FAQ states that “a score of 75% or above must be earned to pass the Multiple Choice Exam”, and that requirement covers every Linux Foundation multiple-choice exam — the OTCA among them — so 75% is published, just not on the product page. The question count is still genuinely unpublished, so any figure you meet for it is unverified. Note too that the CNCF discounts often enough that the sticker price is rarely what people pay. Check the published curriculum on the official page matches the domains and weights transcribed above before you build a study plan on them.

↗ Official OTCA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository ◆ OpenTelemetry documentation ◆ The OpenTelemetry specification

Where it sits in the ladder — and what to do next

☺ Like you’re 10: This is a specialist first badge. From here you either go deeper into building platforms, or wider across the other badges.

OTCA sits on the associate rung next to KCNA (Kubernetes fundamentals), KCSA (security fundamentals), CGOA (GitOps) and CNPA (platform engineering fundamentals). None of them gate anything, and OTCA is the most specialist of the group — it certifies one project rather than a discipline. The certifications overview lays out the whole shelf.

Go deep — the CNPE

The natural sequel. You now own the CNPE’s observability domain more thoroughly than the blueprint requires; what remains is the other four domains and the hands. Start with the CNPE exam guide for the format, then the lab track and the practice task bank — beginning with the observability set, where you’ll be pleasantly fast — then a timed mock exam. Keep Know It Cold open while you drill; its Collector and Prometheus manifests are the ones you’ll write against the clock.

Go wide, or go build

To broaden, CNPA is the obvious companion — its observability domain is largely revision for you, and that module is already written here — while the Kubernetes administrator track (CKA, then CKS) is what most platform roles screen for. To build, turn the badge into capability: ship an Instrumentation resource so any team gets traces from a pod annotation, put a gateway Collector in front of your backend and do redaction and tail sampling there once instead of in forty services, wire spanmetrics so RED metrics come free from traces, and use OpenCost and cardinality budgets to keep the bill honest. Then read reliability & incidents and check that the telemetry you collect actually answers the questions you ask at 3am — because that, not the certificate, is the outcome.