OTCA practice test
OpenTelemetry Certified Associate · free · 42 questions in the bank today
By Ibrahim Yesilay · Published · Updated
Start a free OTCA practice test: OpenTelemetry Certified Associate questions with an instant verdict and explanation, an order that returns to your weakest domains, and a timed mock with the official time limit. The official OTCA exam is 60 questions in 90 minutes with a passing score of 75%, as read from the Linux Foundation documentation on 2026-10-28.
Ten guest answers need no account; mock exams need a free one. Independent practice, not affiliated with the CNCF or the Linux Foundation.
OTCA exam snapshot
Exam facts from the Linux Foundation pages, checked 2026-10-28; full table with sources on the OTCA certification page.
What this OTCA practice test is
This page starts a free OTCA practice session on GoldenKube. The official OTCA exam is 60 questions in 90 minutes with a passing score of 75%, as read from the Linux Foundation documentation on 2026-10-28. The GoldenKube OTCA bank held 42 questions when this page was written; the live count is shown above. One question at a time. As soon as you answer you see whether you were right and read the explanation; reloading the page keeps the verdict on screen. The next question comes from the questions due for review first, then from the domain where you are weakest and still have unseen questions, then from the rest of the bank. Use it to learn the vocabulary of the API, the SDK and the Collector, and read the specification for the API and SDK domain alongside it.
Every OTCA question in the bank has a written explanation, so a wrong answer is always followed by the reasoning that fixes it.
What the OTCA bank covers
The OTCA bank is small and spread evenly over the four domains, so the API and SDK domain, almost half of the exam, has a much smaller share of the bank than its weight, and pipeline debugging a larger one. The table compares the official domain weights, checked against the OTCA certification page on 2026-10-28, with the share of the bank each domain holds and the number of explained questions, both read from the database when the page is served. The OpenTelemetry API and SDK is the heaviest domain at 46%, so it deserves the largest share of your study time whatever the bank's share is.
| Official domain | Exam weight | Bank share | Questions | Explained |
|---|---|---|---|---|
| Fundamentals of Observability | 18% | 24% | 10 | 10 |
| The OpenTelemetry API and SDK | 46% | 29% | 12 | 12 |
| The OpenTelemetry Collector | 26% | 21% | 9 | 9 |
| Maintaining and Debugging Observability Pipelines | 10% | 26% | 11 | 11 |
All 42 questions have a written explanation. Live from the database; the OTCA bank coverage report explains the method.
A domain whose bank share is well below its weight is one to study from the official curriculum and the project documentation as well; the bank-coverage report linked below tracks these gaps over time.
How the bank covers the OTCA curriculum
The OTCA curriculum puts almost half of the exam, 46%, on a single domain: the OpenTelemetry API and SDK, with seven topics from the data model to context propagation and agents. The GoldenKube OTCA bank is one of the smallest on the site and spreads its 42 questions far more evenly, with 12 on the API and SDK and 11 on maintaining and debugging pipelines, a domain worth only 10%. In other words the bank over-represents pipeline debugging and under-represents the API and SDK compared with the exam. Use the bank to learn the vocabulary of every domain, and plan extra reading in the specification for the API and SDK topics in the cards. Every question maps to one official domain. Counts come from the seed bank at build time; topics are quoted from the curriculum PDF.
Fundamentals of Observability
18% of the exam · 10 questions in the bank
What telemetry is, how semantic conventions name it and what instrumentation should let you conclude.
Official curriculum topics
- Telemetry Data
- Semantic Conventions
- Instrumentation
- Analysis and Outcomes
The OpenTelemetry API and SDK
46% of the exam · 12 questions in the bank
How the API, the SDK and their pipelines produce, process and export each signal, and how context crosses process boundaries.
Official curriculum topics
- Data Model
- Composability and Extension
- Configuration
- Signals (Tracing, Metric, Log)
- SDK Pipelines
- Context Propagation
- Agents
The OpenTelemetry Collector
26% of the exam · 9 questions in the bank
How a Collector is configured, deployed and scaled, and how its pipelines receive, transform and export data.
Official curriculum topics
- Configuration
- Deployment
- Scaling
- Pipelines
- Transforming Data
Maintaining and Debugging Observability Pipelines
10% of the exam · 11 questions in the bank
How to find out why telemetry is missing or wrong, and how errors and schema changes are handled.
Official curriculum topics
- Context Propagation
- Debugging Pipelines
- Error Handling
- Schema Management
Weights from the official certification page; question counts from the GoldenKube bank when this page was built; topics as named in the CNCF curriculum PDF listed under Sources.
Try three OTCA questions
Three questions from the bank with their answers and explanations. The OTCA sample-questions page has twenty more; the practice session has the whole bank.
Question 1
- A.Sidecar Agent
- B.Centralized Collector
- C.Kubernetes Operator
- D.Standalone Server
Correct answer: C
Question 2
- A.The API is used for instrumenting applications, while the SDK processes and exports data
- B.The API stores telemetry data, while the SDK retrieves it
- C.The SDK provides application interfaces, while the API only handles traces
- D.The API is required for tracing, but the SDK is optional
Correct answer: A
Question 3
- A.To store telemetry data
- B.To define language-specific interfaces for instrumentation
- C.To aggregate telemetry data
- D.To send alerts to Prometheus
Correct answer: B
How to practise OTCA with GoldenKube
With 42 questions, the OTCA bank can be seen in full in one or two sittings, so the loop spends more time on the specification than on new questions. Answer the bank once in the adaptive order; every miss climbs the review ladder (12 other answers, then 1 day, then 4 days) and only leaves it after three correct answers in a row. Because the bank is small, the review ladder and the bookmarks list do most of the work after day 2: you will see the same questions again, so read each explanation for the reason behind the answer and not the answer itself. Put the gap between bank and exam weight to use by reading the API and SDK parts of the specification alongside practice. The mock exam draws all 42 questions, fewer than the official 60, in the official 90 minutes, so it rehearses reading speed but not stamina.
The 14-day loop, and the same steps in 7 days
- Days 1-27-day plan: Day 1Answer the whole bank in the adaptive order and bookmark every question about ports, environment variables or pipeline order.
- Days 3-57-day plan: Day 2Read the API and SDK topics in the specification (signals, SDK pipelines, context propagation), then Focus mode on The OpenTelemetry API and SDK.
- Days 6-77-day plan: Day 3Run a Collector locally with one OTLP receiver, a memory_limiter and a batch processor and one exporter; then Focus mode on The OpenTelemetry Collector.
- Days 8-97-day plan: Day 4Clear the due reviews, then Focus mode on Maintaining and Debugging Observability Pipelines and Fundamentals of Observability.
- Day 107-day plan: Day 5Timed mock exam; compare the by-domain breakdown with the 46% weight of the API and SDK domain.
- Days 11-137-day plan: Day 6Practise the bookmarks list from the Review center and reread the specification sections behind every miss.
- Day 147-day plan: Day 7Second mock exam, then a last pass over the default ports and environment variables.
Because every question will be familiar by the second week, a high mock score at the end mostly measures recall of this bank. Treat the specification reading in days 3 to 7 as the real preparation for the API and SDK domain.
Common OTCA mistakes
OTCA questions lean on defaults: ports, environment variables, which component is enabled and in what order processors run. The pitfalls below are stated as the OpenTelemetry specification, the Collector documentation and the Collector component READMEs state them, each with a link. They are the details most likely to separate two otherwise plausible options.
1. Swapping the OTLP ports
The default port for OTLP over gRPC is 4317 and for OTLP over HTTP it is 4318. An SDK pointed at 4317 with the HTTP exporter, or the reverse, fails to export.
2. Adding /v1/traces to a signal-specific endpoint
With OTEL_EXPORTER_OTLP_ENDPOINT the exporter appends /v1/traces, /v1/metrics or /v1/logs. A signal-specific variable such as OTEL_EXPORTER_OTLP_TRACES_ENDPOINT is used as-is, so it must contain the full path.
3. Configuring a component but not adding it to a pipeline
A receiver, processor, exporter or extension defined in its section but not referenced in the service section is not enabled. The Collector loads it and does nothing with it.
4. Putting processors in any order
Processors run in the order the pipeline lists them. The memory_limiter README advises placing it first so backpressure reaches receivers, and the batch processor should come after the memory_limiter and any sampling processors.
5. Assuming the SDK samples a fraction of traces by default
The default sampler is ParentBased(root=AlwaysOn): root spans are always sampled and child spans follow their parent. OTEL_TRACES_SAMPLER defaults to parentbased_always_on.
6. Expecting head sampling to keep every error trace
Head sampling decides early, before the whole trace exists, so it cannot guarantee that all traces with an error are kept. That needs tail sampling, which must be stateful and hold a large amount of data.
7. Forgetting which propagators are on by default
OTEL_PROPAGATORS defaults to tracecontext,baggage, the W3C Trace Context and W3C Baggage formats. A service that expects B3 headers needs b3 or b3multi configured explicitly.
Mock exam
The official OTCA exam has 60 questions, but the bank holds 42, and a mock never repeats a question, so the OTCA mock exam uses all 42 with the official 90 minutes and the 75% threshold. That leaves more time per question than the real exam: it checks every domain under a clock, not pacing or stamina, and the result is practice feedback. Mock exams need a free account; your history of runs is kept on the exam's mock page.
Frequently asked questions
Is the OTCA practice test free?
Yes. Your first 10 answers need no account. After that a free account keeps your progress; there is no paid tier and no card.
How many OTCA questions are there?
42 when this page was written; the live count from the database is shown at the top of the page. Questions are added and corrected over time.
Does the OTCA practice test match the real exam format?
Partly. The mock exam uses the published 90 minutes and 75% pass mark, but the bank has 42 questions, fewer than the official 60, so a mock uses all of them. Practice mode is untimed and adaptive. The questions are GoldenKube's own, not exam content.
Where are more sample questions with answers?
The OTCA sample-questions page shows 20 questions with answers and explanations without an account, and each OTCA topic page shows three more for its subdomain.
What does OTEL_SERVICE_NAME do?
It sets the service.name resource attribute. If service.name is also given in OTEL_RESOURCE_ATTRIBUTES, OTEL_SERVICE_NAME takes precedence, which is a common source of confusion when two configuration layers set the name.
Which header carries the trace context between services?
With the default W3C Trace Context propagator, the trace ID and the parent span ID travel in the traceparent HTTP header, so the receiving service can continue the same trace. Baggage is propagated separately with the W3C Baggage format.
Why is the OTCA mock exam shorter than 60 questions?
A mock never repeats a question, and the bank holds 42, so the mock uses all of them with the official 90 minutes and 75% pass mark. That gives more time per question than the real exam; treat the result as a check of each domain, not of pacing.
Sources
- OpenTelemetry Certified Associate (official certification page) (read )
- CNCF curriculum: OTCA Curriculum (PDF) (read )
- Collector README: batch processor (read )
- OpenTelemetry docs: Context propagation (read )
- OpenTelemetry spec: OTLP (default ports) (read )
- OpenTelemetry spec: OTLP exporter configuration (read )
- OpenTelemetry docs: Collector configuration (read )
- Collector README: memory_limiter processor (read )
- OpenTelemetry spec: Tracing SDK (samplers) (read )
- OpenTelemetry docs: Sampling concepts (read )
- OpenTelemetry spec: SDK environment variables (read )
Last updated