OpenTelemetry Certified Associate Roadmap

Understand why telemetry exists before memorizing component names.

• Distinguish observability from monitoring and raw data collection.
• Use metrics for aggregate behavior, logs for events, and traces for distributed request flow.
• Model traces as related spans with parent relationships, attributes, events, links, status, and timing.
• Define service outcomes and investigations that need multiple signals.
• Learn how semantic conventions standardize names and meanings.
• Compare code-based and zero-code instrumentation and identify duplicate coverage.
• Classify sensitive fields and unbounded metric attributes before collection.
• Practice moving from an SLI symptom to representative trace and log evidence.

Evidence: a signal decision map, service outcome specification, telemetry data classification, and one cross-signal incident narrative.

The API and SDK form the largest OTCA domain. Learn who owns instrumentation and who owns telemetry policy.

• Separate library use of the API from application ownership of SDK configuration.
• Configure Resources, instrumentation scopes, providers, processors, readers, and exporters.
• Create spans, events, links, attributes, status, and recorded exceptions with correct semantics.
• Inject and extract W3C Trace Context across service boundaries.
• Use Baggage only for approved non-sensitive propagated context.
• Compare head, parent-based, and tail sampling constraints.
• Use batch processing and bounded flush and shutdown lifecycle.
• Understand metric instruments, aggregation, Views, temporality, and exemplars.
• Correlate logs with active Trace ID and Span ID.
• Export all signals with OTLP while keeping backend choice outside instrumentation code.

Evidence: a three-service trace graph, correlated logs, reconciled metrics, sampling tests, privacy checks, and graceful-shutdown evidence.

Trace every item through receivers, ordered processors, connectors, exporters, extensions, and service configuration.

• Select a Collector distribution by required components and stability.
• Configure OTLP and selected pull or host receivers.
• Place memory limiting, filtering, transformation, resource, sampling, and batching deliberately.
• Enable every component by referencing it in a service pipeline or extension list.
• Use connectors to join pipelines when a cross-signal or routing use case requires it.
• Protect receiver and exporter endpoints with appropriate TLS and authentication.
• Deploy agent Collectors for local intake and gateways for central processing.
• Prevent duplicate collection and preserve stable Resource identity.
• Validate merged configuration and inspect available components before rollout.

Evidence: valid trace, metric, and log pipelines; a component inventory; agent and gateway topology; security denial tests; and data-count reconciliation.

Collectors are production services. Bound memory and queues, understand loss, and scale stateful processing correctly.

• Use the memory limiter early and align it with runtime memory limits.
• Use batch processing for efficient export without claiming guaranteed delivery.
• Configure bounded sending queues, retries with backoff, and optional persistent storage.
• Define refusal, retry, overflow, drop, restart, and backend-rejection behavior.
• Scale stateless pipelines horizontally and route same-trace spans together for tail sampling.
• Monitor accepted, refused, dropped, queued, sent, failed, CPU, memory, and latency signals.
• Test load spikes, uneven traces, backend slowness, process restart, and certificate expiry.
• Measure fan-out, network, queue disk, backend ingestion, and retention cost.

Evidence: a capacity model, bounded outage test, trace-aware scaling proof, internal telemetry dashboard, and resilience runbooks.

Diagnose from source to backend and represent blind spots honestly.

• Use an independent telemetry oracle with known trace graphs, metric points, logs, and sampling outcomes.
• Localize loss through SDK generation, propagation, receiver, processor, queue, exporter, network, and backend evidence.
• Distinguish missing, sampled, refused, dropped, queued, stale, and rejected data.
• Repair injection and extraction before expecting the Collector to reconstruct parentage.
• Version semantic-convention and schema changes across every producer and consumer.
• Use staged transform or dual-read migrations and retire old fields deliberately.
• Display healthy, degraded, unknown, stale, and intentionally sampled coverage separately.
• Complete three projects, review 40 cards, and repeat weak-domain scenarios.
• Run timed reviews and verify the current Linux Foundation instructions.

Evidence: a fault decision tree, stage-by-stage loss accounting, schema migration tests, honest coverage dashboard, and exam-day checklist.