OTCA sample questions with answers

OTCA sample questions

OpenTelemetry Certified Associate (OTCA), CNCF / The Linux Foundation.

1. Question 1

   Domain: Fundamentals of Observability

   A Flask service runs with python app.py. The team wants traces for Flask and requests without changing app.py.

   Which sequence enables zero-code instrumentation for this Python application?

   1. Run opentelemetry-bootstrap -a install, then start with opentelemetry-instrument python app.py
   2. Install opentelemetry-sdk, then start the app with python -m opentelemetry app.py
   3. Install opentelemetry-api, then add import opentelemetry.auto as the first line of app.py and restart
   4. Run opentelemetry-collector --instrument python app.py on the same host as the app
   Show the answer

   Answer: A. Run opentelemetry-bootstrap -a install, then start with opentelemetry-instrument python app.py

   opentelemetry-bootstrap -a install detects installed packages and installs the matching instrumentation libraries, and opentelemetry-instrument wraps the process so they are activated at start-up. Installing only the API adds no instrumentation, and there is no import-based auto switch.

   Checked against: https://opentelemetry.io/docs/zero-code/python/

2. Question 2

   Domain: Fundamentals of Observability

   An Express application is started with node app.js in a container. The team may only change the container's start command and environment.

   Which start command enables the Node.js auto-instrumentations without code changes?

   1. node --instrument @opentelemetry/sdk-node --exporter=otlp app.js
   2. node --require @opentelemetry/auto-instrumentations-node/register app.js
   3. npx opentelemetry-instrument --traces_exporter otlp node app.js
   4. node --import @opentelemetry/api --experimental-loader=@opentelemetry/sdk-node app.js
   Show the answer

   Answer: B. node --require @opentelemetry/auto-instrumentations-node/register app.js

   Requiring the register entry point of @opentelemetry/auto-instrumentations-node sets up the Node SDK and the bundled instrumentations before the application loads, configured through OTEL_* variables. Loading only the API registers nothing, and opentelemetry-instrument is the Python wrapper, not a Node tool.

   Checked against: https://opentelemetry.io/docs/zero-code/js/

3. Question 3

   Domain: The OpenTelemetry API and SDK

   A consumer pulls 50 messages in one batch and processes them in a single span. Each message was produced in a different trace and carries its own trace context.

   How should the batch span relate to the originating message traces?

   1. Make the first message's span the parent and ignore the remaining messages
   2. Create 50 parent spans for the batch span, one for each consumed message
   3. Add span links to each message's span context, since a span has only one parent
   4. Copy all 50 trace IDs into a single span attribute stored as a string list for lookup
   Show the answer

   Answer: C. Add span links to each message's span context, since a span has only one parent

   Links let a span reference any number of other span contexts, including ones from different traces, which is the recommended model for batch processing. A span can have only one parent, so choosing the first message would lose the causal link to the other 49.

   Checked against: https://opentelemetry.io/docs/concepts/signals/traces/#span-links

4. Question 4

   Domain: The OpenTelemetry API and SDK

   Application code calls span.setStatus(Ok) after validating input, and later in the same span a helper calls span.setStatus(Error, "timeout").

   What status does the span have at the end?

   1. Ok, because a status of Ok is final and later changes should be ignored
   2. Error, because the most recent call to set the status on a span always wins
   3. Unset, because conflicting status values cancel each other out
   4. Error, because Error always takes precedence over an earlier Ok
   Show the answer

   Answer: A. Ok, because a status of Ok is final and later changes should be ignored

   The trace API says that when the status is set to Ok it should be treated as final, and any later attempts to change it should be ignored; this is also why instrumentation libraries are told to leave the status Unset rather than set Ok. Setting Error last does not override an earlier Ok.

   Checked against: https://opentelemetry.io/docs/specs/otel/trace/api/#set-status

5. Question 5

   Domain: The OpenTelemetry API and SDK

   In OpenTelemetry, what does a Resource represent?

   1. The library or module that created a particular span, metric or log record in the process
   2. The entity producing telemetry, such as a service, host or pod, described by attributes
   3. The backend endpoint and tenant that the telemetry is finally exported to
   4. The request-scoped key-value pairs that are propagated between services
   Show the answer

   Answer: B. The entity producing telemetry, such as a service, host or pod, described by attributes

   A Resource is an immutable set of attributes such as service.name, host.name or k8s.pod.name that identifies what produced the telemetry, and the SDK attaches it to every span, metric and log record. The library that emitted the data is the instrumentation scope, a separate concept that is easy to confuse with it.

   Checked against: https://opentelemetry.io/docs/concepts/resources/

6. Question 6

   Domain: The OpenTelemetry API and SDK

   If OTEL_PROPAGATORS is not set, which propagators does a conforming SDK configure?

   1. B3 multi-header and W3C Baggage for compatibility (b3multi,baggage)
   2. W3C Trace Context only (tracecontext)
   3. No propagators until one is set explicitly (none)
   4. W3C Trace Context and W3C Baggage (tracecontext,baggage)
   Show the answer

   Answer: D. W3C Trace Context and W3C Baggage (tracecontext,baggage)

   The specification sets the default of OTEL_PROPAGATORS to tracecontext,baggage. Trace Context alone is a common misremembering, but it would silently stop baggage from crossing service boundaries.

   Checked against: https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#general-sdk-configuration

7. Question 7

   Domain: The OpenTelemetry Collector

   A config declares extensions: health_check: {} at the top level, and the pipelines work, but nothing listens on the health check port.

   Why is the health endpoint not available?

   1. health_check only works with the contrib distribution and listens on port 8888
   2. Extensions must be added to each pipeline's processors list
   3. Extensions must also be listed under service.extensions to be enabled
   4. health_check requires a pipeline of type health
   Show the answer

   Answer: C. Extensions must also be listed under service.extensions to be enabled

   Like other components, extensions are only configured by their top-level section; they are enabled by adding them to the service.extensions list. They are not part of pipelines, because they do not process telemetry.

   Checked against: https://opentelemetry.io/docs/collector/configuration/#extensions

8. Question 8

   Domain: The OpenTelemetry Collector

   Which statement about Collector pipelines is correct?

   1. A pipeline may mix traces and metrics as long as its receiver accepts both signal types
   2. Each pipeline has one signal type, one or more receivers, ordered processors and one or more exporters
   3. A pipeline must have exactly one receiver and exactly one exporter to be considered valid
   4. Processors in a pipeline run in parallel on each incoming batch, so their listed order does not matter
   Show the answer

   Answer: B. Each pipeline has one signal type, one or more receivers, ordered processors and one or more exporters

   Each pipeline is defined for a signal such as traces, metrics or logs, accepts several receivers, applies processors sequentially and sends a copy of the data to each exporter. Processor order matters because each one sees the output of the previous one.

   Checked against: https://opentelemetry.io/docs/collector/architecture/

9. Question 9

   Domain: The OpenTelemetry Collector

   A gateway Collector must tag all traces from one cluster with deployment.environment.name=production using the transform processor's trace_statements.

   Which transform statement adds the attribute to every span's resource?

   1. add(resource.deployment.environment.name, "production")
   2. resource.attributes.deployment.environment.name = "production"
   3. insert("deployment.environment.name") where resource.name == "production"
   4. set(resource.attributes["deployment.environment.name"], "production")
   Show the answer

   Answer: D. set(resource.attributes["deployment.environment.name"], "production")

   OTTL modifies data with editor functions such as set, whose first argument is a path like resource.attributes["key"] and whose second is the value. OTTL has no assignment operator or add function, so the other forms are not valid statements.

   Checked against: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md

10. Question 10

    Domain: Maintaining and Debugging Observability Pipelines

    A team upgrades HTTP instrumentation that supports the stable HTTP semantic conventions. Existing dashboards query the old attribute names and cannot all be rewritten at once.

    Which setting supports a gradual migration of the dashboards?

    1. OTEL_SEMCONV_STABILITY_OPT_IN=http/dup, emitting both old and stable attributes
    2. OTEL_SEMCONV_STABILITY_OPT_IN=http, emitting both the old and stable attributes
    3. OTEL_SEMCONV_VERSION=latest, rewriting the old attributes in the backend
    4. OTEL_RESOURCE_ATTRIBUTES=schema_url=stable, upgrading every attribute
    Show the answer

    Answer: A. OTEL_SEMCONV_STABILITY_OPT_IN=http/dup, emitting both old and stable attributes

    The HTTP migration guide defines http/dup to emit both the old and the new stable conventions, so dashboards can be moved over before old attributes disappear. Setting http alone switches to the stable conventions only, which would break old dashboards immediately.

    Checked against: https://opentelemetry.io/docs/specs/semconv/non-normative/http-migration/