Free OTCA (OpenTelemetry Certified Associate) practice: the 4 official domains, exam-style questions, a timed practice exam and more.
Play the OTCA map → · Official OTCA exam page
Telemetry data, semantic conventions, instrumentation, analysis and outcomes
Data model, composability, configuration, signals, SDK pipelines, context propagation, agents
Configuration, deployment, scaling, pipelines, transforming data
Context propagation, debugging pipelines, error handling, schema management
Answer: Traces; Metrics; Logs. Profiles are an emerging signal; dashboards and alerts are backend features, not signals.
Answer: The OpenTelemetry Protocol for sending telemetry between SDKs, Collectors and backends. OTLP runs over gRPC (port 4317) or HTTP (port 4318).
Answer: You instrument once and can send data to any compatible backend. Switching backends means changing exporter configuration, not code.
Answer: http.response.status_code. Current HTTP semantic conventions use http.request.method and http.response.status_code.
Answer: deployment.environment.name. Resource semantic conventions define where telemetry comes from.
Answer: Using the OpenTelemetry API directly in your code to create spans and metrics. It captures business-specific operations that zero-code instrumentation cannot know about.
Answer: A library that adds OpenTelemetry instrumentation to another library or framework (e.g. an HTTP client). Many are bundled into zero-code agents.
Answer: OTEL_SERVICE_NAME. OTEL_RESOURCE_ATTRIBUTES can set other resource attributes as key=value pairs.
Answer: Trace ID and span ID on the log record. Log appenders/bridges add the active trace context automatically.
Answer: Jumping from a metric spike to example traces and their logs. Exemplars and shared trace context make the jump possible.
Answer: Managing Collectors as custom resources; Injecting zero-code instrumentation into Pods. The OpenTelemetryCollector and Instrumentation CRDs.
Answer: OpenTelemetry does not store or visualize data; backends do. It covers generation, collection and export.
Answer: A timestamped annotation inside a span, e.g. an exception. Exceptions are recorded as events with exception.* attributes.
Answer: Relating a span to spans in other traces, e.g. a batch consumer processing many messages. Parent-child relationships use the parent span context, not links.
Answer: Starts a span and makes it the current span in the context. Child spans created inside then use it as their parent.
Answer: It is not exported. Always end spans, e.g. in a finally block.
Answer: SERVER. The outgoing call from the caller is CLIENT.
Answer: PRODUCER. The process that receives it creates a CONSUMER span.
Answer: Set status to Error (and record the exception as an event). Unset is the default; Ok is for explicitly confirmed success.
Answer: TraceIdRatioBased. Wrapping it in ParentBased makes child spans follow the root’s decision.
Answer: So downstream services follow the upstream sampling decision and traces stay complete. Otherwise each service could drop different spans of the same trace.
Answer: OTEL_TRACES_SAMPLER. OTEL_TRACES_SAMPLER_ARG sets its argument, e.g. 0.1.
Answer: Sending finished spans to a destination, e.g. OTLP or the console. Processors hand spans to exporters.
Answer: Histogram. The SDK aggregates histogram measurements into buckets.
Answer: ObservableGauge (asynchronous gauge). Asynchronous instruments are observed on each collection.
Answer: Counter. Counters are monotonic: they only accept non-negative increments.
Answer: Collects metrics from the SDK, on a schedule or on demand. A PeriodicExportingMetricReader pushes on an interval; a pull reader serves a Prometheus endpoint.
Answer: Changing how an instrument is aggregated or named, or dropping attributes. E.g. custom histogram buckets or removing a high-cardinality attribute.
Answer: Whether exported values are cumulative since start or deltas since the last export. Prometheus expects cumulative; some backends prefer delta.
Answer: Key-value pairs propagated with the context to downstream services. Baggage is not added to spans automatically — you read it where needed.
Answer: W3C Trace Context and W3C Baggage. OTEL_PROPAGATORS=tracecontext,baggage is the default.
Answer: Configure the B3 propagator (OTEL_PROPAGATORS=b3 or b3multi). Propagators and exporters are independent choices.
Answer: Headers such as traceparent (and tracestate, baggage). The receiver extracts them to continue the trace.
Answer: Letting existing logging libraries emit OpenTelemetry log records. Applications keep their logging library; an appender bridges to OTel.
Answer: The API. Only the final application should choose and configure the SDK.
Answer: Only one can be the global provider; registering should happen once at startup. Set the global provider once, early.
Answer: OTEL_TRACES_EXPORTER. Values include otlp (default), console and none.
Answer: 4318. 4317 is gRPC; 9411 is Zipkin; 14268 legacy Jaeger HTTP.
Answer: grpc, http/protobuf or http/json for OTLP exports. The default varies by language SDK.
Answer: Discover attributes about the environment (host, container, Kubernetes, cloud) automatically. Their attributes are merged into the Resource.
Answer: span.setAttribute(key, value). Attributes describe the operation; prefer semantic convention names.
Answer: SDK span limits (e.g. OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT). Excess attributes are dropped and counted.
Answer: Debugging or tests, where immediate export matters more than performance. It exports synchronously on span end.
Answer: Carrying the active span and baggage across function calls and threads. Context is propagated in-process and serialized across processes.
Answer: The context is propagated to it (automatically by instrumentation or manually). Lost context causes broken, disconnected traces.
Answer: A sample measurement linked to a trace ID, attached to a metric data point. It lets you jump from a histogram bucket to a trace.
Answer: Each unique attribute combination creates a separate time series. Avoid unbounded attributes such as user IDs.
Answer: Exports buffered telemetry so it is not lost. Batch processors hold spans in memory until they flush.
Answer: Sampler decides at span start; processors receive finished spans; exporters send them. Non-sampled spans are not recorded or exported.
Answer: How often the periodic metric reader exports. It is in milliseconds; the spec default is 60000 (one minute).
Answer: otelcol-contrib. You can also build a custom distribution with the OpenTelemetry Collector Builder (ocb).
Answer: Capabilities outside the data pipeline, e.g. health_check, pprof, zpages, auth. Extensions are listed under service.extensions.
Answer: k8sattributes. It looks up the source Pod by IP or resource attributes.
Answer: filter. Conditions are written in OTTL.
Answer: The OpenTelemetry Transformation Language used by processors like transform and filter. E.g. set(attributes["env"], "prod") where resource.attributes["k8s.namespace.name"] == "prod".
Answer: tail_sampling. It buffers spans and decides per trace based on policies like errors or latency.
Answer: Keeps a percentage of traces (head-style) inside the Collector. It hashes the trace ID so decisions are consistent.
Answer: One per node to receive local telemetry and collect node/host data. A gateway Deployment handles central processing.
Answer: Run multiple replicas behind a load balancer. Stateful processing like tail sampling needs trace-ID-aware routing instead.
Answer: loadbalancing. It keeps all spans of a trace on the same backend Collector.
Answer: prometheus. It accepts Prometheus scrape_configs.
Answer: hostmetrics. kubeletstats gives Pod/container stats from the kubelet.
Answer: filelog. Operators parse formats such as the container runtime log format.
Answer: It is sent to both exporters. Pipelines fan out to every listed exporter.
Answer: Yes — e.g. otlp in traces, metrics and logs pipelines. Each pipeline gets its own copy of the data.
Answer: type/name, e.g. otlp/backend1 and otlp/backend2. The suffix after / makes the ID unique.
Answer: ${env:API_KEY}. Confmap providers also support file: and others.
Answer: otelcol validate --config=config.yaml. Distribution binaries such as otelcol-contrib have the same subcommand.
Answer: spanmetrics. Connectors are exporters in one pipeline and receivers in another — here traces in, metrics out.
Answer: Modifies telemetry with OTTL statements (set, delete, rename…). Use the spanmetrics connector to derive metrics from traces.
Answer: It compresses many items into fewer export calls after filtering and transforming. Batching before filtering would waste work on data you drop.
Answer: Context is not propagated between them (missing or mismatched propagators). Check that the caller injects and the callee extracts the same header format.
Answer: otelcol_exporter_send_failed_spans (and _metric_points, _log_records). Compare with otelcol_exporter_sent_* to see loss.
Answer: The Collector is near its memory limit — scale out or reduce load. Refused data is reported to the sender, which may retry.
Answer: zpages. pprof is for profiling; health_check for liveness.
Answer: Configure it with persistent storage (e.g. the file_storage extension). In-memory queues are lost on restart.
Answer: Schema URLs and schema transformations map old names to new. Telemetry schemas describe changes between versions.
Answer: Switch the exporter to console/debug and verify spans are produced. Then check endpoint, protocol (gRPC vs HTTP) and sampling.
Answer: service.name. service.name is a resource attribute; without it backends show "unknown_service".
Answer: Common attribute names let any backend and dashboard interpret data from any library. Consistent names (http.request.method, db.system) make telemetry portable and comparable.
Answer: The calls are no-ops — nothing is recorded or exported. The API ships with no-op implementations so library instrumentation costs nothing until an SDK is registered.
Answer: traceparent. W3C Trace Context (traceparent, tracestate) is the default propagator; B3 is Zipkin’s format.
Answer: BatchSpanProcessor. Batching amortizes export cost and keeps request latency independent of the backend.
Answer: UpDownCounter. Counters must be monotonic; UpDownCounter accepts increments and decrements.
Answer: OTEL_EXPORTER_OTLP_ENDPOINT. It is defined by the spec, so the same variable works for every language SDK.
Answer: It is not referenced in a pipeline under service.pipelines. Only components listed in a service pipeline are started.
Answer: memory_limiter first, batch near the end. Refuse data early when memory is tight; batch after the transformations, right before export.
Answer: Agents forward to a gateway tier, load-balanced by trace ID (loadbalancing exporter). Routing by trace ID guarantees all spans of a trace reach the same gateway instance.
Answer: Add the debug exporter (verbosity: detailed) to the pipeline. The debug exporter prints the telemetry the pipeline sees to the Collector logs.
Answer: Exporter retry_on_failure with a sending_queue (optionally persistent). Retries with backoff plus a queue buffer the data until the backend returns.