20 Free OTCA Sample Questions with Answers

How to use these OTCA practice questions

Work through the 20 OTCA sample questions in one sitting without looking anything up. For each question, decide on an answer first, then open the answer and read the explanation, including when you were right, because a correct guess and a correct line of reasoning look identical until the exam rewords the question. Mark every question as right, wrong or guessed, and count a guess as wrong when you score yourself. Give the set about 30 minutes, which is the average time per question on the real exam multiplied by twenty. The aim is to find out which exam domains are already solid and which ones need study before you buy the exam.

The official exam format is 60 questions in 90 minutes, with a passing score of 75%, according to the Linux Foundation documentation checked on 2026-10-23.

With JavaScript enabled, each answer starts collapsed behind a Show answer button so you can test yourself. Without JavaScript, and for any crawler or screen reader that reads the raw page, every answer and explanation is already visible below its question.

These questions were written for GoldenKube practice. They are not copied from the real exam, and nothing on this page tells you what the real exam will ask.

• Read the question twice and underline the constraint words: "most", "least", "first", "only", "not".
• Eliminate options you can prove wrong before you pick between the rest.
• Where a question says to select all that apply, every correct option must be chosen and none of the wrong ones.
• Read the explanation even for questions you got right; it often names the nearby concept the exam likes to swap in.

Fundamentals of Observability (4 questions)

The OpenTelemetry API and SDK (9 questions)

The OpenTelemetry Collector (5 questions)

Maintaining and Debugging Observability Pipelines (2 questions)

Score yourself

The Linux Foundation lists a passing score of 75% for OTCA. On a set of 20 questions that is 15 correct. Reaching 15 here is a useful signal and not a prediction: 20 questions is a small sample, and the real exam covers every domain in its published weights. Use the table below to decide what to do next. Count only the questions you answered correctly without help, and be strict about it: a question you got right for the wrong reason belongs in the missed pile. Then repeat the exercise a few days later with a different set from the full bank so that you are measuring understanding and not memory of these specific questions.

Count your misses per domain, using the headings above. One missed question in a domain is noise; three misses in one domain is a study plan. The practice mode on GoldenKube does this sorting for you by sending you back to the domains where you are weakest.

Fundamentals of Observability: what it tests

Fundamentals of Observability is the vocabulary domain of OTCA. Expect the distinction between monitoring and observability, the signals of traces, metrics and logs, how they relate to each other, the idea of context that links them, and why standard instrumentation matters when systems use many languages. Questions are usually conceptual and ask what a signal tells you or why correlation helps. The trap is treating the signals as interchangeable, when each answers a different kind of question and is cheapest for a different job. This is a smaller domain, so a handful of definitions covers it. Expect plain definition and scenario questions that reward a clear mental model over detail.

Pick one incident you know and decide which signal would have shown it first, which would have explained it, and which would have measured its impact. The exercise ties the three signals together.

The OpenTelemetry API and SDK: what it tests

The OpenTelemetry API and SDK is by far the largest OTCA domain. Expect the split between the API, which instrumentation code calls, and the SDK, which implements it, providers for traces, metrics and logs, spans with attributes, events and status, context propagation across services, the W3C trace context format, baggage, resources, semantic conventions, samplers, processors and exporters, and manual versus automatic instrumentation. Questions ask what a component does or what happens when something is configured. A frequent trap is mixing the API and SDK roles, since libraries should depend only on the API so that applications choose the implementation. Expect a mix of vocabulary questions and short code-shaped scenarios, so be comfortable reading a few lines of instrumentation.

Follow one request through two services and write down what is created, what is propagated and what is exported at each hop. This single trace covers most of the domain.

The OpenTelemetry Collector: what it tests

The OpenTelemetry Collector covers the component that receives, processes and exports telemetry. Expect receivers, processors, exporters and connectors, extensions, how pipelines are defined per signal, the OTLP protocol, and the agent and gateway deployment patterns. Questions give a goal such as filtering, batching or fan-out to several backends and ask where in the configuration it belongs. The common trap is the pipeline rule: a component only runs if it is listed in a service pipeline, so a perfectly defined receiver that is never referenced does nothing, and the exam describes that situation as telemetry not arriving. Read configuration snippets slowly, because a missing line in the service section is easy to miss and is often the entire point of the question.

Write a minimal Collector configuration from memory with one receiver, one processor and one exporter wired into a pipeline. The wiring step is where mistakes are made.

Maintaining and Debugging Observability Pipelines: what it tests

Maintaining and Debugging Observability Pipelines covers keeping telemetry flowing. Expect the Collector's own logs and metrics, health checks, diagnosing dropped or missing data, back pressure and queueing, scaling the Collector, sampling decisions and their effects, and verifying that attributes and context survive the pipeline. Questions describe a symptom and ask for the likeliest cause or the first thing to check. The trap is blaming the backend first; the exam usually expects you to check whether the data left the application and reached the Collector before looking further downstream. It is the smallest domain but the most scenario based. Order your reasoning by the direction of the data, starting at the source and moving toward the backend.

Make a short list of symptoms, such as missing traces, broken parent links and rising memory use, and write the first two checks for each, starting nearest the application.

What a 20-question OTCA sample can and cannot tell you

A set of 20 questions is a screening test, not a measurement. With only a few questions per domain, one lucky guess or one unlucky wording moves your result by five percentage points, and a domain with only two questions behind it says almost nothing about that domain's true strength. The set is also fixed, so after one read-through it measures your memory of these items and not your command of OTCA. Use it to choose where to start studying, not to decide whether you are ready, and then rely on the larger bank, where questions repeat only after a gap and the app tracks which domains stay weak.

A second limit is style. Written practice questions share one author voice, while a real exam draws on many writers and reads differently. Treat any practice score, here or elsewhere, as one input next to the official curriculum, hands-on experience with the technology, and the documentation of the project itself.

A one-week plan after the OTCA sample set

After the sample set, spend a week turning the result into a plan. Start with the domains where you missed questions and read the matching part of the official curriculum before you try more questions, because practice is far more useful once you can explain the topic. Return to practice in short daily sessions, review every missed question the next day, and leave the last day for a fresh mixed set. Keep a simple note of which concepts caused misses; the same three or four ideas usually explain most of them, and naming them is what turns practice into progress.

The largest OTCA domain is The OpenTelemetry API and SDK, at 46% of the published weights. If two domains tie for weakest in your tally, start with the heavier one, and keep the other 3 domains ticking over with short reviews.

Adjust the pace to your calendar. If you have more time, spread the same steps over two or three weeks and add a second mixed session at the end of each week. If you have less, keep days 1 to 3 and day 6 and accept a rougher picture. What matters is that every study session starts from a specific weak domain and ends with a check, not that the plan is followed to the letter.

Practice the full OTCA bank

These 20 questions are a small slice of the GoldenKube OTCA bank, which holds 42 questions. In practice mode the app serves the questions you are due to review first, then the domain where you are weakest, and it brings missed questions back after a gap until you answer them correctly. You can answer 10 questions as a guest without an account; after that a free account keeps your progress, and no credit card is asked for at any point. Each answer comes with the same kind of written explanation you saw on this page, so a wrong answer is always followed by the reasoning that fixes it.

Practice mode shows one question at a time and gives the verdict and explanation as soon as you answer. A focus option lets you stay inside a single domain until it feels solid, which is the natural next step after finding your weakest domain on this page. There is no timer and no exam simulation in practice mode; the goal is learning, not performance under pressure.

Frequently asked questions