OTCA study materials
OTCA study resources

OTCA case studies

OTCA · Put your knowledge to work in context.

The OpenTelemetry Certified Associate (OTCA) is a multiple-choice credential for engineers who work with OpenTelemetry, the vendor-neutral framework for generating, collecting, and exporting telemetry. It suits SREs, platform and DevOps engineers, backend developers, and observability specialists who instrument services, run a Collector, or maintain telemetry pipelines. The OTCA case studies are 5 cases and about 3,237 words.

1

Tail Sampling Drops the Errors You Care About

A payments team runs the OTel Collector as a gateway Deployment (3 replicas) behind a load balancer. All 40 services send OTLP/gRPC directly to it.

603 words, about 3 min
2

Baggage Survives HTTP but Vanishes at the Queue

A checkout service calls a payment service over gRPC (OTel auto-instrumented, W3C traceparent / tracestate propagators configured), then publishes to a Kafka topic consumed by a fraud service. The team uses Baggage to carry tenant.id and experiment.bucket end-to-end so downstream spans and logs can be sliced by tenant.

621 words, about 3 min
3

Span Metrics Cardinality Blows Up the Backend

A platform team enables the Collector's spanmetrics connector to derive RED metrics from traces. They send everything - including http.route for a public API with 30k distinct paths (user IDs in the path), http.status code , http.method , and tenant.id (bounded at ~500 tenants).

608 words, about 3 min
4

Auto-Instrumentation Misses the Async Path

An order service is a Java Spring Boot app using the OTel Java agent (auto-instrumentation). HTTP entry spans and JDBC calls appear correctly, and the service calls a downstream inventory service over gRPC - that span is also present.

732 words, about 4 min
5

The Collector That Drops Data Under Load and Hides It

A collector gateway is configured with memory limiter (limit 80% of 2Gi, spike 20%), batch (defaults), and otlp receivers/exporters. During a traffic spike (3× normal, ~50k spans/sec), the backend receives roughly 60% of expected spans.

673 words, about 3 min