An instrumentation upgrade changes an attribute name used by dashboards. During the rollout, old and new instrumentation versions coexist. Their telemetry identifies different schema versions.
Which TWO statements are correct when planning compatibility?
Replacing the newer schema URL with the older URL also converts the attribute names.
A schema URL identifies a telemetry schema version; it does not itself transform records.
Giving both instrumentation versions the same scope name normalizes their emitted attributes.
Consumers can use schema-version information to apply supported transformations between versions.
B
A schema URL identifies a schema version, and consumers can use that information to apply supported transformations between versions, but merely changing the URL does not transform the data. Scope names identify instrumentation and do not normalize changed attributes.
Maintaining and Debugging Observability Pipelines
25
Select Two
D
An application is configured to export OTLP using http/protobuf to port 4317. The Collector explicitly exposes OTLP/gRPC on 4317 and OTLP/HTTP on 4318.
Network connectivity and TLS validation succeed, but telemetry export fails with protocol-related errors. The team wants to keep OTLP/HTTP.
Which change should it make?
Use the Collector's HTTP listener on 4318 with the OTLP trace request path.
Keep port 4317 and change the HTTP payload encoding from Protobuf to JSON.
Keep port 4317 and increase the exporter timeout for the HTTP request.
Use port 4318 and change the application's exporter protocol to gRPC.
A
The stated HTTP listener is on 4318, and OTLP/HTTP traces use the trace request path. JSON remains an HTTP encoding and does not make an HTTP request compatible with a gRPC listener. Timeouts do not resolve protocol mismatches, and switching the application to gRPC on port 4318 reverses the mismatch.
Maintaining and Debugging Observability Pipelines
24
Select One
A Collector starts successfully and its health-check endpoint responds. However, a synthetic test trace does not appear in the backend.
The engineer first wants to inspect the actual span payload that reaches the end of the Collector's configured processing chain. What is the most direct diagnostic step?
Increase the SDK's sampling probability and compare the backend's total trace count.
Query the health-check endpoint while repeatedly sending the synthetic trace.
Inspect the Collector's receiver counters for an increase in accepted spans.
Add a detailed debug exporter to the same traces pipeline and inspect its output.
D
A detailed debug exporter in that pipeline exposes the records reaching its exporter stage. Health checks establish availability, and receiver counters establish receipt volume; neither displays the post-processing payload. Increasing sampling changes data volume without locating this pipeline issue.
Maintaining and Debugging Observability Pipelines
23
Select One
Every span emitted by an application contains an account.email span attribute. The organization needs the spans for performance analysis, but that attribute must be removed before the Collector sends them to an external backend.
The field does not appear elsewhere in the telemetry. Which configuration best preserves the required data?
Filter out spans that contain account.email before the remote exporter.
Delete account.email from resource attributes in the traces pipeline.
Delete account.email from span attributes in the traces pipeline.
Rename the span attribute to account.identifier before the remote exporter.
C
Deleting the span attribute retains the performance data while removing the specified field. Filtering would discard every affected span, resource-attribute deletion targets a different location, and renaming preserves the email value.
The OpenTelemetry Collector
22
Select One
A Collector exporter already has an in-memory sending queue and retries enabled. Its queue and retry limits can accommodate the expected backend outage.
The remaining requirement is to preserve queued telemetry across a Collector process restart. A persistent volume is available.
Which TWO configuration changes are needed?
Add the file exporter to the same pipeline so exported batches also appear on disk.
Configure and enable a file_storage extension using the persistent volume.
Increase the batch processor's timeout to keep more data pending before export.
Reference the storage extension in the exporter's sending-queue configuration.
B
The enabled storage extension supplies persistent storage, and the sending queue must reference it. A separate file exporter does not make the remote exporter replay that file after restart, and batch timing does not persist the queue. Persistence still depends on storage availability and configured limits.
The OpenTelemetry Collector
21
Select Two
D
A Collector tier performs tail sampling based on whether any span in a trace has an error status. After scaling from one replica to four, retained traces frequently lack spans.
A request-level load balancer distributes incoming OTLP requests across the replicas. All replicas use identical policies, and their processing capacity is sufficient.
What should the team change?
Increase exporter batch sizes so more spans travel in each outgoing request.
Route spans by trace ID so each trace reaches the same sampling replica.
Route spans by service name so each service reaches the same sampling replica.
Increase the replica count so each sampler evaluates fewer incoming spans.
B
Tail sampling maintains state for each trace. Routing by trace ID brings that trace's spans to the same sampler. Service-based routing can split a distributed trace across samplers, and larger export batches or additional replicas do not establish trace affinity.
The OpenTelemetry Collector
20
Select One
A Kubernetes platform must collect host-local logs from every node and forward application telemetry to an external backend. Hundreds of application Pods run across a smaller number of nodes.
The team wants to avoid a log-collection sidecar in every Pod and maintain backend credentials in a central collection tier.
Which TWO deployment choices best fit?
Run a Collector DaemonSet with access to the required node-local log paths.
Run a Collector sidecar in every application Pod with access to the node's logs.
Forward node Collector output to gateway Collectors that export to the backend.
Configure each application SDK with the external backend's export credentials.
A
Node-local Collectors can read the required local files and forward telemetry to a gateway tier, and gateways can hold the backend credentials. Per-Pod sidecars add the duplication the scenario seeks to avoid, and putting backend credentials in each application defeats centralization.
The OpenTelemetry Collector
19
Select Two
C
A Collector distribution includes a connector that consumes spans and produces metrics. The team wants to send the resulting metrics through a metrics pipeline while continuing to export the original spans.
How should the connector be connected?
Add it as a receiver in both pipelines and retain the existing traces exporter.
Add it as a processor in the traces pipeline and an exporter in the metrics pipeline.
Add it as an extension and reference that extension from both pipeline definitions.
Add it as a traces exporter and a metrics receiver, retaining the traces exporter.
D
A connector acts as an exporter at the end of one pipeline and a receiver at the start of another. Here it consumes traces and supplies metrics. Keeping the existing traces exporter preserves span export. The other placements assign the connector incorrect roles.
The OpenTelemetry Collector
18
Select One
A Collector already exports traces through its traces pipeline. An engineer defines an attributes processor named attributes/remove_customer to delete a customer identifier.
The Collector starts successfully, but exported spans still contain the identifier. The processor's identifier is absent from service.pipelines.traces.processors.
Which configuration change is needed?
Add attributes/remove_customer to the traces pipeline's processor list.
Add attributes/remove_customer to the list under service.extensions.
Move the processor definition beneath the OTLP receiver configuration.
Reference the processor from the remote exporter's endpoint configuration.
A
Defining a processor configures its instance. Referencing it in the pipeline enables it for that data flow. The service.extensions list enables extensions, while receiver and exporter endpoint settings do not attach processors to a pipeline.
The OpenTelemetry Collector
17
Select One
An SDK uses OTLP/HTTP and supports standard OpenTelemetry environment-variable configuration. No signal-specific endpoint variables or programmatic endpoint overrides are set.
Its configuration includes:
OTEL_EXPORTER_OTLP_ENDPOINT=https://telemetry.example.com/otel/
The proxy accepts standard OTLP signal paths beneath /otel/.
To which URL should the SDK send traces?
https://telemetry.example.com/v1/traces
https://telemetry.example.com/otel/
https://telemetry.example.com/otel/v1/traces
https://telemetry.example.com/otel/traces
C
For OTLP/HTTP, the general endpoint variable supplies a base URL. The exporter constructs the trace URL by appending v1/traces, preserving /otel/. The first option removes the configured prefix, the second omits the signal path, and the last uses the wrong path.
The OpenTelemetry API and SDK
16
Select One
An application exports structured logs and traces. Both signals contain the same service resource attributes, but engineers cannot reliably navigate from a request log to the span active when the log was emitted.
The logging integration can access the active OpenTelemetry context. What should it populate?
The log record's TraceId and SpanId fields from that context.
A resource attribute containing the name of the active span.
The log record's instrumentation scope with the active span's name.
A new trace ID derived from the log record's timestamp.
A
The log data model provides TraceId and SpanId for correlation with request processing and particular spans. Service resources and scope names do not identify an individual request, and generating another trace ID breaks the connection to the existing trace.
The OpenTelemetry API and SDK
15
Select One
An application's SDK drops approximately 90% of traces through head sampling. A Collector then applies tail sampling to retain traces containing errors.
An incident reveals that many failed requests have no trace in the backend. The team needs failures occurring late in a request to be considered by the tail sampler.
Which change addresses the sampling limitation?
Increase the tail sampler's decision wait while keeping SDK sampling unchanged.
Mark spans as errors immediately before the SDK exports each completed batch.
Add a second error-retention policy to the Collector's existing tail sampler.
Configure the SDK to record and export all candidate traces to the tail sampler.
D
Tail sampling can evaluate only telemetry that reaches it, and it cannot recover spans discarded by upstream head sampling. Longer waits or additional Collector policies do not restore those spans. The SDK must export the candidate traces if later outcomes should influence retention.
The OpenTelemetry API and SDK
14
Select One
A short-lived command-line application uses a batching span processor. It ends its spans successfully, but some runs exit before any spans reach the Collector. Export succeeds when the application remains running.
Which change most directly addresses this behavior?
Increase the processor queue capacity to hold more completed spans.
Shut down the SDK gracefully and wait for completion before exiting.
Reduce the Collector's batch timeout to export received spans sooner.
Increase the exporter's retry duration for transient network failures.
B
Graceful shutdown gives processors an opportunity to flush completed spans and release resources. The application must allow that operation to finish within its timeout. Larger queues and longer retries do not keep a terminated process running, and Collector timing cannot affect spans it never receives.
The OpenTelemetry API and SDK
13
Select One
A gateway places customer.tier=gold in baggage. Downstream services receive that baggage through configured propagators.
The team wants to use the value for trace analysis and is considering using it to authorize premium operations. Which TWO statements should guide the implementation?
The value becomes a resource attribute when the downstream service extracts baggage.
Instrumentation must explicitly copy the value into span attributes if it should appear there.
The value is trustworthy when it arrives alongside a valid W3C trace context.
The value needs independent validation before it influences an authorization decision.
B
Baggage is separate from span and resource attributes, so instrumentation must copy values explicitly when they should appear as telemetry attributes. Baggage has no built-in integrity guarantee, so a value needs independent validation before it influences authorization, and a valid trace context does not make it trustworthy.
The OpenTelemetry API and SDK
12
Select Two
D
A third-party library records a request Counter with route, status, and request_id attributes. Unique request IDs create excessive metric-stream cardinality.
The application owner can configure the SDK but cannot modify the library. The owner needs counts by route and status, with reduced aggregation cardinality inside the application.
Which change best meets the requirement?
Increase the export interval so more request IDs are combined into each export.
Remove request_id with a Collector processor after the SDK exports the metric.
Configure a matching SDK View that retains only route and status attributes.
Switch the Counter's export temporality while retaining its existing attributes.
C
A View can select the attributes retained in a metric stream, reducing its aggregation cardinality inside the SDK. Collector-side removal occurs after that application-side cost has already been incurred. Export intervals and temporality do not remove unique attribute combinations.
The OpenTelemetry API and SDK
11
Select One
A service has 20 replicas with uneven request volumes. Engineers need to estimate the 95th-percentile request duration across the whole service for each reporting interval.
Which collection strategy preserves the information needed for this calculation?
Record durations in histograms with compatible bucket boundaries across replicas.
Export each replica's 95th-percentile duration and average those values in the backend.
Export each replica's mean duration and weight the means by request count.
Record each replica's latest completed duration in a gauge and combine the values.
A
Compatible histograms can combine observations across replicas and support percentile estimation. Averaging replica percentiles does not yield the service-wide percentile, weighted means still produce a mean, and latest-value gauges discard nearly all of the duration distribution.
The OpenTelemetry API and SDK
10
Select One
A connection pool exposes callbacks whenever a connection becomes active or returns to the pool. The application does not expose a function that reads the current active count.
The team wants an additive metric of active connections, updated directly from those callbacks. Which instrumentation fits?
Use a Counter, adding one when a connection becomes active and zero when it returns.
Use a Histogram, recording one when a connection becomes active and minus one when it returns.
Use an ObservableGauge, reporting the change observed during the latest callback.
Use an UpDownCounter, adding one on activation and minus one on return.
D
An UpDownCounter accepts positive and negative changes to an additive quantity. A Counter cannot represent decrements, and a Histogram describes a distribution of measurements. Reporting the most recent change through an ObservableGauge would not report the current active connection count.
The OpenTelemetry API and SDK
9
Select One
A worker combines messages from several independent traces into one batch operation. The team wants one span representing the batch, with a structured causal relationship to every contributing message.
How should the batch span represent these relationships?
Use the first message as its parent and store the remaining trace IDs as text attributes.
Create the batch span with links to the contributing messages' span contexts.
Assign every contributing message's span context as a parent of the batch span.
Reuse the first message's span ID and add an event for each remaining message.
B
Links represent relationships to multiple span contexts, including contexts from different traces. A span has at most one parent. Text attributes lack the structured relationship provided by links, while reusing another operation's span ID does not create a distinct batch operation.
The OpenTelemetry API and SDK
8
Select One
Two services communicate through a custom HTTP client and server framework that have no automatic instrumentation. Each service has a working tracing SDK and exporter.
The team wants the receiving service's server span to continue the caller's trace. Which TWO actions are required at the HTTP boundary?
Inject the caller's current trace context into outgoing request headers.
Copy the caller's span attributes into the receiving service's resource.
Configure both services to obtain span IDs from the same ID generator.
Extract the incoming context and use it when creating the server span.
A
The caller injects context into the transport carrier, and the receiver extracts it and uses it as the parent context. Copying span attributes into a resource and sharing an ID generator do not establish the remote parent-child relationship.
The OpenTelemetry API and SDK
7
Select Two
D
A service named checkout emits telemetry from two instrumentation libraries. Engineers need to distinguish the service producing the telemetry from the library and version that generated each record.
Which mapping follows the OpenTelemetry data model?
Store the service name in the instrumentation scope and library versions in resource attributes.
Store both identities in resource attributes, creating a separate resource for each operation.
Store the service identity in the resource and library identity in the instrumentation scope.
Store the service identity in span names and library identity in the propagated trace context.
C
The resource identifies the entity producing telemetry, including service identity. Instrumentation scope identifies the instrumentation responsible for a record, commonly through its name and version. Span names identify operations, and propagated trace context does not replace either identity.
The OpenTelemetry API and SDK
6
Select One
A team maintains a database client library used by applications with different telemetry exporters and sampling policies. The library should emit spans while allowing each application to control telemetry processing.
How should the library integrate with OpenTelemetry?
Create a private SDK and accept exporter settings through its connection configuration.
Depend on the tracing API and leave SDK configuration to the application.
Export OTLP directly and let each application choose the receiving Collector.
Register a global SDK when the library establishes its first database connection.
B
The API provides the instrumentation interfaces. The application owner installs and configures the SDK, including processing and export. A private SDK, direct OTLP implementation, or library-installed global SDK takes control away from the consuming application.
The OpenTelemetry API and SDK
5
Select One
Applications export OTLP to a shared Collector. A company is replacing its observability backend, and the new backend supports the signals already collected.
The team wants a transition period in which both backends receive the same processed telemetry. Which approach requires the fewest application changes?
Install a second SDK in each application and configure it for the new backend.
Add the new backend's exporter to every application's existing SDK configuration.
Replace the application exporters with a custom exporter that writes to both backends.
Add a second exporter to the existing Collector pipelines during the transition.
D
A Collector can export processed telemetry to multiple destinations. Adding an exporter at that shared point supports the transition without changing each application. The other approaches distribute migration work across applications, and installing a second SDK introduces yet another component.
Fundamentals of Observability
4
Select One
A Java application uses the OpenTelemetry Java agent. Its traces contain incoming HTTP requests and database calls, but a slow, application-specific pricing calculation is not represented separately.
The team can make a small code change. What provides the missing detail with the least duplication of existing instrumentation?
Add an API-created span around the calculation using the agent-provided OpenTelemetry instance.
Register a second SDK and instrument the HTTP, pricing, and database operations through it.
Reduce the agent's export interval so that intermediate work appears as separate spans.
Add a Collector processor that divides the HTTP span using its recorded start and end times.
A
Automatic instrumentation covers supported frameworks and libraries. Manual instrumentation can add application-specific operations to that existing telemetry. A second SDK introduces unnecessary configuration and potential duplication. Export intervals and Collector processing cannot recover unrecorded internal operation boundaries.
Fundamentals of Observability
3
Select One
Java and Python services emit HTTP telemetry through the same Collector. Their dashboards require separate queries because equivalent information uses different attribute names and units.
The team wants new services to work with shared dashboards with minimal service-specific configuration. Which approach best addresses the underlying issue?
Configure both SDKs to use the same OTLP transport and serialization format.
Give both services the same instrumentation scope name and scope version.
Align their instrumentation with the same applicable HTTP semantic conventions.
Attach a common resource attribute identifying the shared dashboard.
C
Semantic conventions standardize the meaning and representation of commonly observed operations. Matching transport settings only standardizes delivery. Scope names identify instrumentation, while a shared dashboard resource attribute does not reconcile incompatible names or units.
Fundamentals of Observability
2
Select One
An online retailer needs to alert on changes in checkout failure rates and investigate which downstream operations contribute to individual slow checkouts. Request volume is high, and the team cannot retain detailed telemetry for every request.
Which TWO collection approaches best support these objectives?
Record a periodically sampled gauge containing the result of the most recent checkout.
Record request and failure counts as metrics with bounded attribute values.
Calculate total request and failure counts from traces retained by an error-biased sampler.
Retain distributed traces for selected checkouts, including spans for downstream operations.
B
Request and failure counts support rate calculations without retaining individual request records, and distributed traces for selected checkouts expose the downstream operations contributing to individual slow requests. A latest-result gauge does not count outcomes, and error-biased samples cannot directly provide population totals.
Fundamentals of Observability
1
Select Two
D
.png)
.webp)
.svg)
