CertGrid
Cloud Native Certification

OTCA: OpenTelemetry Certified Associate Practice Exam

Validates observability fundamentals and the OpenTelemetry project - telemetry collection, instrumentation and SDKs, metrics, traces, logs and exporters, and integration with observability backends.

Start with a free OTCA practice test, then work through 713 exam-style questions with full answer explanations, and take timed mock exams to track your readiness against the exam objectives.

Free account: a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full bank and timed mock exams. No credit card required to start.

713
Practice pool
Not published
Real exam
90 min
Real exam time
Intermediate
Level
75%
Passing score

CertGrid runs a fixed 60-question timed mock, separate from the real exam format above.

Objective-mapped practice, aligned to current exam objectives · Reviewed Oct 2026 · Independent practice platform.

What the OTCA exam covers

Free OTCA practice test questions

A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 713-question bank.

  1. Question 1Fundamentals of Observability

    An engineer asks which signals OpenTelemetry uses to record telemetry data about a running system. What is the answer?

    • ATraces, metrics and logsCorrect
    • BTraces and metrics only
    • CMetrics and logs only
    • DTraces, metrics, logs and dashboards
    ✓ Correct answer: A

    Traces describe the path of a request, metrics describe aggregate numeric behaviour over time, and logs describe discrete events - each has its own specification, API surface and data model, while sharing resource attributes and context so they can be correlated. The signals page also lists baggage, which propagates context between services rather than recording telemetry, and names profiles as a signal still under development.

    Why the other options are wrong
    • BTraces and metrics leaves out logs, which is a defined signal.
    • CMetrics and logs omits traces, which the signals page lists as a supported signal alongside metrics, logs and baggage.
    • DDashboards are a backend concern rather than a telemetry signal.
  2. Question 2The OpenTelemetry API and SDK

    A team must decide where a trace begins. What creates the root span?

    • AThe first span created with no parent in contextCorrect
    • BThe span with the longest duration in the trace
    • CThe span belonging to the first service alphabetically
    • DThe span the collector receives first
    ✓ Correct answer: A

    When a request arrives with no incoming trace context, the span created for it has no parent and starts a new trace, generating a fresh trace identifier that then propagates onward. Everything downstream becomes a descendant regardless of arrival order or duration.

    Why the other options are wrong
    • BDuration has no bearing on which span is the root.
    • CService naming plays no part in trace structure.
    • DArrival order at the collector is not the trace structure.
  3. Question 3The OpenTelemetry Collector

    An SRE team must reduce log volume without losing the ability to investigate incidents. Which approach fits?

    • ADropping records below error severityCorrect
    • BSampling one in ten records at random
    • CTruncating every record to a fixed length
    • DRemoving the timestamp from each record
    ✓ Correct answer: A

    Debug and info records dominate volume while contributing least during an incident, so a severity filter removes most of the cost and none of the errors. Random sampling would discard errors at the same rate as everything else, which is the opposite of what is wanted.

    Why the other options are wrong
    • BRandom sampling discards errors at the same rate as routine records.
    • CTruncating records to a fixed length destroys the detail in each.
    • DRemoving the timestamp saves little and makes records unusable.
  4. Question 4The OpenTelemetry API and SDK

    An engineering team must decide where to put the code that configures the SDK in a library-heavy application. Where does it belong?

    • AIn the application's own startup path before other workCorrect
    • BIn the first library that needs to record a span
    • CIn a shared internal package every service imports
    • DIn the collector configuration for that service
    ✓ Correct answer: A

    Setting it up in the entry point means the providers are in place before any library creates a tracer, and it keeps the choice of exporter and sampler with the team that owns the deployment. A library doing it would impose those choices on every consumer.

    Why the other options are wrong
    • BA library configuring the SDK imposes its choices on consumers.
    • CA shared package can help but must still be called from startup.
    • DCollector configuration cannot set up an application's SDK.
  5. Question 5The OpenTelemetry API and SDKSelect all that apply

    The open question is what makes manual instrumentation worth maintaining over time. Which TWO practices help? (Choose TWO)

    • AFollowing the conventions so the spans stay comparableCorrect
    • BKeeping spans coarse enough that refactoring rarely breaks themCorrect
    • CAdding a span for every private method for completeness
    • DNaming spans after the current implementation classes
    • ERecording every local variable as an attribute
    ✓ Correct answer: A, B

    Spans placed at meaningful boundaries and named for what they achieve keep working when the code beneath them is rewritten, while conventional attribute names mean the data stays usable in shared dashboards. Fine-grained spans tied to structure become maintenance debt.

    Why the other options are wrong
    • CA span per private method tends to break whenever the code is restructured and adds overhead for little insight.
    • DNames tied to implementation classes change whenever those classes are renamed or reorganised, breaking queries on the name.
    • ERecording every local variable is noise and a privacy risk.
  6. Question 6The OpenTelemetry API and SDKSelect all that apply

    A service owner is deciding what to do before adding a new attribute to an existing metric. Which TWO considerations apply? (Choose TWO)

    • AHow many distinct values the attribute will takeCorrect
    • BHow the change multiplies the existing series countCorrect
    • CWhether the backend supports string attributes
    • DWhether the SDK version is the latest available
    • EWhether the metric name follows conventions
    ✓ Correct answer: A, B

    Adding a key with ten values to a metric that already has two hundred series can produce up to two thousand, so the question is the product rather than the new key alone. Estimating that before the change is far cheaper than discovering it on a bill.

    Why the other options are wrong
    • CString attributes are universally supported.
    • DSDK currency is unrelated to the cardinality decision.
    • EThe metric name is already established at this point.
  7. Question 7The OpenTelemetry API and SDKSelect all that apply

    A team is deciding what belongs in the resource for a service. Which TWO attributes are most valuable? (Choose TWO)

    • AThe service nameCorrect
    • BThe deployment environmentCorrect
    • CThe current request identifier
    • DThe user's session token
    • EThe response body of the last call
    ✓ Correct answer: A, B

    Those two let a backend separate the same service running in staging from production and group everything a service emits, which almost every query and dashboard depends on. Per-request values belong on spans rather than on the resource, which describes the entity producing the telemetry.

    Why the other options are wrong
    • CThe current request identifier varies per request and belongs on a span.
    • DA session token is a credential tied to one user's session, so it is unsafe to record and is not a property of the service.
    • EThe response body of the last call is neither identity nor safe to attach.
  8. Question 8The OpenTelemetry Collector

    A filter processor is added with the conditions below. Which spans does it drop? ```yaml processors: filter: error_mode: ignore trace_conditions: - resource.attributes["service.name"] == "healthz" - span.name == "GET /ping" ```

    • AOnly spans from the healthz service that are also named GET /ping
    • BSpans from the healthz service or named GET /ping, either oneCorrect
    • CEvery span except those from healthz or named GET /ping
    • DNo spans, since conditions on two contexts need an and group
    ✓ Correct answer: B

    The filter processor uses OTTL conditions to decide what to drop, and if any condition is met the telemetry is dropped. The conditions in a list are ORed together, so a span matching either the resource condition or the span name condition is removed. Each condition is parsed on its own and grouped by its inferred context, with resource conditions evaluated before span conditions. To keep only certain telemetry, the transforming telemetry page writes a single condition that negates the wanted values. With error_mode: ignore, a condition that errors is logged and processing continues.

    Why the other options are wrong
    • ARequiring both would need one condition joined with and; separate list entries are ORed, so either match drops the spans.
    • CThe filter processor drops what matches its conditions and keeps every other span, not the other way round.
    • DConditions on different contexts can sit in one list, since each is parsed and grouped by its own context.
  9. Question 9The OpenTelemetry API and SDK

    A newcomer asks what happens when telemetry is produced faster than it can be exported. What does the SDK do?

    • ARecords beyond the maximum queue size are droppedCorrect
    • BThe application is slowed until the queue drains
    • CRecords are written to disk until the backlog clears
    • DThe exporter opens additional connections indefinitely
    ✓ Correct answer: A

    The batching processor has a maximum queue size (2048 spans by default for traces), and after it is reached new spans are dropped rather than blocking the code that ended them. The SDK self-monitoring metric otel.sdk.processor.span.processed counts such drops with error.type queue_full, which is how sustained overload becomes visible.

    Why the other options are wrong
    • BThe application is not slowed until the queue drains; the processor drops spans at the limit instead of blocking.
    • CSDKs do not write telemetry to disk by default.
    • DExporters do not open unbounded numbers of connections.
  10. Question 10Maintaining and Debugging Observability Pipelines

    A service deployed to fifty pods produces telemetry from forty-eight. The two silent pods serve traffic normally and their logs show no SDK errors. What is the most productive next check?

    • AWhether the SDK was initialised at all in those two podsCorrect
    • BWhether the backend has capacity for two more instances
    • CWhether the service name differs from the other forty-eight
    • DWhether their spans exceed the attribute count limit
    ✓ Correct answer: A

    The error handling specification says a library should log an error it suppresses, and an OTLP exporter that cannot reach its endpoint retries transient errors and then fails, so a blocked network path would normally leave export errors in the SDK's log. Clean logs from pods that serve traffic point at setup that never ran there, such as a missing environment variable, an agent not attached or an injection annotation absent from those pods. Comparing the effective configuration of a silent pod with a working one confirms it.

    Why the other options are wrong
    • BBackend capacity would not single out two pods of one service while accepting telemetry from the other forty-eight.
    • CA different service name would produce telemetry under that name.
    • DAttribute count limits discard extra attributes on a span rather than suppressing the span itself.

Who this OTCA practice exam is for

This practice set is for anyone preparing for the OTCA: OpenTelemetry Certified Associate exam at the intermediate level - from first-time candidates building a foundation to experienced Cloud Native practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this OTCA practice exam

  1. Start with the free sample questions above to gauge your current baseline.
  2. Read the full explanation on every question, including why each wrong option is wrong.
  3. Track your weak domains and focus your study where you are losing the most marks.
  4. Once you are scoring consistently well, take a timed, full-length mock exam.
  5. Use your readiness score to decide when you are ready to book the real OTCA exam.

Related Cloud Native resources

OTCA practice exam FAQ

How many questions are in the OTCA practice exam on CertGrid?

CertGrid has 713 practice questions for OTCA: OpenTelemetry Certified Associate, covering 4 exam domains. The real OTCA exam runs 90 min. The vendor does not publish a question count for it, so the length of CertGrid's mock is CertGrid's own choice. CertGrid's timed mock is a fixed 60 questions.

What is the passing score for OTCA?

The Linux Foundation does not publish a passing score or a question count for OTCA. CertGrid grades this mock against its own 0-1000 threshold using the CNCF associate convention, so read your score as readiness rather than as a vendor result. You have about 90 min to complete it. CertGrid tracks your readiness against the exam objectives so you know where to focus.

Are these official OTCA exam questions?

No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the OTCA: OpenTelemetry Certified Associate exam.

Is there a free OTCA practice test?

Yes. You can take a free OTCA: OpenTelemetry Certified Associate practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 713-question bank, timed mock exams and full-bank domain analytics.

What CertGrid is (and is not)

CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.

Independent & original. CertGrid is not affiliated with or endorsed by Microsoft, AWS, Google, Cisco, CompTIA, the Linux Foundation, HashiCorp, or other certification vendors. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.