AI-200 secure, monitor and troubleshoot
Secure, monitor, and troubleshoot Azure solutions is worth 20–25% of AI-200. It has four objectives in two pairs: keeping secrets and settings out of code with Azure Key Vault and Azure App Configuration, and seeing what a distributed app is doing with OpenTelemetry tracing and KQL queries. The objective list is short, so each objective carries a lot of weight.
Secure secrets with Key Vault
Access without a credential
The exam’s favourite pattern: the app gets a managed identity, the identity gets a Key Vault role such as Key Vault Secrets User, and the code uses DefaultAzureCredential with the SecretClient from the SDK. No password, client secret or connection string is stored anywhere. When an option removes a stored credential, it is usually the right one.
Prefer the Azure RBAC permission model over legacy access policies for new vaults; it uses the same role assignments as the rest of Azure.
Retrieval
- Fetching a secret by name returns the current version. Fetching by version returns that exact value, which will not change on rotation.
- App Service and Functions can resolve secrets through Key Vault references in app settings, so the code reads an ordinary environment variable.
- Cache retrieved secrets briefly in the app rather than calling Key Vault on every request, which runs into throttling limits.
Rotation
Rotation means creating a new version of the secret and updating the resource it protects. Key Vault publishes events such as SecretNearExpiry to Event Grid, and a Function subscribed to that event can generate the new credential, store it as a new version, and update the target service. Code that always reads the current version picks it up without redeploying.
Soft delete and purge protection keep a deleted secret recoverable. Scenarios about an accidentally deleted secret want recovery from soft delete, not a restore from backup.
Store configuration with App Configuration
App Configuration holds non-secret settings centrally, so several apps and environments can share them.
| Feature | Use it for |
|---|---|
| Key-values | Settings such as endpoints, model names, batch sizes |
| Labels | The same key with different values per environment, such as dev and prod |
| Key Vault references | Pointing to a secret without copying it into App Configuration |
| Feature flags | Turning a feature on or off without redeploying |
| Sentinel key refresh | Reloading configuration in running apps when one watched key changes |
The line to keep clear: secrets live in Key Vault, settings in App Configuration. App Configuration can reference a Key Vault secret, but the value stays in the vault.
Trace distributed systems with OpenTelemetry
An AI back end is rarely one process. A request might pass through an API in Container Apps, a Service Bus queue, a Function and a database. OpenTelemetry follows it across all of them.
- Traces are made of spans, one per unit of work, linked by a shared trace ID.
- Context propagation carries that ID between services, using the W3C
traceparentheader over HTTP. Without propagation, each service produces an unconnected trace. - The Azure Monitor OpenTelemetry distro for Python is set up with
configure_azure_monitor()and a connection string, and sends traces, metrics and logs to Application Insights. - Add custom spans and attributes around work that matters, such as an embedding call or a vector query, so you can see its duration separately.
Analyse logs and metrics with KQL
KQL is read top to bottom as a pipeline of operators separated by |. The ones to know cold:
| Operator | Does |
|---|---|
where | Filter rows, such as where timestamp > ago(1h) |
project | Choose or rename columns |
summarize … by | Aggregate: count(), avg(), percentile(), dcount() |
bin() | Group times into buckets, such as bin(timestamp, 5m) |
join | Combine tables, typically on operation_Id to link a request to its dependencies |
order by, top | Sort, or sort and limit |
render | Chart the result, such as render timechart |
In Application Insights, requests, dependencies, exceptions and traces sit in separate tables. “Which dependency made slow requests slow?” is a join between requests and dependencies on the operation ID.
Sample questions
Question 1. A containerised API reads an API key from Key Vault. The key must be rotated every 90 days with no code change or redeployment, and the API must use the new key within minutes. How should the API read the key?
- A. Read the secret by a specific version identifier stored in app settings
- B. Copy the key into the image at build time
- C. Read the secret by name without a version, with a short in-memory cache
- D. Copy the key into App Configuration as a plain key-value
Show answer
Answer: C
Reading the secret by name returns the current version, so after rotation creates a new version the API receives it on its next read, and a short cache keeps it within minutes. Pinning a version ignores the rotation. Baking the key into the image requires a rebuild. App Configuration key-values are for settings, and copying the key there duplicates the secret outside the vault.
Want more questions like this? Full AI-200 practice tests →
Question 2. Traces from an API and from the Function it calls through a Service Bus queue appear in Application Insights as two unrelated operations. What is missing?
- A. A higher sampling rate in Application Insights
- B. Trace context propagation between the API and the Function through the message
- C. A separate Log Analytics workspace for the Function
- D. A more verbose log level in the Function
Show answer
Answer: B
Separate operations mean the trace context was not carried across the queue, so the Function started a new trace. Propagating the context in the message lets the Function continue the same trace. Sampling reduces volume but does not split traces. A separate workspace would make correlation harder. Log levels affect verbosity, not trace linkage.
Want more questions like this? Full AI-200 practice tests →
Question 3. You need a list of the ten slowest dependency types called by requests that failed in the last hour, based on Application Insights data. Which approach fits?
- A. Summarise average duration of all dependencies by type and take the top ten
- B. Filter requests where success is false and order by duration
- C. Count exceptions by type over the last hour
- D. Filter failed requests, join dependencies on operation_Id, summarise average duration by type and take the top ten
Show answer
Answer: D
Filtering failed requests, joining to dependencies on operation_Id, summarising average duration by dependency type and taking the top ten answers exactly the question. Option A ignores failures. Option B looks only at requests and never reaches dependency data. Option C counts exceptions rather than measuring dependency duration.
Want more questions like this? Full AI-200 practice tests →
What to practise
Give one app a managed identity, grant it a Key Vault role and read a secret with DefaultAzureCredential. Add the Azure Monitor OpenTelemetry distro to two services that talk to each other and confirm they share one trace. Then spend an hour in the Application Insights logs view writing summarize and join queries against your own traffic. KQL is learned by typing it, not by reading about it.