OTCA: OpenTelemetry Certified Associate Practice Exam

What the OTCA exam covers

• OpenTelemetry Fundamentals133 questions
• Instrumentation and SDKs133 questions
• Metrics133 questions
• Traces133 questions
• Logs and Exporters133 questions

Free OTCA practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 665.

1. Question 1OpenTelemetry Fundamentals

   A team wants telemetry that is not tied to one observability vendor. What does OpenTelemetry provide toward that?

   • AA vendor-neutral API, SDK and protocol for all three signalsCorrect
   • BA storage backend for traces and metrics
   • CA hosted dashboard for querying telemetry
   • DAn alerting engine for production incidents
   ✓ Correct answer: A

   The project defines how telemetry is created and how it travels - an API applications code against, SDKs that implement it, and OTLP as the protocol - so the backend becomes a choice made at configuration time rather than a dependency baked into the application. Storing, querying and alerting are left to whatever backend you point it at.

   Why the other options are wrong

   • BA storage backend is what OpenTelemetry deliberately leaves to others.
   • CA hosted dashboard for querying is the backend's role, not the project's.
   • DAn alerting engine sits in the backend rather than in OpenTelemetry.
2. Question 2Metrics

   A gauge reports the same stale value for hours after the process it describes stopped updating. What is the likely cause?

   • AThe observable callback is returning a cached valueCorrect
   • BThe exporter is using delta temporality
   • CThe view has dropped an attribute key
   • DThe reader interval is shorter than the export interval
   ✓ Correct answer: A

   The SDK invokes the registered callback at each collection, so if that callback reads a variable nothing is updating any more, a stale value is exported indefinitely and looks like a healthy flat line. Checking what the callback actually reads is the first step.

   Why the other options are wrong

   • BDelta temporality changes reporting rather than the value's freshness.
   • CDropping an attribute key merges series instead of freezing values.
   • DThe reader interval governs how often collection happens.
3. Question 3Instrumentation and SDKs

   A service instruments an outbound HTTP call but the downstream service starts a new trace. What is missing?

   • AInjection of the context into the outbound request headersCorrect
   • BAn exporter configured on the calling service
   • CA matching service name on both sides
   • DA span kind of client on the outbound span
   ✓ Correct answer: A

   The span records the call locally, but the trace only continues if the propagator writes the context into the outgoing headers - which manual HTTP code often forgets while instrumentation libraries do it automatically. The symptom is two valid traces where one was expected.

   Why the other options are wrong

   • BAn exporter is clearly working since the calling span appears.
   • CService names do not need to match for a trace to continue.
   • DSpan kind describes the role and does not carry context.
4. Question 4Logs and Exporters

   A collector is deployed as a sidecar to a single application. What does that arrangement give up?

   • AThe ability to see and act on traffic from other servicesCorrect
   • BThe ability to enrich records with pod metadata
   • CThe ability to batch records before export
   • DThe ability to export to more than one backend
   ✓ Correct answer: A

   Policies that need a whole trace, such as tail sampling, or a fleet-wide view cannot be applied by a collector that only sees one application's telemetry, which is why sidecars usually forward to a shared gateway. Local enrichment, batching and fan-out all still work.

   Why the other options are wrong

   • BPod metadata is exactly what a sidecar is well placed to add.
   • CBatching works the same in a sidecar as anywhere else.
   • DA sidecar can fan out to several backends without difficulty.
5. Question 5Metrics

   A platform group must bound the number of series a single instrument can create. What mechanism applies?

   • AA cardinality limit that collapses excess into an overflow seriesCorrect
   • BA rate limit on how often the instrument may be recorded
   • CA queue size limit on the metric reader
   • DA timeout applied to each metric export
   ✓ Correct answer: A

   Once the configured number of distinct attribute sets is reached, further ones are aggregated into a single series marked as overflow, so memory stays bounded and the presence of the overflow series signals that something is producing more dimensions than expected.

   Why the other options are wrong

   • BA recording rate limit would lose measurements rather than bound series.
   • CA reader queue limit governs export rather than series count.
   • DAn export timeout bounds one send attempt only.
6. Question 6Instrumentation and SDKs

   A team must confirm an agent attached successfully to a Java process. What is the clearest evidence?

   • AThe agent's startup lines in the process outputCorrect
   • BThe presence of the agent jar on the filesystem
   • CThe service appearing in the backend's service list
   • DThe collector reporting a new open connection
   ✓ Correct answer: A

   It logs its version and configuration as the process starts, which proves it was loaded rather than merely present, and its later diagnostic output explains export problems. A jar on disk that was never referenced by the command line produces nothing at all.

   Why the other options are wrong

   • BA jar on disk may never have been loaded by the process.
   • CA backend entry may be stale from an earlier deployment.
   • DA connection may come from a different process on the host.
7. Question 7Logs and Exporters

   An engineer is weighing how to handle a backend that requires a different attribute name than the conventions use. What is the tidy approach?

   • ARename it in the exporting pipeline, keeping the source unchangedCorrect
   • BChange the instrumentation to use the backend's name
   • CRecord both names on every record at the source
   • DAsk every team to write queries using both names
   ✓ Correct answer: A

   Keeping conventional names in the services means the telemetry stays portable and comparable, and a rename applied in the pipeline that feeds that particular backend satisfies it without spreading a vendor's naming through every codebase. Removing the backend later removes the rename.

   Why the other options are wrong

   • BChanging instrumentation spreads a vendor's naming everywhere.
   • CRecording both names doubles the attribute cost on every record.
   • DAsking teams to use both names pushes the problem onto queries.
8. Question 8MetricsSelect all that apply

   A team must decide what to do when a metric pipeline must survive a backend outage. Which TWO help? (Choose TWO)

   • AA collector queue that retains data during the outageCorrect
   • BCumulative temporality so a missed export loses nothingCorrect
   • CA shorter export interval so less is in flight
   • DMore attributes so the data is easier to recover
   • EA second instrument recording the same values
   ✓ Correct answer: A, B

   A queue holds exports until the destination returns, and because a cumulative value carries the total since process start, a dropped export is superseded by the next one rather than lost. Under delta, a missing export is a permanently missing interval.

   Why the other options are wrong

   • CA shorter interval sends more often into a failing destination.
   • DMore attributes increase volume without aiding recovery.
   • EA duplicate instrument doubles cost without improving durability.
9. Question 9Instrumentation and SDKs

   An engineer is weighing what to do when a service must be instrumented before its dependencies are. What is the outcome?

   • AUseful traces for its own work, deepening as dependencies followCorrect
   • BNo usable traces until every dependency is instrumented
   • CTraces that the backend rejects as incomplete
   • DTraces that duplicate the uninstrumented services
   ✓ Correct answer: A

   Spans for its own handling and its outbound calls already show where its time goes and which dependencies are slow from its point of view, which is often enough to act on. Each dependency instrumented afterwards adds detail inside the gaps.

   Why the other options are wrong

   • BTraces are useful long before every dependency is covered.
   • CBackends accept traces regardless of missing hops.
   • DUninstrumented services produce no spans to duplicate.
10. Question 10Logs and ExportersSelect all that apply

    A service owner is deciding what to monitor to know the telemetry pipeline is healthy. Which TWO signals are most direct? (Choose TWO)

    • ARefused record counts at the collector's receiversCorrect
    • BFailed send counts at the collector's exportersCorrect
    • CThe number of services currently instrumented
    • DThe size of the collector's configuration file
    • EThe number of alerts defined in the backend
    ✓ Correct answer: A, B

    Refusals rising means the collector is under pressure and senders are being told to retry, while failed sends mean the destination is unhealthy or a credential has expired. Together they distinguish an ingress problem from an egress one immediately.

    Why the other options are wrong

    • CInstrumented service count is inventory rather than health.
    • DConfiguration file size says nothing about pipeline health.
    • EThe number of defined alerts is a backend concern.

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

• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• Prometheus Certified Associate (PCA) practice examRelated
• CBA practice examRelated
• Certified Argo Project Associate (CAPA) practice examRelated

OTCA practice exam FAQ