|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.instrument-app-opentelemetry.knowledge-check |
| 3 | +title: Module assessment |
| 4 | +metadata: |
| 5 | + title: Module Assessment |
| 6 | + description: Module assessment |
| 7 | + ms.date: 02/19/2026 |
| 8 | + author: jeffkoms |
| 9 | + ms.author: jeffko |
| 10 | + ms.topic: unit |
| 11 | +durationInMinutes: 5 |
| 12 | +content: "Choose the best response for each of the following questions." |
| 13 | +quiz: |
| 14 | + questions: |
| 15 | + - content: "What standard does OpenTelemetry use to propagate trace context across service boundaries?" |
| 16 | + choices: |
| 17 | + - content: "OpenTracing B3 headers" |
| 18 | + isCorrect: false |
| 19 | + explanation: "B3 is a multiple-header propagation format from the Zipkin project, not the default standard used by OpenTelemetry." |
| 20 | + - content: "W3C TraceContext using `traceparent` headers" |
| 21 | + isCorrect: true |
| 22 | + explanation: "OpenTelemetry uses the W3C TraceContext standard to propagate context through HTTP headers. The `traceparent` header carries the trace ID, parent span ID, and trace flags so receiving services can join the same distributed trace." |
| 23 | + - content: "OpenCensus binary propagation" |
| 24 | + isCorrect: false |
| 25 | + explanation: "OpenCensus used a binary encoding format for propagating trace context, not an HTTP header standard. OpenTelemetry was formed from the merger of OpenCensus and OpenTracing, and it adopted the W3C TraceContext standard specifically to provide a vendor-neutral, interoperable HTTP header format." |
| 26 | + - content: "When you configure the Azure Monitor connection string in a production environment, which approach is recommended?" |
| 27 | + choices: |
| 28 | + - content: "Embed it directly in source code using the code-based configuration option." |
| 29 | + isCorrect: false |
| 30 | + explanation: "Embedding credentials in source code is the least secure approach. Source code can be committed to version control or exposed in compiled binaries, making it unsuitable for production secrets." |
| 31 | + - content: "Store it in a `config.py` settings file that is deployed alongside the application code." |
| 32 | + isCorrect: false |
| 33 | + explanation: "A Python settings file can be committed to version control and is deployed alongside application code, which risks exposing the connection string. Environment variables keep sensitive configuration out of source code and configuration files." |
| 34 | + - content: "Set the `APPLICATIONINSIGHTS_CONNECTION_STRING` environment variable." |
| 35 | + isCorrect: true |
| 36 | + explanation: "The environment variable approach keeps credentials out of source code and configuration files, makes it easy to change per environment without code changes, and aligns with the principle of storing configuration separately from application code." |
| 37 | + - content: "When using `tracer.start_as_current_span()` in Python and an unhandled exception propagates out of the `with` block, what does the OpenTelemetry SDK do automatically?" |
| 38 | + choices: |
| 39 | + - content: "Records the exception on the span and sets the span status to error." |
| 40 | + isCorrect: true |
| 41 | + explanation: "The Python SDK automatically catches exceptions that propagate out of a `start_as_current_span` context manager, records the exception details, and sets the span status to `StatusCode.ERROR`. This provides automatic error capture without requiring explicit exception handling code." |
| 42 | + - content: "Suppresses the exception and marks the span as successful to avoid false alerts." |
| 43 | + isCorrect: false |
| 44 | + explanation: "The SDK doesn't suppress exceptions. Unhandled exceptions continue to propagate after being recorded on the span. Suppressing errors would hide failures from the calling code and make debugging harder." |
| 45 | + - content: "Leaves the span status as unset and doesn't record any exception details." |
| 46 | + isCorrect: false |
| 47 | + explanation: "Leaving the span status unset would make a failed operation appear successful in Application Insights. The SDK specifically records the exception and sets the error status to ensure failures are visible in trace data without requiring manual error handling in every span." |
| 48 | + - content: "A Python AI application creates a span using `tracer.start_as_current_span(\"CallLlmApi\", kind=SpanKind.CLIENT)`. In which Application Insights table does this span appear?" |
| 49 | + choices: |
| 50 | + - content: "`requests`" |
| 51 | + isCorrect: false |
| 52 | + explanation: "The `requests` table contains server spans (`SpanKind.SERVER`) and consumer spans (`SpanKind.CONSUMER`). Client spans don't appear in the `requests` table." |
| 53 | + - content: "`traces`" |
| 54 | + isCorrect: false |
| 55 | + explanation: "The `traces` table contains log records emitted through Python's `logging` module or the OpenTelemetry logging API, not span data from custom tracers." |
| 56 | + - content: "`dependencies`" |
| 57 | + isCorrect: true |
| 58 | + explanation: "Application Insights maps client spans (`SpanKind.CLIENT`), along with internal and producer spans, to the `dependencies` table. These represent outgoing calls from the service to external resources or APIs, such as calls to an LLM endpoint or embedding service." |
| 59 | + - content: "Which field in Application Insights telemetry tables corresponds to the OpenTelemetry trace ID and enables correlation of all telemetry items in a distributed trace?" |
| 60 | + choices: |
| 61 | + - content: "`cloud_RoleName`" |
| 62 | + isCorrect: false |
| 63 | + explanation: "`cloud_RoleName` identifies the service that generated the telemetry, corresponding to the `service.name` resource attribute. It groups telemetry by service, not by trace." |
| 64 | + - content: "`operation_Id`" |
| 65 | + isCorrect: true |
| 66 | + explanation: "The `operation_Id` field corresponds to the OpenTelemetry trace ID. It appears in the `requests`, `dependencies`, `traces`, and `exceptions` tables and links all telemetry items belonging to the same distributed trace together." |
| 67 | + - content: "`id`" |
| 68 | + isCorrect: false |
| 69 | + explanation: "The `id` field corresponds to the span ID, which uniquely identifies a single span. It doesn't link all spans in a trace together the way `operation_Id` does." |
0 commit comments