AI-200: Secure, Monitor, and Troubleshoot Azure Solutions

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team operates a containerized Python RAG API in Azure Container Apps. The API calls an Azure Functions enrichment step, publishes work to Azure Service Bus, and reads embeddings from Azure Cosmos DB for NoSQL. Some requests exceed the latency target, and engineers must reconstruct the path of a single request across all components to find the slow hop. Which observability evidence is the best design fit?

Options:

• A. Platform metrics for CPU, requests, and queue depth

• B. OpenTelemetry distributed traces with propagated context and per-hop spans

• C. Structured application logs filtered by request timestamp

• D. Averages from a KQL latency dashboard by service

Best answer: B

Explanation: Distributed tracing is the right evidence when the question is about one request’s path across multiple services. With OpenTelemetry, each component emits spans that share a trace context, so engineers can see the parent-child sequence through the container app, function, Service Bus operation, and Cosmos DB call. Logs are event records and can add details, while metrics summarize numeric behavior such as throughput, CPU, or queue depth. Those are useful for correlation, but they do not inherently reconstruct the end-to-end request path. For this scenario, the key is per-hop timing under a shared trace ID.

• Timestamped logs can show nearby events, but they do not inherently model the parent-child request path across services.
• Platform metrics reveal aggregate health and load, not the slow hop in one distributed request.
• Average latency dashboards help identify trends, but averages do not reconstruct a single request journey unless based on trace spans.

Question 2

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team is deploying a containerized Python RAG API to Azure Container Apps. The API reads embeddings from Azure Cosmos DB for NoSQL and sends work messages to Azure Service Bus. Requirements: credentials must not be in source code, container images, logs, or browser-visible settings; nonsecret feature flags must remain centrally configurable across revisions. Which design best fits these requirements?

Options:

• A. Use managed identity, Key Vault, and App Configuration.

• B. Write resolved secrets to startup logs for auditing.

• C. Store all settings in client-visible app configuration.

• D. Bake connection strings into the container image.

Best answer: A

Explanation: The secure configuration boundary is the server-side workload identity. In Azure Container Apps, assign a managed identity to the container app and use it to retrieve secrets from Azure Key Vault at runtime. Store nonsecret values, such as feature flags or endpoint names, in Azure App Configuration. This avoids placing credentials in source code, images, logs, or client-visible settings while still supporting centralized configuration across deployments and revisions.

The key distinction is that secrets belong in Key Vault behind identity-based access, while nonsecret operational settings can be centrally managed in App Configuration.

• Image-baked secrets fail because container images can be copied, scanned, cached, or reused outside the intended runtime boundary.
• Client-visible settings fail because browser or mobile clients cannot be trusted to protect service credentials.
• Logging secrets fails because logs expand credential exposure to monitoring stores and support workflows.

Question 3

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A Python API running in Azure Container Apps loads a PostgreSQL password from Azure Key Vault during startup. The deployed App Configuration values show the expected vault URI and secret name, and the secret exists and is enabled in that vault. The revision fails readiness with these logs:

ManagedIdentityCredential: token acquired for https://vault.azure.net
KeyVault URI: https://kv-rag-prod.vault.azure.net/
Secret name: pg-password
GET /secrets/pg-password -> 403 Forbidden
Error: caller is not authorized to read secrets

Which root cause best follows from the evidence?

Options:

• A. The managed identity lacks permission to read Key Vault secrets.

• B. The Key Vault endpoint is configured incorrectly.

• C. The Container Apps revision has no managed identity assigned.

• D. The secret name is configured incorrectly.

Best answer: A

Explanation: The evidence separates authentication, configuration, and authorization. The app successfully obtains a token for Key Vault by using ManagedIdentityCredential, so the managed identity is present and usable. The vault URI and secret name match the expected configuration, and the secret exists and is enabled, so this is not primarily an endpoint or secret-setting problem. A 403 Forbidden response from Key Vault when reading an existing secret indicates the caller is authenticated but not authorized for that data-plane operation. The likely fix is to grant the Container Apps managed identity an appropriate Key Vault secret-read permission, such as a role or access policy that allows get on secrets.

• Wrong endpoint is less supported because the logs show the expected vault URI and Key Vault returns an authorization failure.
• Wrong secret name would more likely produce a not-found result, and the stem states the secret exists.
• No managed identity conflicts with the log showing ManagedIdentityCredential successfully acquired a token.

Question 4

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team uses OpenTelemetry to trace a Python API that sends work to Azure Service Bus and a Container Apps worker that processes the messages. A failed request shows this trace evidence:

Trace T1: API HTTP request -> Service Bus send
Trace T2: worker process message -> Cosmos DB query
Observation: worker spans never have T1 as parent
Dead-letter count: 0

What is the best next diagnostic step?

Options:

• A. Rotate the worker’s Key Vault secrets

• B. Review dead-letter handling in the queue

• C. Increase sampling for the worker application

• D. Inspect Service Bus trace context injection and extraction

Best answer: D

Explanation: Missing parent-child relationships across an asynchronous boundary usually indicate a trace context propagation issue. The API trace includes the Service Bus send span, and the worker creates spans, but those spans start a new trace instead of continuing the original one. The next diagnostic step is to verify that W3C trace context, such as traceparent, is injected into Service Bus message application properties by the sender and extracted by the worker before starting the processing span. The absence of dead-letter growth makes message delivery failure less likely. Sampling would more likely cause missing spans, not consistently separate traces.

• Sampling change does not explain why worker spans consistently exist but start under different trace IDs.
• Dead-letter review targets failed message delivery, but the worker is processing messages and the dead-letter count is 0.
• Secret rotation addresses credential failures, not broken trace parent relationships between services.

Question 5

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team runs a containerized Python RAG API in Azure Container Apps. Nonsecret settings, including Retrieval:TopK, are stored in Azure App Configuration. Operations changed Retrieval:TopK from 3 to 8 and require the change to take effect without rebuilding or restarting containers.

Trace after the change:

startup: App Configuration loaded Retrieval:TopK=3
request: Key Vault secret resolved OK
request: App Configuration refresh not invoked
request: retrieval query built with top_k=3
request: model call succeeded

Which failure point is indicated by the trace?

Options:

• A. The embedding index must be rebuilt.

• B. The API does not refresh Azure App Configuration.

• C. The model prompt template is misconfigured.

• D. The Key Vault secret rotation failed.

Best answer: B

Explanation: This trace is testing application configuration retrieval, not the user-facing AI feature. Azure App Configuration can centralize nonsecret settings, but runtime updates are not applied just because the value changed in the store. The app must be configured to refresh relevant keys, often through a registered key or sentinel plus refresh logic in the request pipeline or background path. Here, the request still uses top_k=3, while Key Vault resolution and the model call both succeed. That places the failure before retrieval and generation: the app is using stale configuration.

• Index rebuild fails because Retrieval:TopK controls runtime query behavior, not stored embedding content.
• Secret rotation fails because the trace shows Key Vault resolution succeeded.
• Prompt template fails because the stale value is visible before the model call.

Question 6

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A containerized AI inference API runs on Azure Container Apps. Each deployment creates a new revision, and traffic is shifted gradually only if the new revision can serve requests. The app exposes /healthz, which verifies model load and required service connections. Which monitoring signal best confirms the new revision is healthy?

Options:

• A. Azure Container Registry image build completion

• B. Successful readiness probe results for the new revision

• C. Traffic weight assigned to the latest revision

• D. KEDA scale-out events for the container app

Best answer: B

Explanation: For Azure Container Apps revision changes, the best health signal is runtime readiness for the specific revision being released. A successful image build or traffic setting only shows that deployment steps occurred; it does not prove the container started correctly, loaded the model, or can reach required dependencies. A readiness probe tied to /healthz is designed to answer whether the revision is ready to receive traffic. Monitoring that signal before increasing traffic helps catch broken configuration, failed model initialization, or dependency connectivity issues early.

• Build completion confirms the image was created, not that the deployed container is healthy.
• Scale-out events show autoscaling activity, not request readiness or dependency health.
• Traffic weight is a routing configuration, not evidence that the target revision can serve traffic.

Question 7

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team needs one distributed trace for a request that crosses containers, messaging, a function, and a data service. The API already uses OpenTelemetry and injects W3C trace context into the Service Bus message.

Request path:
Client -> Container Apps API -> Service Bus queue
       -> Azure Function -> Cosmos DB for NoSQL

Visible spans:
trace 9f3: API inbound
trace 9f3: Service Bus send
trace b72: Cosmos DB write (uncorrelated)

Message property:
traceparent = 00-9f3...-...

Which component should be instrumented to emit the missing spans?

Options:

• A. The Service Bus-triggered Azure Function

• B. The Azure Container Apps API

• C. The Cosmos DB account metrics

• D. The Service Bus queue entity

Best answer: A

Explanation: OpenTelemetry correlation depends on application components propagating trace context and emitting spans at each execution boundary. The API has already created the inbound and Service Bus send spans, and the message contains traceparent, so the missing link is the consumer side. The Service Bus-triggered Azure Function should extract that context, create a span for message processing, and keep that context active when calling Cosmos DB so the database dependency span is part of trace 9f3 instead of a new trace. Azure platform services can expose logs and metrics, but the application code or instrumented SDK usually creates the spans that connect the request path.

• API-only instrumentation fails because the send span is already present and cannot represent downstream function execution.
• Queue entity spans are not the right target because the queue stores and delivers messages, while producers and consumers propagate trace context.
• Cosmos DB metrics do not replace function-side context extraction or create an end-to-end application trace.

Question 8

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A containerized Python API in Azure Container Apps uses a user-assigned managed identity named uai-api to load startup settings. The flow fails before the app can connect to PostgreSQL.

Trace:

1. App Configuration: get FeatureFlagA -> 200 OK
2. App Configuration: get PgPassword -> 200 OK
   content-type: keyvaultref
3. Key Vault: get secret pg-password
   identity: uai-api
   result: 403 Forbidden

Access summary:

App Configuration: uai-api = App Configuration Data Reader
Key Vault: func-mi = Key Vault Secrets User
Key Vault: uai-api = no role assignment

Which missing link is causing the failure?

Options:

• A. Assign Key Vault access to the App Configuration resource.

• B. Grant uai-api App Configuration Data Owner access.

• C. Grant uai-api permission to read Key Vault secrets.

• D. Store PgPassword as a plain App Configuration value.

Best answer: C

Explanation: The trace shows that App Configuration access is already working: both configuration reads return 200 OK. The failure occurs when the application follows the Key Vault reference and tries to retrieve pg-password using the runtime identity uai-api. Key Vault enforces its own authorization boundary, so the identity that resolves the secret must have an appropriate secrets role, such as Key Vault Secrets User, at the vault or secret scope. App Configuration can hold the reference, but it does not bypass Key Vault authorization.

The key takeaway is to keep nonsecret configuration in App Configuration and secrets in Key Vault, while granting the application identity access to each service it directly reads.

• App Configuration owner access is unnecessary because the trace already shows successful App Configuration reads.
• App Configuration resource access fails because the app identity, not the App Configuration service, is shown calling Key Vault.
• Plain configuration secret weakens the security boundary and ignores the intended Key Vault reference pattern.

Question 9

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A Python API enqueues RAG jobs on Azure Service Bus and returns immediately. An Azure Function processes each message and calls Cosmos DB and a model endpoint. A developer reviews one correlated OpenTelemetry trace. Which TWO conclusions are supported by the trace? Select TWO.

Trace excerpt:

Options:

• A. The failure came from the downstream model endpoint call.

• B. The message waited about 2.8 seconds before processing began.

• C. The database query dominated the Function execution time.

• D. The caller waited about 4.56 seconds for the HTTP response.

• E. The Cosmos DB query was the failing dependency.

• F. The 1.64-second Function duration represents queue wait.

Correct answers: A and B

Explanation: For asynchronous work, caller latency is represented by the inbound HTTP span only. Queue wait is the gap between the message send completing and the trigger span starting; here the send span ended at 120 ms and the Function started at 2,920 ms, or about 2,800 ms. Function execution is the duration of the Function span, 1,640 ms. The Cosmos DB dependency succeeded in 185 ms, while the downstream HTTPS call returned Error 502. The key is not to add every correlated span together as caller latency.

• Caller path trap fails because the HTTP POST span ended at 230 ms; later spans are asynchronous processing.
• Function-duration trap fails because the 1,640 ms Function duration is execution time, not queue wait.
• Database-failure trap fails because the Cosmos DB query completed with OK status in 185 ms.

Question 10

Topic: Secure, Monitor, and Troubleshoot Azure Solutions

A team runs a containerized RAG API on Azure Container Apps. It stores embeddings in Azure Cosmos DB for NoSQL and sends ingestion work through Azure Service Bus. After a new revision, users report intermittent 500 responses and latency spikes. Container stdout logs, dependency telemetry, and platform metrics are already in a Log Analytics workspace. Which approach is the best design fit to investigate the incident?

Options:

• A. Rebuild the Cosmos DB vector index before reviewing telemetry

• B. Query the workspace with KQL for the affected revision and time window

• C. Replace Service Bus with Event Grid for ingestion notifications

• D. Move nonsecret settings from Key Vault to App Configuration

Best answer: B

Explanation: KQL is used in Azure Monitor and Log Analytics to query logs and metrics when investigating solution behavior. In this scenario, the needed evidence already exists in a Log Analytics workspace: container logs, dependency telemetry, and platform metrics. The fastest design fit is to query that telemetry by the incident time window, Container Apps revision, status code, dependency failures, and latency signals. This supports correlation across the app, messaging path, and data dependency without changing the architecture first. Configuration cleanup, indexing changes, or messaging redesign might be considered later only if telemetry shows they are relevant.

• Configuration storage misses the incident goal because moving settings does not analyze existing logs or metrics.
• Index rebuild first assumes the cause before checking telemetry and may disrupt the workload unnecessarily.
• Messaging replacement overbuilds the response and does not use the available operational evidence.

Continue with full practice

Use the AI-200 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AI-200 on Web View AI-200 Practice Test

Related focused pages

• Free AI-200 Full-Length Practice Exam
• Develop Containerized Solutions on Azure
• Develop AI Solutions by Using Azure Data Management Services
• Connect to and Consume Azure Services

Free review resource

Read the AI-200 Cheat Sheet for compact concept review before returning to timed practice.