OTCA Study Guide: OpenTelemetry Certification

What OTCA covers

OpenTelemetry Certified Associate validates foundational knowledge of observability and the OpenTelemetry project. The official page describes an online, proctored, multiple-choice exam lasting 90 minutes. The public domains are Fundamentals of Observability at 18%; The OpenTelemetry API and SDK at 46%; The OpenTelemetry Collector at 26%; and Maintaining and Debugging Observability Pipelines at 10%.

The weighting makes API and SDK understanding the center of preparation, but the domains form one lifecycle. An application or instrumentation library uses the API. The application configures an SDK. Context is propagated across service boundaries. SDK processors and readers send telemetry, often over OTLP, to a Collector. Collector receivers accept data, processors transform it, exporters send it onward, and connectors may join pipelines. Operators use internal telemetry, logs, health, and backend evidence to identify loss or delay.

OpenTelemetry is vendor-neutral instrumentation and telemetry plumbing; it is not an observability backend. It does not decide which service objectives matter, retain all data forever, or guarantee delivery. Backends store, query, visualize, or analyze the exported telemetry. Keep that boundary clear in every scenario.

Domain 1: fundamentals of observability

Observability is the ability to understand internal state from system outputs. Monitoring commonly evaluates known conditions; observability supports investigation of both expected and unexpected behavior. Collecting every possible field is not the goal. Useful telemetry has semantics, context, quality, ownership, retention, and a connection to an operational or product outcome.

Metrics represent numerical measurements and aggregate behavior over time. They are efficient for rates, error ratios, latency distributions, saturation, and objectives. Logs record events and detailed context. Traces connect timed operations into a distributed request or workflow. A trace contains spans; each span can have a parent, attributes, events, links, status, kind, and timing. The signals complement each other.

Semantic conventions standardize names and meanings for common operations, resources, and telemetry. Consistency lets shared dashboards and analysis work across teams. Conventions have stability levels and can evolve, so pin expectations and plan migration rather than treating every field as eternal.

Instrumentation can be code-based or zero-code. Code-based instrumentation creates domain-specific spans and measurements. Zero-code tooling can instrument supported frameworks, libraries, or runtimes without source changes. Both can be used together, but overlapping coverage can create duplicate spans. Review the resulting trace shape instead of assuming more instrumentation is always better.

Start with outcomes. If checkout latency is the question, measure aggregate latency and success, trace representative requests, and log meaningful error events. Avoid user IDs, emails, raw URLs, or request IDs as metric attributes; their cardinality and privacy cost can overwhelm their value. Use trace or protected event systems for per-request detail.

Domain 2: OpenTelemetry API and SDK

Composability and ownership

The API defines interfaces that instrumentation code calls. A reusable library can depend on the API without forcing an SDK or export policy on its consumer. The application owner configures the SDK: providers, Resources, sampling, processors, metric readers, Views, exporters, and lifecycle. This separation lets multiple libraries compose under one application policy.

A Resource describes the entity producing telemetry, such as a service, process, container, host, cloud resource, or Kubernetes workload. A stable service.name is foundational. InstrumentationScope identifies the library or module that emitted telemetry and can carry a version and schema URL. Resource and scope answer different attribution questions.

Context and tracing

Context carries correlation information within an execution unit. Propagation moves it across process and service boundaries by injecting values into a carrier and extracting them on receipt. OpenTelemetry's default propagator uses W3C Trace Context headers. The receiver must extract before creating its server span so the new span can join the upstream trace.

Baggage propagates application-defined key-value data. It can cross boundaries and may enter logs or downstream services, so do not put credentials, tokens, or personal data in it. Treat external trace and baggage headers as untrusted input: validate parsing, decide whether to accept or restart context, and control what is forwarded to external services.

A span represents one operation. Events annotate meaningful points within it. Links relate a span to other contexts without making one the parent, fitting batches or asynchronous fan-in. Status describes the operation outcome according to API and semantic rules; recorded exceptions add structured error evidence but do not automatically decide every status.

Head sampling decides near span creation, before later outcomes are known. Parent-based sampling preserves upstream decisions while applying a root sampler to new traces. Tail sampling can use completed trace evidence but requires spans for a trace to reach the same decision point and consumes Collector memory and time. Sampling reduces cost but creates intentional absence; coverage reporting must distinguish sampled data from pipeline loss.

BatchSpanProcessor exports completed spans efficiently in batches. Simple processing is helpful for development but can add synchronous overhead. Short-lived applications must call supported flush or shutdown lifecycle methods or buffered telemetry may never leave the process. Bound shutdown time so telemetry delivery does not make termination indefinite.

Metrics and logs

Counters record monotonic additive values such as completed requests. UpDownCounters record additive changes that can increase or decrease, such as active work. Histograms record distributions such as latency or size. Observable instruments report values through callbacks where the language implementation supports them. Instrument selection must follow the behavior of the quantity.

A View lets the application customize streams created from matching instruments, including aggregation and retained attributes. Use Views to remove a library attribute that creates unnecessary cardinality or to configure suitable histogram aggregation. Metric temporality determines whether an aggregation covers a delta interval or accumulates from a fixed start; exporters and backends must interpret it consistently.

Exemplars associate representative measurements with aggregate metric points and can include trace and span context. This enables movement from a latency or error metric to an example trace without placing unique trace IDs into metric attributes.

OpenTelemetry logs provide a model and bridge path for existing logging systems. Correlation requires active context to be captured into a LogRecord, commonly as Trace ID and Span ID. Creating spans does not automatically modify every unrelated logger; verify language and framework integration. Preserve severity and event meaning, and avoid exporting secrets in body or attributes.

OTLP transports OpenTelemetry traces, metrics, and logs over supported transports. Applications can send directly to a compatible backend for simple development, but a Collector usually centralizes retry, batching, encryption, filtering, routing, and credential management.

Domain 3: OpenTelemetry Collector

The Collector is a vendor-agnostic service for receiving, processing, and exporting telemetry. A receiver accepts data from push or pull sources. A processor changes or handles data. An exporter sends data to a destination. A connector acts as an exporter from one pipeline and a receiver into another. An extension adds service features such as health, authentication, or diagnostics without directly sitting in the telemetry data flow.

Configuration alone does not enable a component. Receivers, processors, exporters, and connectors must be listed in a service pipeline; extensions must be listed under service extensions. Components use type/name identifiers, allowing multiple configured instances of one type. Processor order is behavioral: redact or filter sensitive attributes before batching and export.

Collector distributions contain different components and stability levels. Inspect the selected distribution's component list and each component's documentation before assuming a configuration is portable. Pin the release and image digest. Run the validate command against the final merged configuration before rollout.

Deployment can begin with direct application export, then add agents and gateways. Agents run close to workloads or hosts and can collect local or host-specific data. Gateways centralize policy, routing, sampling, and backend export. Avoid collecting the same source from both paths. Use stable Resources so topology changes do not break service identity.

Scaling depends on processors. Stateless receive, batch, and export paths can often load-balance horizontally. Tail sampling needs all relevant spans for one trace at one decision point, requiring trace-aware routing. Other stateful processing may impose similar constraints. Measure CPU, memory, queue, network, backend, and uneven-key behavior rather than scaling replicas blindly.

Resilience is bounded. The memory limiter can refuse data before unsafe memory pressure; place it early and align it with container limits. Batch processing improves export efficiency. Sending queues and retries absorb temporary backend failure. Persistent queue storage can survive restarts for supported exporters. None guarantees no loss: queues fill, disks fail, credentials expire, and backends reject data. Define and monitor those limits.

Security begins with endpoint scope. Bind only where required, use TLS for transport, and add suitable client authentication or mTLS for remote producers. Protect certificate and token files, verify servers, rotate trust, and reject insecure skip-verification shortcuts in production. Diagnostic and debug endpoints may expose telemetry or internals and should remain private.

Domain 4: maintaining and debugging pipelines

Debug from source to destination. First ask whether instrumentation generated telemetry and whether sampling intentionally removed it. Then inspect SDK queue and export status, network and authentication, receiver acceptance, processor drops or errors, exporter queue and send failures, backend acceptance, and query freshness. Do not start by changing random configuration at the backend.

Collector internal telemetry is essential. Monitor accepted, refused, dropped, queued, sent, failed, CPU, memory, and latency where available for the chosen version and components. A healthy process endpoint proves liveness, not delivery. Coverage should become degraded when queues saturate, processors fail, exporters reject, or data becomes stale.

Context fragmentation is usually an application boundary problem. Verify outbound injection, carrier integrity, compatible propagators, and inbound extraction before blaming the Collector. Once spans are created with unrelated Trace IDs, a transport pipeline cannot safely infer the missing parent relationship.

Error handling requires known semantics. A receiver may refuse data and let a retry-capable sender retry. A processor may drop data intentionally or because of an error policy. An exporter may queue and retry transient failures. A backend may accept transport but reject content. Preserve evidence at each boundary and test what happens when capacity is exhausted.

Schema management spans producers and consumers. A renamed semantic attribute can break processor expressions, storage mapping, dashboards, alerts, and runbooks. Inventory consumers, version the change, transform or dual-read temporarily, validate old and new interpretation, assign an owner, and retire the compatibility path on a stated date.

An eight-week study plan

Week 1: signals, observability, outcomes, semantic conventions, and instrumentation approaches. Weeks 2 and 3: API versus SDK, Resources, scopes, spans, context, Baggage, sampling, metric instruments, Views, temporality, exemplars, logs, and OTLP. Build the first project and explain every emitted field.

Weeks 4 and 5: Collector components, configuration, enablement, processor order, connectors, extensions, distributions, agents, gateways, security, and transformation. Build the gateway project and validate all signal counts. Weeks 6 and 7: memory, batching, queues, retries, persistence, scaling, trace affinity, internal telemetry, and cost. Inject outages and account for loss.

Week 8: propagation debugging, source-to-backend triage, schema migration, coverage states, and timed review. Complete the troubleshooting project. Review all 40 flashcards and original checks by domain, focusing on why distractors assign responsibility to the wrong component.

Common mistakes

• Calling OpenTelemetry a backend. It instruments and transports telemetry; storage and analysis are separate.
• Letting libraries configure global SDK policy. Libraries use the API; applications own SDK behavior.
• Confusing Resource and instrumentation scope. One identifies the producing entity, the other the instrumentation module.
• Putting secrets in Baggage. Propagated context can cross trust boundaries and be logged.
• Creating duplicate spans. Automatic and custom instrumentation need deliberate boundaries.
• Ignoring shutdown. Buffered telemetry from short-lived processes can be lost.
• Configuring but not enabling Collector components. Service pipelines and extension lists activate them.
• Using the wrong processor order. Sensitive data may be batched or exported before redaction.
• Randomly balancing tail sampling. A trace split across replicas produces incomplete decisions.
• Calling liveness delivery health. A live Collector can still refuse or drop every record.
• Renaming schema without migration. Consumers silently lose or reinterpret data.

Three portfolio projects

The three-service instrumentation project creates correlated traces, metrics, and logs using code-based and zero-code instrumentation, W3C propagation, sampling, Views, and OTLP. The secure Collector project builds agent and gateway tiers with mTLS, ordered processors, queues, persistent buffering, trace-aware scaling, and internal telemetry. The troubleshooting project creates an independent oracle, breaks each pipeline stage, performs a schema migration, and exposes healthy, degraded, unknown, and stale states.

Use only synthetic data and disposable environments. Record architecture, trust boundaries, expected results, configuration, validation, fault injection, cost, privacy, cleanup, resume bullets, and interview explanations. State limitations: a local success does not prove production scale, complete delivery, or regulatory compliance.

Readiness checklist

• Explain the role and limits of traces, metrics, logs, semantic conventions, and instrumentation.
• Distinguish API, SDK, Resource, instrumentation scope, context, propagator, and Baggage.
• Choose span relationships, events, status, sampling, processors, metric instruments, Views, temporality, exemplars, and lifecycle behavior.
• Trace Collector data through receiver, ordered processors, connectors, exporters, extensions, and service enablement.
• Choose agent and gateway patterns and explain trace-aware scaling.
• Design bounded memory, queues, retries, persistence, TLS, authentication, and internal telemetry.
• Diagnose generation, propagation, processing, delivery, backend, and schema failures from evidence.

Continue learning

Official references

• Linux Foundation OTCA certification
• CNCF public curriculum repository
• OpenTelemetry documentation
• OpenTelemetry concepts
• Context propagation
• Instrumentation
• Collector documentation
• Collector configuration
• Collector troubleshooting
• OpenTelemetry specifications