Welcome to the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub!
Welcome to the one-stop hub with information for preparing for the AI-200: Developing AI Cloud Solutions on Azure certification exam. The content for this exam helps prepare you to be “responsible for contributing to all phases of implementing AI solutions on Azure, with an emphasis on back-end services and components. You’re also responsible for supporting all phases of the development lifecycle, including requirements gathering, design, development, deployment, security, and monitoring”. Upon successful completion of the exam, you earn the Microsoft Certified: Azure AI Cloud Developer Associate certification.
This hub provides information directly here (topic-by-topic as outlined in the official study guide), links to a number of external resources, tips for preparing for the exam, practice tests, and section questions to help you prepare. Bookmark this page and use it as a guide to ensure that you are fully covering all relevant topics for the AI-200 exam and making use of as many of the resources available as possible.
Audience Profile (from Microsoft’s site)
As a candidate for this Microsoft Certification, you’re responsible for contributing to all phases of implementing AI solutions on Azure, with an emphasis on back-end services and components. You’re also responsible for supporting all phases of the development lifecycle, including requirements gathering, design, development, deployment, security, and monitoring.
You should be proficient in:
- Azure SDKs and third-party SDKs used in Azure.
- Azure data management services.
- Azure monitoring and troubleshooting.
- Azure messaging and eventing.
- Vector databases.
- Python programming.
- Implementing containerized applications on Azure.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Secure, monitor, and troubleshoot Azure solutions (20–25%) --> Monitor and troubleshoot Azure solutions --> Write KQL queries to analyze logs and metrics
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Azure applications generate large amounts of telemetry, including application logs, resource logs, requests, dependencies, exceptions, performance information, and metrics. For an AI cloud developer, being able to turn this telemetry into useful information is an important troubleshooting and monitoring skill.
Kusto Query Language (KQL) is the query language used by Azure Monitor Logs and Log Analytics. It is designed for querying and analyzing large volumes of structured and semi-structured data. KQL is also used across several Microsoft services, including Azure Monitor, Azure Data Explorer, Microsoft Fabric, and Microsoft Sentinel.
For the AI-200 exam, you should be comfortable reading and writing KQL queries that:
Filter log records
Select and rename columns
Sort results
Limit returned records
Create calculated columns
Aggregate data
Group results
Analyze data over time
Identify errors and exceptions
Analyze application performance
Join or combine related data
Create time-series visualizations
Investigate trends and anomalies
Analyze telemetry from distributed applications
1. What Is Kusto Query Language?
Kusto Query Language (KQL) is a read-only query language optimized for analyzing large datasets.
A KQL query generally starts with a table and then applies a sequence of operations to that table.
The pipe character (|) passes the output of one operation to the next.
Conceptually:
Table
↓
Filter
↓
Filter
↓
Select columns
↓
Results
This pipeline-oriented approach is one of the most important characteristics of KQL.
KQL queries are read-only. They retrieve and analyze data rather than modifying the underlying records.
2. Azure Monitor Logs and Log Analytics
Azure Monitor Logs stores telemetry in a Log Analytics workspace.
Log Analytics is one of the primary tools used in the Azure portal to write and execute KQL queries.
The general relationship is:
Azure Resources / Applications
↓
Azure Monitor
↓
Diagnostic data
↓
Log Analytics Workspace
↓
KQL
↓
Analysis / Alerts /
Workbooks / Reports
Resource logs aren’t automatically available in a Log Analytics workspace simply because the resource exists. A diagnostic setting generally needs to be configured to send resource logs to the workspace.
KQL queries can subsequently be used for troubleshooting, analysis, dashboards, alerts, and reporting.
3. Understanding the Basic KQL Query Structure
A simple KQL query looks like this:
TableName
| operator
| operator
| operator
For example:
AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| project TimeGenerated, Name, ResultCode
Each line operates on the results produced by the previous line.
Important exam concept
KQL isn’t SQL.
For example:
SQL:
SELECT Name, ResultCode
FROM AppRequests
WHERE Success =0;
KQL:
AppRequests
| where Success == false
| project Name, ResultCode
The order and syntax are different.
4. The where Operator
The where operator filters records.
AppRequests
| where Success == false
This returns only unsuccessful requests.
Multiple conditions can be combined:
AppRequests
| where Success == false
| where ResultCode == 500
Or:
AppRequests
| where Success == false and ResultCode == 500
You can also use or:
AppRequests
| where ResultCode == 500 or ResultCode == 503
Common comparison operators
Operator
Meaning
==
Equals
!=
Not equal
>
Greater than
<
Less than
>=
Greater than or equal
<=
Less than or equal
contains
Contains text
startswith
Starts with text
endswith
Ends with text
in
Matches one of several values
Example:
AppRequests
| where ResultCode in (500, 502, 503)
5. Filtering by Time
Time filtering is extremely important when troubleshooting.
A common approach is the ago() function.
AppRequests
| where TimeGenerated > ago(1h)
This means:
Return records generated within the last hour.
Other examples:
| where TimeGenerated > ago(30m)
| where TimeGenerated > ago(24h)
| where TimeGenerated > ago(7d)
You can also specify explicit timestamps:
| where TimeGenerated between (
datetime(2026-08-10 08:00:00) ..
datetime(2026-08-10 12:00:00)
)
Exam tip
When investigating an incident, filtering by time early is usually a good practice because it reduces the amount of data being processed and makes the results easier to interpret.
6. The project Operator
Use project to select the columns you want returned.
AppRequests
| project TimeGenerated, Name, ResultCode
Instead of returning every available column, the query returns only the selected columns.
You can instead summarize performance by endpoint:
AppRequests
| summarize
AverageDuration = avg(DurationMs),
MaximumDuration = max(DurationMs),
RequestCount = count()
by Name
| order by AverageDuration desc
This helps identify endpoints that consistently perform poorly.
23. Counting Distinct Users
The dcount() function provides an approximate distinct count.
For example:
AppRequests
| summarize UniqueUsers = dcount(UserId)
This is often useful for telemetry where an exact distinct count isn’t required.
For example:
AppRequests
| summarize UniqueUsers = dcount(UserId)
by bin(TimeGenerated, 1h)
| render timechart
24. Joining Data
Sometimes the information needed to investigate a problem is stored in multiple tables.
KQL supports operations such as join.
Conceptually:
TableA
| join kind=inner TableB on SomeColumn
For example, you might correlate application records with another dataset containing additional information.
The join operator combines rows from two tables based on matching values.
Important exam consideration
Don’t automatically use join simply because two datasets exist. First determine whether the required information can be obtained from a single table.
Also remember that Azure Monitor has some KQL differences and limitations compared with Azure Data Explorer. For example, certain cross-cluster functionality isn’t supported in Azure Monitor.
25. The union Operator
union combines data from multiple tables or datasets.
Conceptually:
union TableA, TableB
This is useful when similar telemetry exists in multiple tables.
For example, Application Insights telemetry can be analyzed across multiple telemetry tables.
26. Working with Application Insights Telemetry
Application Insights provides application telemetry such as:
Requests
Dependencies
Exceptions
Traces
Page views
Availability results
Custom events
Custom metrics
For example, you can examine requests:
requests
| where timestamp > ago(1h)
| summarize count() by resultCode
Or exceptions:
exceptions
| where timestamp > ago(1h)
| summarize count() by type
| order by count_ desc
The exact tables and schema depend on the telemetry architecture and Azure Monitor/Application Insights configuration being used, so the ability to inspect the available table schema is important.
27. Logs Versus Metrics
A key concept for AI-200 is understanding that logs and metrics are complementary.
Metrics
Metrics are typically numerical measurements designed for efficient monitoring and alerting.
Examples include:
CPU percentage
Request count
Memory utilization
Network traffic
Latency
Logs
Logs provide detailed records about events and operations.
Examples include:
Exceptions
HTTP requests
Dependency calls
Resource operations
Application traces
Security events
A metric might tell you:
Error rate increased to 12%.
A log query can help answer:
Which endpoint is failing, what exception is occurring, and which dependency is involved?
Azure Monitor supports working with both metrics and logs, and log-based metrics can themselves be represented through KQL queries.
28. Querying Resource Logs
Azure resources can send resource logs to Log Analytics through diagnostic settings.
Once the logs are available, KQL can be used to analyze them.
The exact table and fields depend on the Azure service and diagnostic configuration.
29. Using render
The render operator specifies how query results should be visualized.
For example:
AppRequests
| summarize count() by bin(TimeGenerated, 5m)
| render timechart
Other visualization types can be used depending on the data and analysis.
The important exam concept is that render affects how results are displayed, not how the underlying records are filtered or aggregated.
30. Detecting Anomalies
KQL includes capabilities for time-series analysis and anomaly detection.
For example, a time series can be created using make-series.
KQL also provides functions and operators that can be used for anomaly detection and forecasting. Azure Monitor documents these capabilities for analyzing telemetry without having to export the data to an external machine-learning system.
For AI-200, understand the general purpose:
Use KQL time-series capabilities to identify unusual behavior in application or infrastructure telemetry.
31. Example: Detecting an Increase in Errors
A practical investigation might proceed in stages.
Step 1 – Determine whether errors are occurring
AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count()
Step 2 – Determine when they occurred
AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by bin(TimeGenerated, 15m)
| render timechart
Step 3 – Identify the failing endpoints
AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by Name
| order by count_ desc
Step 4 – Identify the status codes
AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by ResultCode
| order by count_ desc
This demonstrates a very useful troubleshooting methodology:
Finally, investigate dependencies associated with those requests.
This type of correlation is especially useful in distributed AI applications where an API might call several backend services.
33. Query Performance and Cost
KQL can process very large datasets, but query design still matters.
Good practices include:
Filter early
Prefer:
AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| summarize count() by Name
rather than processing an unnecessarily large historical dataset.
Select only required columns
Use:
| project TimeGenerated, Name, ResultCode
when you don’t need every column.
Use appropriate time ranges
Don’t query seven days of telemetry when the incident occurred five minutes ago.
Aggregate when appropriate
Instead of returning millions of individual records:
| summarize count() by Name
may provide the information you actually need.
This is especially relevant when working with billable data and large workspaces.
34. Querying Basic and Auxiliary Logs
Azure Monitor supports different table plans, including Analytics, Basic, and Auxiliary tables.
There are additional query limitations for Basic and Auxiliary tables. For example, certain multi-table operations aren’t supported, and Basic table queries are limited to a single table in relevant scenarios. Query costs can also depend on the amount of data scanned.
For the exam, understand that not every KQL query capability is necessarily available against every type of Azure Monitor log table.
35. Running KQL Programmatically
KQL isn’t limited to the Azure portal.
The Azure Monitor Logs Query API allows applications and automation tools to execute KQL queries against a Log Analytics workspace. The API accepts a KQL query and optional time range and returns the query results.
For example, conceptually:
{
"query":"AzureActivity | summarize count() by Category",
"timespan":"PT12H"
}
This makes it possible to build custom monitoring applications and automation around Azure Monitor data.
36. Important KQL Operators for AI-200
You should be familiar with at least the following:
Operator/function
Purpose
where
Filter records
project
Select columns
project-away
Remove columns
extend
Add calculated columns
summarize
Aggregate data
order by
Sort records
take
Limit records
distinct
Return unique values
join
Combine related datasets
union
Combine datasets
render
Visualize results
count()
Count records
countif()
Conditional count
avg()
Average
sum()
Sum
min()
Minimum
max()
Maximum
dcount()
Approximate distinct count
bin()
Group values into intervals
ago()
Calculate a relative time
isnull()
Test for null
isnotnull()
Test for non-null
contains
Search for text
has
Search for a term
in
Match against a list
37. KQL Exam Tips
For AI-200, focus on understanding why an operator is used rather than simply memorizing syntax.
Remember:
where = filter
| where Status == "Failed"
project = choose columns
| project TimeGenerated, Status
extend = calculate/add columns
| extend DurationSeconds = DurationMs / 1000
summarize = aggregate
| summarize count() by Status
order by = sort
| order by DurationMs desc
take = limit rows
| take 10
bin = group into intervals
| summarize count() by bin(TimeGenerated, 5m)
render = visualize
| render timechart
A particularly important pattern is:
TABLE
→ where
→ extend/project
→ summarize
→ order
→ render
38. Putting It All Together
Consider this query:
AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize
FailedRequests = count()
by bin(TimeGenerated, 30m), Name
| order by TimeGenerated asc
| render timechart
This query:
Starts with AppRequests.
Limits the analysis to the last 24 hours.
Keeps unsuccessful requests.
Groups failures into 30-minute intervals.
Separates them by endpoint name.
Sorts the results chronologically.
Creates a time-series visualization.
Understanding how each stage transforms the data is exactly the type of reasoning that can help with AI-200 scenario-based questions.
39. Key Takeaways
For the “Write KQL queries to analyze logs and metrics” topic, make sure you can:
Explain what KQL is.
Explain the role of Log Analytics and Azure Monitor Logs.
Understand KQL’s pipeline syntax.
Filter records with where.
Select columns with project.
Create calculated values with extend.
Aggregate records with summarize.
Group data with by.
Sort results with order by.
Limit results with take.
Find unique values with distinct.
Filter by relative time using ago().
Group time-series data using bin().
Calculate counts, averages, sums, minimums, and maximums.
Use conditional aggregations such as countif().
Analyze errors and exceptions.
Analyze request duration and performance.
Correlate data using join when appropriate.
Combine datasets using union.
Create visualizations using render.
Understand the relationship between logs and metrics.
Understand how diagnostic settings make resource logs available for querying.
Recognize that Azure Monitor has some KQL differences and limitations compared with Azure Data Explorer.
Understand how KQL can be executed programmatically through the Azure Monitor Logs Query API.
Practice Exam Questions
Question 1
An AI-powered web application is experiencing intermittent HTTP 500 errors. You need to determine how many failed requests occurred during each 10-minute interval during the last hour.
Which KQL query should you use?
A.
AppRequests
| where TimeGenerated > ago(1h)
| where ResultCode == 500
| summarize count() by bin(TimeGenerated, 10m)
B.
AppRequests
| where TimeGenerated > ago(10m)
| summarize count() by ResultCode
C.
AppRequests
| summarize count() by TimeGenerated
| where ResultCode == 500
D.
AppRequests
| project ResultCode
| take 10
Answer: A
Explanation
where filters the data to the desired time period and status code. summarize count() counts the records, while bin(TimeGenerated, 10m) groups the results into 10-minute intervals.
Question 2
You need to identify the 20 slowest API requests made during the last two hours.
Which query should you use?
A.
AppRequests
| summarize avg(DurationMs) by Name
| take 20
B.
AppRequests
| where TimeGenerated > ago(2h)
| order by DurationMs desc
| take 20
C.
AppRequests
| where DurationMs > 20
| summarize count()
D.
AppRequests
| project DurationMs
| order by DurationMs asc
Answer: B
Explanation
The query first restricts the data to the last two hours, sorts individual requests by duration in descending order, and then returns the first 20 records. This identifies the slowest individual requests.
Question 3
An application team wants to calculate the average request duration for each API endpoint.
Which operator should primarily be used?
A.project
B.extend
C.summarize
D.take
Answer: C
Explanation
summarize is the KQL operator used for aggregation. For example:
AppRequests
| summarize AverageDuration = avg(DurationMs) by Name
project selects columns, extend creates calculated columns, and take limits the number of returned records.
Question 4
You need to add a column called DurationSeconds containing the request duration converted from milliseconds to seconds.
Which KQL statement should you use?
A.
| summarize DurationSeconds = DurationMs / 1000
B.
| project DurationSeconds = DurationMs / 1000
C.
| extend DurationSeconds = DurationMs / 1000.0
D.
| where DurationSeconds = DurationMs / 1000
Answer: C
Explanation
extend adds a calculated column while retaining the existing columns. Using 1000.0 also ensures the calculation is performed as a floating-point calculation.
Question 5
An administrator wants to identify the number of failed operations grouped by operation name.
countif() counts records that satisfy a condition, and by OperationNameValue groups the counts by operation. This directly answers the requirement.
Question 6
You are investigating application traffic and want to see request counts in five-minute intervals displayed as a time-series chart.
Which query should you use?
A.
AppRequests
| take 5
| render timechart
B.
AppRequests
| summarize count() by TimeGenerated
| render piechart
C.
AppRequests
| summarize count() by bin(TimeGenerated, 5m)
| render timechart
D.
AppRequests
| project TimeGenerated
| render timechart
Answer: C
Explanation
bin() groups timestamps into five-minute intervals, summarize count() counts requests in each interval, and render timechart produces the time-series visualization.
Question 7
You want to return only the TimeGenerated, Name, and ResultCode columns from a request table.
Which operator should you use?
A.extend
B.project
C.summarize
D.distinct
Answer: B
Explanation
project controls which columns are returned.
For example:
AppRequests
| project TimeGenerated, Name, ResultCode
Question 8
You need to investigate exceptions generated during the previous 30 minutes and display only records where the exception message contains the word “timeout.”
Which query is appropriate?
A.
AppExceptions
| where TimeGenerated > ago(30m)
| where OuterMessage contains "timeout"
B.
AppExceptions
| summarize count() by OuterMessage
C.
AppExceptions
| project TimeGenerated
| take 30
D.
AppExceptions
| order by OuterMessage
Answer: A
Explanation
The first where restricts the data to the previous 30 minutes. The second filters exception messages containing "timeout".
Question 9
An application team wants to determine the approximate number of distinct users who generated requests during each hour.
Which query should you use?
A.
AppRequests
| summarize count(UserId) by bin(TimeGenerated, 1h)
B.
AppRequests
| summarize distinct(UserId) by bin(TimeGenerated, 1h)
C.
AppRequests
| summarize dcount(UserId) by bin(TimeGenerated, 1h)
D.
AppRequests
| distinct UserId
| render timechart
Answer: C
Explanation
dcount() provides an approximate distinct count. Combining it with bin(TimeGenerated, 1h) produces an approximate unique-user count for each hour.
Question 10
An application has experienced a sudden increase in failures. You want to determine whether the failures are concentrated in particular API endpoints and identify the number of failures per endpoint.
Which query is most appropriate?
A.
AppRequests
| take 10
B.
AppRequests
| project Name, Success
C.
AppRequests
| summarize avg(DurationMs) by Name
D.
AppRequests
| where Success == false
| summarize FailureCount = count() by Name
| order by FailureCount desc
Answer: D
Explanation
The query filters for failed requests, groups those failures by endpoint name, counts the failures, and sorts the endpoints from the highest failure count to the lowest. This is an effective way to identify which API endpoints are contributing most to the incident.
Final Exam Perspective
The most important thing to remember for this AI-200 topic is that KQL is fundamentally about turning large volumes of telemetry into actionable information.
A scenario might give you thousands or millions of log records and ask you to determine:
What failed?
Use where.
How many failed?
Use summarize count() or countif().
Where did the failures occur?
Use summarize ... by.
When did they occur?
Use bin() with a timestamp.
Which endpoint is the slowest?
Use summarize avg() or inspect individual records with order by.
What happened during the last hour?
Use ago(1h).
What does the trend look like?
Use time-based summarize and render timechart.
What information do I actually need to see?
Use project.
If you can recognize these patterns quickly, you will be well prepared for the KQL-related scenario questions in AI-200. Azure Monitor’s KQL capabilities are specifically designed for exploring logs, transforming and aggregating telemetry, identifying patterns and anomalies, troubleshooting applications, and supporting alerts and reports.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Secure, monitor, and troubleshoot Azure solutions (20–25%) --> Monitor and troubleshoot Azure solutions --> Trace distributed systems by using OpenTelemetry SDKs
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Modern AI applications are rarely single-process applications. A typical solution might include an API hosted in Azure App Service or Azure Container Apps, Azure Functions for background processing, Azure Service Bus or Event Grid for messaging, a database such as Azure Cosmos DB or Azure Database for PostgreSQL, and one or more AI services.
When a request travels through several of these components, determining where time was spent, where an error occurred, or which downstream dependency caused a failure can be difficult if each component produces isolated logs.
OpenTelemetry (OTel) addresses this problem by providing a vendor-neutral framework for generating, collecting, and exporting telemetry—including traces, metrics, and logs. For AI-200, an especially important capability is distributed tracing, which allows a request to be followed across application and service boundaries.
The key exam skill is understanding how OpenTelemetry SDKs create spans, associate spans into traces, propagate trace context between services, and export telemetry to an observability backend.
1. What Is Distributed Tracing?
Distributed tracing tracks a single logical operation as it moves through multiple services, processes, and infrastructure components.
Consider an AI application with this architecture:
Client
│
▼
API
│
├──► Azure Cosmos DB
│
├──► Azure OpenAI
│
└──► Azure Service Bus
│
▼
Azure Function
│
▼
PostgreSQL
A user might submit a question to the API. The API retrieves information from Cosmos DB, calls an AI model, places a message on Service Bus, and an Azure Function processes the message.
Without distributed tracing, each component might generate its own logs:
API log:
Request completed in 2.8 seconds
Cosmos DB log:
Query completed in 150 ms
Azure Function log:
Execution completed in 1.9 seconds
It can be difficult to determine whether these records belong to the same user request.
With distributed tracing, OpenTelemetry can associate the operations with a common Trace ID:
Trace ID: 7bba9f...
└── API request
├── Cosmos DB query
├── Azure OpenAI request
└── Service Bus operation
└── Function execution
└── PostgreSQL query
This allows developers to visualize the complete path of a request and identify slow or failing components.
A trace is composed of spans, with each span representing an individual operation. Spans can be nested to represent parent-child relationships.
2. Trace vs. Span
These two terms are fundamental to the AI-200 topic.
Trace
A trace represents the complete journey of a logical operation through a distributed system.
For example:
Trace
│
├── HTTP request
│
├── Database query
│
├── AI model request
│
└── Message processing
A trace is identified by a Trace ID.
Span
A span represents a single unit of work within the trace.
Examples include:
An HTTP request
A database query
An Azure SDK operation
An RPC call
A call to an AI service
A message-processing operation
A custom application operation
A span typically contains information such as:
Span name
Trace ID
Span ID
Parent span ID
Start time
End time
Attributes
Events
Status
Links
For example:
Trace ID: ABC123
Span: HTTP GET /orders
│
├── Span: SQL SELECT
│
└── Span: HTTP GET /customer
The parent-child relationship allows the tracing system to reconstruct the request’s execution path.
3. The OpenTelemetry API and SDK
OpenTelemetry separates the API from the SDK.
OpenTelemetry API
The API provides interfaces that application code and instrumentation can use to create telemetry.
For tracing, the API includes concepts such as:
TracerProvider
Tracer
Span
SpanContext
OpenTelemetry SDK
The SDK provides the implementation responsible for processing and exporting telemetry.
The SDK can handle:
Span creation
Sampling
Span processing
Exporting
Resource information
Propagation configuration
A TracerProvider is generally initialized as part of application startup and is used to create Tracer instances.
Conceptually:
Application
│
▼
TracerProvider
│
▼
Tracer
│
▼
Span
│
▼
Span Processor
│
▼
Exporter
│
▼
Telemetry backend
4. What Is a Tracer?
A Tracer creates spans.
For example, an application might obtain a tracer for its order-processing component:
Tracer
│
├── Span: Validate order
├── Span: Retrieve customer
└── Span: Submit payment
The tracer itself does not represent the operation. Instead, it is the mechanism used to create spans describing operations.
A common pattern is to initialize the tracing infrastructure once and then obtain tracers from the configured TracerProvider.
5. Span Context
A SpanContext contains the information necessary to identify and propagate a span’s tracing context.
Important fields include:
Trace ID — identifies the overall trace.
Span ID — identifies the current span.
Trace flags — include information such as whether the trace is sampled.
Trace state — can carry tracing-system-specific information.
The SpanContext is especially important because it is the portion of tracing information that can be serialized and propagated between processes.
For example:
Service A
Trace ID = 123
Span ID = ABC
│
│ propagate context
▼
Service B
Trace ID = 123
Span ID = XYZ
Parent = ABC
Service B creates a new span but associates it with the existing trace.
6. Context Propagation
Context propagation is the key concept behind distributed tracing.
Suppose Service A calls Service B:
Service A
│
│ HTTP request
▼
Service B
Service A needs to transmit its tracing context with the request.
Service B then extracts that context and creates a child span.
Service A
Trace ID = 123
Span ID = AAA
│
│ trace context
▼
Service B
Trace ID = 123
Span ID = BBB
Parent = AAA
The result is a single trace containing both operations.
OpenTelemetry commonly uses the W3C Trace Context format for this purpose. HTTP requests can carry trace context using headers such as traceparent.
Why this matters
Without context propagation:
Service A → Trace A
Service B → Trace B
The observability platform cannot reliably determine that the operations belong to the same request.
With context propagation:
Service A ───────┐
│
▼
Trace 123
▲
│
Service B ───────┘
The complete distributed operation can be reconstructed.
7. Automatic vs. Manual Context Propagation
In many applications, instrumentation libraries automatically inject and extract trace context.
For example:
HTTP client
│
▼
Instrumentation
│
├── inject trace context
▼
HTTP request
The receiving service’s instrumentation can extract the context automatically.
This is preferred because it reduces custom tracing code and helps maintain consistent propagation behavior. OpenTelemetry documentation notes that instrumentation libraries handle propagation automatically for many common scenarios.
Manual propagation may be necessary when:
A custom transport is being used.
A messaging protocol is not automatically instrumented.
Application-specific integration is required.
The developer needs explicit control over propagation.
The general concepts are:
Inject
Current Context
│
▼
Propagator
│
▼
Outgoing message
Extract
Incoming message
│
▼
Propagator
│
▼
Remote Context
The OpenTelemetry Propagators API provides mechanisms for injecting and extracting context from messages.
8. Distributed Tracing Across Messaging Systems
Distributed systems don’t communicate only through HTTP.
AI applications frequently use:
Azure Service Bus
Azure Event Grid
Queues
Event streams
Background workers
For example:
API
│
│ send message
▼
Service Bus
│
│ receive message
▼
Azure Function
The original request may create one trace, while the message-processing operation occurs later and potentially on another compute instance.
Tracing context can be propagated through messaging metadata when supported and correctly configured.
This allows developers to understand relationships such as:
Trace
│
├── API request
│
└── Message publishing
│
└── Message processing
│
└── Database operation
An important distinction is that asynchronous processing can have different causal relationships from a simple synchronous HTTP call. OpenTelemetry supports Span Links for situations where an operation is related to another span but doesn’t necessarily fit a straightforward parent-child hierarchy.
9. Span Attributes
Attributes are key-value pairs attached to spans.
They provide additional information about an operation.
For example:
Span:
Name: GET /orders
Attributes:
http.request.method = GET
http.route = /orders
customer.tier = premium
order.type = subscription
Attributes can help developers filter and analyze telemetry.
However, developers should avoid placing sensitive information into telemetry.
For example, avoid attributes containing:
Passwords
Access keys
Authentication tokens
Credit-card information
Sensitive personal information
The same caution applies to OpenTelemetry Baggage, because baggage can be propagated between services. OpenTelemetry specifically recommends avoiding sensitive data in baggage.
10. Span Events
A span can contain events representing notable occurrences during an operation.
For example:
Span: ProcessOrder
Events:
10:01:02 - ValidationStarted
10:01:03 - ValidationCompleted
10:01:04 - PaymentSubmitted
Events are useful when a developer needs more detail about what happened during a span without creating a separate span for every small occurrence.
11. Span Status
A span can have a status indicating the outcome of an operation.
For example:
Status: OK
or:
Status: ERROR
An error status can help identify failed operations when examining distributed traces.
For example:
Trace
│
├── API request OK
│
├── Cosmos DB query OK
│
└── AI service request ERROR
This immediately focuses troubleshooting on the AI service operation.
12. Resources
OpenTelemetry also associates telemetry with resources.
A resource describes the entity producing the telemetry.
Examples include:
Service name
Service version
Host
Container
Kubernetes pod
Kubernetes namespace
Cloud environment
For example:
Service:
order-api
Version:
2.4.0
Environment:
production
Container:
order-api-7d9f
Resource information becomes particularly useful when many instances of the same application generate telemetry.
OpenTelemetry defines resources as information describing the entity for which telemetry is recorded.
13. Exporters
Creating spans is only part of the process. The telemetry needs to be sent somewhere where it can be analyzed.
An exporter sends telemetry to a destination.
Conceptually:
Application
│
▼
OpenTelemetry SDK
│
▼
Span Processor
│
▼
Exporter
│
▼
Observability backend
Possible destinations include:
OpenTelemetry Collector
Azure Monitor
Other observability platforms
Console output for development/testing
OpenTelemetry is vendor-neutral, so applications can use exporters appropriate to their target telemetry backend.
14. OpenTelemetry Collector
The OpenTelemetry Collector provides a vendor-neutral way to receive, process, and export telemetry.
A common architecture is:
Application A ─┐
Application B ─┼──► OpenTelemetry Collector ───► Backend
Application C ─┘
The Collector can act as an intermediary between applications and observability platforms.
This can be valuable when an organization wants to:
Centralize telemetry processing
Change telemetry destinations without modifying every application
Filter or transform telemetry
Batch telemetry
Route telemetry to different destinations
The Collector is separate from the OpenTelemetry SDK running inside the application.
15. Sampling
Large distributed applications can generate enormous numbers of spans.
Sampling controls how much tracing data is collected.
For example, an application processing one million requests per day may not need to retain every successful request.
A sampling strategy might retain:
100% of errors
100% of slow requests
A percentage of successful requests
Conceptually:
1,000,000 requests
│
▼
Sampler
│
├── 10% normal requests
└── 100% important/error requests
Sampling reduces telemetry volume, storage requirements, and processing overhead.
OpenTelemetry supports sampling decisions at different stages of telemetry collection.
Exam point
Do not confuse sampling with filtering at the observability backend.
Sampling can influence whether a span is recorded/exported in the first place, whereas backend filtering occurs after telemetry has already reached the collection pipeline.
16. Span Processors
A SpanProcessor receives spans during their lifecycle and passes them through the telemetry pipeline.
Conceptually:
Span
│
▼
Span Processor
│
▼
Exporter
OpenTelemetry supports processors such as:
Simple span processing
Batch span processing
A batch processor can accumulate spans and export them together rather than exporting every span immediately.
This can improve efficiency and reduce the overhead associated with frequent network calls.
17. Instrumentation
Instrumentation is the process of adding telemetry generation to an application.
There are two broad approaches.
Automatic instrumentation
Automatic instrumentation uses libraries, agents, or platform capabilities to instrument common frameworks and dependencies.
Examples may include automatically tracing:
HTTP requests
HTTP clients
Database calls
Framework operations
Messaging operations
This is generally the easiest way to get broad application coverage.
Manual instrumentation
Manual instrumentation allows developers to explicitly create spans around application-specific operations.
For example:
Start span: GenerateAnswer
Retrieve documents
Build prompt
Call model
Process response
End span: GenerateAnswer
Manual instrumentation is particularly useful for business operations that automatic instrumentation doesn’t understand.
18. Custom Spans
Suppose an AI application performs a business operation called GenerateRecommendation.
An HTTP instrumentation library may capture the HTTP request, but that doesn’t necessarily describe the application’s internal business process.
A developer can create a custom span:
Trace
│
└── HTTP POST /recommend
│
└── GenerateRecommendation
│
├── RetrieveDocuments
└── CallAIModel
This provides much better visibility into application-specific processing.
A good custom span should represent a meaningful unit of work—not every individual line of code.
19. Trace Context and the W3C Trace Context Standard
For distributed tracing to work across different technologies, services need a common format for transmitting tracing information.
OpenTelemetry commonly uses the W3C Trace Context specification.
An HTTP request can contain a traceparent header carrying tracing information.
Conceptually:
traceparent:
00-<trace-id>-<parent-span-id>-<flags>
The receiving service extracts the information and uses it when creating its span.
This is one of the most important mechanisms that allows heterogeneous applications to participate in the same distributed trace.
20. OpenTelemetry in Azure Applications
For AI-200, think of OpenTelemetry as a technology that can span the entire Azure application architecture.
For example:
┌───────────────┐
│ Client │
└───────┬───────┘
│
▼
┌───────────────┐
│ API / App │
└───────┬───────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Cosmos DB AI Service Service Bus
│
▼
Azure Function
│
▼
PostgreSQL
A properly instrumented solution can create a trace that makes the entire processing path observable.
This is especially valuable for AI applications because an apparently slow API request may actually be caused by:
A database query
A vector search
An AI model request
A downstream HTTP service
A message-processing delay
A function execution
A retry
Network latency
Distributed tracing helps identify which operation actually contributed to the latency.
21. Troubleshooting With Distributed Traces
Consider an API that normally responds in 500 ms but suddenly takes 6 seconds.
A conventional application log might show:
POST /chat completed in 6 seconds
That tells you the symptom but not the cause.
A distributed trace might show:
POST /chat 6.0 sec
│
├── Authentication 50 ms
├── Cosmos DB query 100 ms
├── Vector search 250 ms
├── AI model request 5.4 sec
└── Response processing 200 ms
Now the likely problem is immediately visible.
Another trace might show:
POST /chat 6.0 sec
│
├── Cosmos DB query 100 ms
├── Service Bus send 20 ms
└── Function processing 5.8 sec
│
└── PostgreSQL query 5.6 sec
The problem is now much more likely to be the database operation rather than the API itself.
Developer-created instrumentation for custom operations
26. Exam Scenario: Putting It All Together
Imagine an AI chatbot architecture:
User
│
▼
Azure App Service
│
├──► Azure Cosmos DB
│
├──► AI model
│
└──► Azure Service Bus
│
▼
Azure Function
│
▼
PostgreSQL
The application is instrumented with OpenTelemetry.
A request generates:
Trace ID = 12345
Span 1: HTTP POST /chat
│
├── Span 2: Cosmos DB query
│
├── Span 3: AI model request
│
└── Span 4: Service Bus publish
│
└── Span 5: Function processing
│
└── Span 6: PostgreSQL query
The important concepts are:
The trace represents the overall operation.
Each span represents a unit of work.
The Trace ID associates the spans.
Context propagation allows tracing information to cross service boundaries.
Span attributes provide additional diagnostic information.
Span events record significant occurrences.
The SDK processes the telemetry.
A span processor manages the span processing pipeline.
An exporter sends telemetry to a destination.
Sampling can reduce telemetry volume.
An OpenTelemetry Collector can provide an intermediary telemetry pipeline.
If you understand that flow, you have the foundation needed for most AI-200 questions involving OpenTelemetry.
Practice Exam Questions
Question 1
An AI application consists of an API, an Azure Function, and a database. A developer wants to follow a single user request across all three components.
Which OpenTelemetry capability is most important?
A. Resource tagging B. Metric aggregation C. Log rotation D. Context propagation
Answer: D
Explanation: Context propagation allows tracing information to travel across process and service boundaries. This enables spans generated by different components to be associated with the same trace. Without propagation, each service could create an isolated trace.
Question 2
An application creates a trace for an HTTP request. The request then causes a database query and a call to an AI service.
What should represent the database query and AI service call?
A. Separate resources B. Separate spans within the trace C. Separate TraceProviders D. Separate exporters
Answer: B
Explanation: A span represents a unit of work. The database query and AI service call can each be represented by spans that belong to the overall trace.
Question 3
An organization wants to reduce the amount of tracing data generated by a high-volume application while continuing to collect a representative subset of traces.
Which OpenTelemetry capability should be configured?
A. Propagation B. Span attributes C. Resource detection D. Sampling
Answer: D
Explanation: Sampling controls which traces or spans are recorded and/or exported. It is commonly used to reduce telemetry volume and overhead in high-volume applications.
Question 4
Service A sends an HTTP request to Service B. Service B must create a span that belongs to the same distributed trace as the request from Service A.
What must occur?
A. Service B must use the same Span ID as Service A. B. Service A and Service B must use the same Tracer instance. C. Service B must export its telemetry before Service A. D. Trace context must be propagated from Service A to Service B.
Answer: D
Explanation: Trace context propagation allows Service B to obtain the Trace ID and parent span information from Service A. Service B creates its own span while maintaining the relationship with the existing trace. The child span should have its own Span ID.
Question 5
A developer wants to attach information such as order.type = subscription to a span representing an order-processing operation.
What should the developer use?
A. Span attribute B. Span exporter C. Trace ID D. Propagator
Answer: A
Explanation: Span attributes are key-value pairs used to add metadata to spans. They can make traces easier to filter, search, and analyze.
Question 6
An application uses OpenTelemetry and needs to send collected spans to a telemetry backend.
Which component is responsible for sending the telemetry to the destination?
A. Tracer B. Exporter C. SpanContext D. Resource
Answer: B
Explanation: An exporter sends telemetry to a destination such as an OpenTelemetry Collector, Azure Monitor, or another supported observability backend.
Question 7
An application uses a custom messaging mechanism that isn’t automatically instrumented. The developer needs to transfer OpenTelemetry trace context through the message.
Which OpenTelemetry concept is specifically designed to inject and extract context from messages?
A. Resource B. Span Event C. Propagator D. Sampler
Answer: C
Explanation: Propagators provide mechanisms for injecting context into and extracting context from carriers such as HTTP headers or message metadata.
Question 8
A development team needs to determine which operation caused an individual API request to take 8 seconds. The API calls three downstream services.
Which telemetry signal is most appropriate for following the request through the individual services?
A. Distributed trace B. Aggregate metric C. Static configuration D. Resource definition
Answer: A
Explanation: Distributed tracing is specifically designed to follow individual operations across distributed components. A trace can reveal which downstream operation consumed most of the 8 seconds.
Question 9
An application generates millions of spans. The development team wants to process spans in groups before exporting them to reduce the overhead associated with exporting each span individually.
Which component is relevant to this requirement?
A. Trace ID B. Batch span processor C. Propagator D. SpanContext
Answer: B
Explanation: A batch span processor collects spans and exports them in batches. This can improve efficiency compared with exporting every span individually.
Question 10
An AI application sends trace context to an external service. Developers are considering adding user credentials and other sensitive information to OpenTelemetry baggage so that it can be available to downstream services.
What is the best approach?
A. Add the credentials to baggage because baggage is encrypted by OpenTelemetry. B. Add credentials only to the Trace ID. C. Store the credentials in span attributes instead. D. Do not place credentials or other sensitive information in baggage.
Answer: D
Explanation: Baggage can be propagated across service boundaries, so sensitive information placed in baggage may be transmitted to downstream systems. Credentials, API keys, and other sensitive information should not be placed in baggage.
Quick Review
Before taking the AI-200 exam, make sure you can answer these questions confidently:
What is a trace? — The complete distributed operation.
What is a span? — An individual unit of work within a trace.
What creates spans? — A Tracer.
What provides tracers? — A TracerProvider.
What connects spans across services? — Context propagation.
What carries trace/span identity? — SpanContext.
What injects and extracts propagation data? — Propagators.
What adds metadata to spans? — Attributes.
What records occurrences within a span? — Events.
What sends telemetry somewhere? — An exporter.
What can batch spans before export? — A span processor.
What reduces telemetry volume? — Sampling.
What describes the telemetry-producing entity? — A resource.
What can receive, process, and forward telemetry? — The OpenTelemetry Collector.
What lets you follow a request across distributed services? — Distributed tracing.
What should never be casually placed in telemetry or baggage? — Secrets and sensitive information.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Secure, monitor, and troubleshoot Azure solutions (20–25%) --> Implement secure Azure solutions --> Store and retrieve app configuration information by using Azure App Configuration
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Azure applications frequently need configuration values such as database endpoints, service URLs, application settings, feature flags, and environment-specific options. Keeping these values directly inside application code or configuration files can make applications harder to maintain, deploy, and operate.
Azure App Configuration is a managed Azure service that provides a centralized place to store and manage application configuration settings and feature flags. Applications can retrieve these settings at runtime, and supported application frameworks can refresh configuration dynamically without requiring an application restart.
For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how to:
Create and manage an App Configuration store
Store configuration as key-value pairs
Organize configuration using key prefixes and labels
Retrieve configuration from applications
Use feature flags
Secure access to App Configuration
Use managed identities
Combine App Configuration with Azure Key Vault
Refresh configuration dynamically
Understand configuration precedence and environment-specific settings
1. What Is Azure App Configuration?
Azure App Configuration is a centralized configuration service designed to separate application configuration from application code.
App Configuration can contain references to secrets stored in Key Vault, allowing the application configuration and secret management concerns to work together.
3. Key-Value Pairs
The fundamental storage mechanism in App Configuration is the key-value pair.
For example:
Key
Value
App:Name
CustomerAI
App:MaxResults
25
AI:Model
gpt-model-1
AI:Temperature
0.2
Database:Endpoint
https://...
The key identifies the setting, while the value contains the configuration data.
App Configuration treats keys as strings. It does not interpret hierarchical delimiters itself. Developers commonly use characters such as : or / to create logical namespaces.
For example:
AI:Model
AI:Temperature
AI:MaxTokens
Database:Endpoint
Database:Timeout
Logging:Level
Logging:EnableDiagnostics
This makes configuration easier to organize and query.
4. Keys Are Case-Sensitive
App Configuration keys are case-sensitive.
For example:
App:Name
and:
app:name
are distinct keys.
However, relying on capitalization alone to distinguish settings is generally discouraged because application frameworks may handle configuration keys differently.
Exam tip
Remember:
App Configuration keys are case-sensitive.
5. Labels
One of the most important App Configuration concepts for AI-200 is the label.
A label allows different values to be associated with the same key.
For example:
Key: AI:Model
could have:
Key
Label
Value
AI:Model
Development
model-dev
AI:Model
Test
model-test
AI:Model
Production
model-prod
This allows an application to use different configuration values depending on its environment.
Why labels are useful
Labels are commonly used for:
Development
Testing
Staging
Production
Application versions
Regional configurations
Deployment rings
For example:
AI:Temperature
could be:
Development → 0.8
Production → 0.2
The application doesn’t need a different key name for every environment.
6. Unlabeled Configuration
A key-value can also have no label.
For example:
AI:Model
Label: Production
Value: production-model
and:
AI:Temperature
Label: Production
Value: 0.2
An unlabeled value can act as a common/default configuration.
A useful pattern is:
No label → default
Development → development override
Test → test override
Production → production override
If an environment-specific value doesn’t exist, the application can use the unlabeled value as the fallback, depending on how configuration is loaded.
7. Configuration Namespaces
A hierarchical naming convention makes large configuration stores much easier to manage.
For example:
AI:Model
AI:Endpoint
AI:Temperature
AI:MaxTokens
Database:Server
Database:DatabaseName
Database:Timeout
Storage:Account
Storage:Container
Logging:Level
Logging:EnableDiagnostics
A developer can then retrieve groups of settings using key filters.
For example:
AI:*
can represent all keys beginning with:
AI:
This is especially useful when multiple services share an App Configuration store.
8. Retrieving Configuration
Applications can retrieve configuration from App Configuration using client libraries appropriate to their language and framework.
Supported integrations include:
.NET
ASP.NET Core
Java/Spring
JavaScript/Node.js
Python
Go
REST API
The application establishes access to the App Configuration store and loads the required key-values.
A conceptual flow is:
Application starts
|
v
Authenticate to App Configuration
|
v
Select configuration keys
|
v
Load key-value pairs
|
v
Application uses settings
The application doesn’t need to know where each individual configuration value is physically stored.
9. Authentication and Secure Access
Applications need permission to access an App Configuration store.
A production application should generally use Microsoft Entra ID authentication and managed identities rather than embedding credentials or connection strings in source code.
For example:
Azure Function
|
| Managed Identity
v
Azure App Configuration
The managed identity can be granted appropriate permissions to read configuration.
This avoids putting long-lived credentials in application code.
Why this matters for AI-200
When you see a scenario asking for:
“The most secure way for an Azure-hosted application to access App Configuration without storing credentials in code”
App Configuration can store a Key Vault reference, allowing the application to retrieve a secret through the reference rather than storing the secret itself in App Configuration.
Exam distinction
If the question asks:
Where should an API secret be stored?
Think:
Azure Key Vault
If it asks:
Where should application configuration and feature flags be centrally managed?
Think:
Azure App Configuration
11. Feature Flags
Azure App Configuration also provides feature management.
A feature flag controls whether functionality is enabled.
Conceptually:
if (NewSearchFeatureEnabled)
{
// New implementation
}
else
{
// Existing implementation
}
This allows application code to be deployed independently from feature availability.
For example, a new AI-powered search feature could be deployed but initially disabled:
NewAISearch = OFF
Later:
NewAISearch = ON
No application redeployment is necessarily required just to change the feature flag.
12. Why Feature Flags Are Useful
Feature flags can support:
Dark deployment
Deploy code without exposing it to users.
Gradual rollout
Enable functionality for an increasing percentage of users.
A/B testing
Compare different implementations or experiences.
Emergency disablement
Turn off problematic functionality without redeploying the application.
Targeted releases
Enable functionality for particular users or groups.
Azure App Configuration supports feature filters, including targeting and time-window scenarios. Custom filters can also be implemented.
13. Dynamic Configuration
One of the most valuable capabilities of App Configuration is dynamic configuration.
Normally, an application might load configuration during startup:
Application starts
↓
Load configuration
↓
Run application
If configuration changes afterward, the application might continue using the old value until it restarts.
Dynamic configuration changes this behavior:
Application starts
↓
Load configuration
↓
Run application
↓
Configuration changes
↓
Refresh
↓
Application uses new configuration
Supported client libraries can refresh configuration without restarting the application.
14. Refresh Is Not Automatic by Default
This is an important exam concept.
Simply loading configuration from App Configuration does not mean that every configuration value is automatically monitored for changes.
For the .NET provider, for example, you explicitly configure refresh behavior using ConfigureRefresh and register the keys that should be monitored.
Two important patterns are:
Register all selected keys
Register a specific key as a refresh trigger
15. RegisterAll
RegisterAll() tells the configuration provider to monitor the selected key-values for changes.
Conceptually:
ConfigureRefresh
|
+-- RegisterAll()
When a selected value changes, the provider can refresh the configuration.
A refresh interval can also be configured to prevent excessive requests.
For example, the .NET provider supports:
SetRefreshInterval(...)
The default refresh interval for the provider is 30 seconds if one isn’t explicitly configured.
16. Sentinel Keys
A sentinel key is an especially important pattern for managing changes to multiple configuration values.
Suppose you need to change:
AI:Model
AI:Temperature
AI:MaxTokens
AI:TopP
You don’t necessarily want the application to reload after each individual change.
Instead, create a sentinel key:
AI:Settings:Sentinel
Update the configuration values first:
AI:Model
AI:Temperature
AI:MaxTokens
AI:TopP
Then update:
AI:Settings:Sentinel
The application monitors the sentinel key.
When it changes, the application refreshes the configuration.
Change settings
↓
Change sentinel
↓
Sentinel detected
↓
Refresh configuration
↓
All settings loaded together
This helps ensure that a group of related configuration changes becomes active together. It also reduces unnecessary monitoring of every individual key.
Exam tip
If a question says:
“Several configuration values must be changed together, and the application should refresh only after all changes have been completed.”
Think:
Sentinel key.
17. Configuration Refresh and Caching
App Configuration clients can cache configuration locally.
This provides an important resilience benefit.
If a refresh attempt fails, applications using the supported provider can continue using their cached configuration rather than immediately failing because App Configuration could not be contacted.
This is important for production applications because configuration services should not unnecessarily become a single point of failure for application execution.
18. Event-Driven Configuration Updates
App Configuration can also emit events when key-values change.
These events can be delivered through Azure Event Grid.
For example:
App Configuration
|
| configuration changed
v
Event Grid
|
+--------> Azure Function
|
+--------> Logic App
|
+--------> HTTP endpoint
This can be used to trigger workflows such as:
Configuration refresh
Deployment automation
Cache invalidation
Operational notifications
This is different from an application simply polling the configuration store for changes.
19. Common Configuration Architecture
A production AI application might use the following architecture:
The application accesses both using its managed identity.
20. App Configuration vs. Environment Variables
Environment variables are still useful for many applications, particularly for simple deployment-specific configuration.
However, App Configuration becomes valuable when:
Multiple applications need the same settings
Configuration must be centrally managed
Different environments need different values
Feature flags are required
Configuration needs to change dynamically
Configuration needs centralized governance
A typical architecture might use environment variables for bootstrapping information while App Configuration provides the application’s broader configuration.
21. App Configuration vs. Configuration Files
Traditional application:
appsettings.json
↓
Application
Centralized configuration:
Azure App Configuration
↓
Application
The second approach is particularly valuable in distributed environments where many application instances need consistent configuration.
For example, imagine 50 containers running an AI API.
With local configuration files, changing an AI model endpoint could require updating and redeploying the application.
With App Configuration, the setting can be changed centrally and, when dynamic refresh is configured, propagated to the running applications.
22. Best Practices
1. Don’t store secrets directly in App Configuration
Use Key Vault for secrets.
2. Use managed identities
Avoid hard-coded credentials and unnecessary connection strings.
3. Establish a consistent key naming convention
For example:
AI:Model
AI:Endpoint
AI:Temperature
Database:Endpoint
Database:Timeout
4. Use labels for environment-specific configuration
For example:
Development
Test
Production
5. Use feature flags for controlled releases
Separate feature deployment from feature activation.
6. Use dynamic refresh when appropriate
This avoids unnecessary application restarts for configuration changes.
7. Use sentinel keys for coordinated updates
This is particularly useful when several settings must change as one logical configuration update.
8. Avoid excessively frequent refresh operations
Configure an appropriate refresh interval.
9. Design for temporary App Configuration unavailability
Use supported caching and resilience mechanisms rather than assuming the service will always be reachable.
10. Use least privilege
Grant applications only the permissions they require.
23. Important AI-200 Concepts to Remember
Concept
What to Remember
App Configuration
Centralized application settings and feature flags
Key-value
Basic configuration storage unit
Key
Identifies a configuration setting
Label
Allows different values for the same key
Feature flag
Controls feature availability
Feature filter
Determines when/for whom a feature is enabled
Managed identity
Secure application authentication to Azure resources
Key Vault
Store sensitive secrets
Key Vault reference
Connect App Configuration settings to Key Vault secrets
Dynamic configuration
Update configuration without application restart
ConfigureRefresh
Configures refresh behavior in supported providers
RegisterAll()
Monitors selected keys for changes
Sentinel key
Triggers coordinated refresh of multiple settings
Refresh interval
Controls how frequently refresh checks occur
Event Grid
Can deliver App Configuration change events
Cached configuration
Helps applications continue operating during temporary refresh failures
24. Common Exam Traps
Trap 1: “Store secrets in App Configuration”
Incorrect.
Use Key Vault for secrets.
Trap 2: “Changing a key automatically reloads every application”
Incorrect.
The application must be configured to support dynamic refresh.
Trap 3: “Use a separate key for every environment”
Not necessarily.
Labels are specifically designed to support scenarios such as:
Key = Database:Endpoint
Label = Development
Label = Test
Label = Production
Trap 4: “Use RegisterAll for coordinated multi-key changes”
It can work, but a sentinel key is often the better pattern when several settings must become active together.
Trap 5: “App Configuration replaces Key Vault”
Incorrect.
The services complement one another.
Trap 6: “Feature flags require redeployment”
Incorrect.
Feature management is specifically intended to decouple feature availability from code deployment.
Practice Exam Questions
Question 1
An AI application stores the following settings in Azure App Configuration:
AI:Model
AI:Temperature
AI:MaxTokens
The development and production environments need different values for these settings. You want to use the same key names in both environments.
What should you use?
A. Separate App Configuration stores for every key
B. Labels
C. Azure Key Vault versions
D. Feature filters
Answer: B
Explanation
Labels allow the same key to have different values depending on the environment or configuration context.
For example:
AI:Model / Development
AI:Model / Production
Feature filters are intended primarily for controlling feature availability, not general environment-specific configuration. Key Vault versions are not the mechanism for environment-specific App Configuration values.
Question 2
An Azure Function needs to retrieve application configuration from Azure App Configuration. The organization does not want credentials stored in application code.
Which authentication approach should you recommend?
A. Store the App Configuration connection string in source control
B. Use a managed identity with appropriate permissions
C. Store the credentials in an application JSON file
D. Embed a client secret directly in the Function code
Answer: B
Explanation
A managed identity allows an Azure-hosted application to authenticate to Azure resources without storing credentials in application code.
The identity should be granted the minimum permissions necessary to read the required configuration.
Question 3
An application has five configuration settings that must be changed together. The application must not reload the configuration until all five settings have been updated.
What is the best approach?
A. Restart the application after every setting change
B. Increase the size of the configuration values
C. Use a sentinel key as the refresh trigger
D. Store all five settings in a single environment variable
Answer: C
Explanation
A sentinel key is designed for this scenario. The application monitors the sentinel instead of using every individual setting as the refresh trigger.
The administrator changes the five settings and then changes the sentinel key. The sentinel change causes the application to refresh the related configuration.
Question 4
An organization needs to store an API password used by an AI application.
Which Azure service should primarily be used to store the password?
A. Azure App Configuration
B. Azure Event Grid
C. Azure Key Vault
D. Azure Service Bus
Answer: C
Explanation
Azure Key Vault is designed for securely storing secrets such as passwords, API keys, certificates, and other sensitive information.
App Configuration should primarily manage application configuration and feature flags. It can reference secrets stored in Key Vault, but it shouldn’t be treated as the primary secret store.
Question 5
A development team wants to deploy a new AI-powered search capability to production but initially make it available only to selected users.
Which App Configuration capability is most appropriate?
A. Feature flags with feature filters
B. Key Vault certificates
C. Configuration snapshots
D. Azure Service Bus topics
Answer: A
Explanation
Feature flags separate feature activation from code deployment. Feature filters can determine whether a feature is enabled for particular users, groups, or other conditions.
This makes feature flags useful for controlled rollouts and experimentation.
Question 6
An application retrieves configuration from Azure App Configuration at startup. An administrator later changes a configuration value, but the running application continues using the old value.
What is the most likely reason?
A. App Configuration keys cannot be changed
B. The application has not been configured for dynamic refresh
C. Labels prevent configuration changes
D. App Configuration only supports configuration files
Answer: B
Explanation
Loading configuration at startup does not automatically mean that a running application will monitor for configuration changes.
Dynamic refresh must be explicitly configured using the appropriate provider and refresh mechanism.
Question 7
A team wants configuration values to follow a consistent namespace such as:
AI:Model
AI:Temperature
AI:MaxTokens
Database:Endpoint
Database:Timeout
What is the primary purpose of this naming approach?
A. It creates Azure RBAC roles automatically
B. It encrypts configuration values
C. It provides a logical organization for configuration keys
D. It creates separate App Configuration stores
Answer: C
Explanation
App Configuration treats keys as strings, but developers can use delimiters such as : or / to establish logical namespaces.
This makes configuration easier to organize, query, and consume.
Question 8
An application uses the .NET App Configuration provider. Developers want the provider to check for configuration changes no more frequently than every 60 seconds.
Which configuration concept should they use?
A. A feature filter
B. A label
C. A Key Vault reference
D. A refresh interval
Answer: D
Explanation
The refresh interval controls how frequently the provider checks for configuration updates.
For example, the .NET provider supports SetRefreshInterval(...) to establish the minimum interval between refresh checks.
Question 9
A company wants to respond automatically whenever an App Configuration key-value changes. The workflow should invoke an Azure Function.
Which architecture is most appropriate?
A. App Configuration → Event Grid → Azure Function
B. App Configuration → Key Vault → Azure Function
C. App Configuration → Service Bus → Key Vault
D. App Configuration → Azure Storage → Key Vault
Answer: A
Explanation
Azure App Configuration can emit events when key-values change. Azure Event Grid can deliver those events to subscribers such as Azure Functions.
This provides an event-driven architecture without requiring the application to continuously poll for changes.
Question 10
An organization has the following requirements:
Store application settings centrally.
Store feature flags.
Store database endpoints and AI model configuration.
Store database passwords securely.
Allow applications to access resources without embedded credentials.
Which architecture best satisfies the requirements?
A. Store everything in App Configuration and use connection strings in application code
B. Store everything in Key Vault and use hard-coded credentials for access
C. Store application settings and feature flags in App Configuration, secrets in Key Vault, and use managed identities
D. Store application settings in environment variables and secrets in source control
Answer: C
Explanation
This architecture follows the intended separation of responsibilities:
Azure App Configuration → application settings and feature flags
Azure Key Vault → secrets
Managed identities → secure authentication without embedding credentials
This is the strongest option from both security and configuration-management perspectives.
Final AI-200 Exam Takeaways
For this topic, make sure you can quickly distinguish the following:
App Configuration = application configuration and feature management.
Key Vault = secrets.
Labels = different values for the same key.
Feature flags = control feature availability.
Managed identity = secure application authentication to Azure resources.
Dynamic refresh = update configuration without restarting the application.
RegisterAll() = monitor selected configuration values for changes.
Sentinel key = trigger a coordinated refresh after multiple configuration changes.
Refresh interval = control how frequently refresh checks occur.
Event Grid = react to App Configuration change events.
The most important architectural idea is that configuration should be externalized from application code, centrally managed, appropriately secured, and—when necessary—capable of being updated without requiring application redeployment or restart. Azure App Configuration is designed specifically to provide that centralized configuration layer, while Key Vault handles the sensitive secrets that applications depend on.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Secure, monitor, and troubleshoot Azure solutions (20–25%) --> Implement secure Azure solutions --> Secure secrets by using Azure Key Vault, including rotation and retrieval
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Applications frequently need credentials, API keys, connection strings, passwords, certificates, and other sensitive values to communicate with external services. Storing these values directly in source code, configuration files, or deployment scripts creates unnecessary security risk.
Azure Key Vault provides a centralized service for securely storing and managing secrets, keys, and certificates. For the AI-200 exam, developers should understand how applications authenticate to Key Vault, retrieve secrets, implement least-privilege access, and support secret rotation without unnecessarily interrupting application operations.
A particularly important principle is:
Avoid secrets whenever Azure managed identities can provide passwordless authentication.
When a secret is unavoidable, store it in Key Vault and allow the application to retrieve it securely at runtime.
1. What Is Azure Key Vault?
Azure Key Vault is a managed service designed to protect and manage sensitive information used by applications and Azure services.
Key Vault can store three major types of security objects:
Object
Primary purpose
Secrets
Passwords, API keys, connection strings, tokens, and other sensitive values
Keys
Cryptographic keys used for encryption, signing, and related cryptographic operations
Certificates
X.509 certificates and their associated lifecycle management
For AI applications, secrets might include:
Third-party API keys
Database passwords
Service credentials
Storage access credentials
Application-specific secrets
Credentials for systems that don’t support Microsoft Entra authentication
A secret should generally be treated as a value that the application needs to retrieve and use, whereas a key is often used by a cryptographic operation.
2. Why Applications Should Not Store Secrets Directly
Consider an application containing:
API_KEY = "abc123..."
Even if the value is stored in an environment variable rather than source code, it can still create security and operational problems.
Potential issues include:
Accidental exposure through source control
Exposure through configuration backups
Difficulty rotating credentials
Credentials being copied between environments
Excessive access by developers or deployment systems
Difficulty auditing access
Credentials remaining valid longer than necessary
A better architecture is:
Application
|
| Microsoft Entra authentication
v
Managed Identity
|
| authorized to read specific secret
v
Azure Key Vault
|
v
Secret value
The application doesn’t need to know a Key Vault password or store another credential simply to authenticate to Key Vault.
Microsoft recommends using managed identities for applications and services accessing Key Vault because they eliminate the need to embed credentials in the application.
3. Authentication vs. Authorization
A common AI-200 exam distinction is the difference between authentication and authorization.
Authentication
Authentication answers:
Who are you?
For example, an Azure Function can authenticate to Azure using its managed identity.
Authorization
Authorization answers:
What are you allowed to do?
After the Function has authenticated, Azure must determine whether that identity is allowed to retrieve a particular Key Vault secret.
Therefore:
Managed Identity
|
| Authentication
v
Microsoft Entra ID
|
| Authorization
v
Azure Key Vault
Both concepts are necessary.
Simply giving an application a managed identity does not automatically give it access to secrets.
The identity must also have appropriate Key Vault data-plane permissions.
4. Managed Identities
A managed identity provides an Azure-managed identity that applications can use to authenticate to services that support Microsoft Entra authentication.
There are two primary types.
System-assigned managed identity
A system-assigned identity is tied to a specific Azure resource.
For example:
Azure Function App
|
+-- System-assigned managed identity
If the Function App is deleted, its system-assigned identity is also deleted.
User-assigned managed identity
A user-assigned identity is a separate Azure resource that can be assigned to multiple Azure resources.
For example:
User-assigned identity
|
+---- Function App A
|
+---- Function App B
|
+---- Container App
This can be useful when multiple applications need to use the same identity and permissions.
For many application scenarios, either type can provide passwordless authentication to Key Vault.
5. Azure RBAC for Key Vault
Azure Key Vault supports authorization through Azure role-based access control (RBAC), as well as the older access-policy model.
For new solutions, Azure RBAC is the preferred authorization model.
Key Vault separates management operations from operations involving the actual data stored in the vault.
Control plane
The control plane manages the Key Vault resource itself.
Examples include:
Creating a vault
Deleting a vault
Configuring vault properties
Managing certain resource-level settings
Data plane
The data plane operates on the contents of the vault.
Examples include:
Reading secrets
Creating secrets
Updating secrets
Deleting secrets
Reading keys
Performing cryptographic operations
This distinction is important because an identity that can manage a Key Vault resource does not necessarily need permission to read secret values.
6. Least Privilege
Applications should receive only the permissions they actually require.
For example, suppose an application only needs to retrieve a secret.
It should not receive permissions to:
Delete secrets
Create secrets
Manage keys
Manage certificates
Change Key Vault permissions
With Azure RBAC, the Key Vault Secrets User role provides access to read secret contents. The Key Vault Secrets Officer role provides much broader permissions to manage secrets.
Exam tip
If an application only needs to read secret values, think:
Key Vault Secrets User
If an application needs to manage secrets, a broader role such as:
Key Vault Secrets Officer
may be appropriate.
Don’t automatically choose a highly privileged role simply because it makes the application work.
7. Retrieving Secrets from Key Vault
Applications should normally retrieve secrets programmatically using the Azure SDK.
A common .NET pattern uses:
SecretClient
DefaultAzureCredential
Conceptually:
Application
|
+-- DefaultAzureCredential
|
+-- SecretClient
|
v
Azure Key Vault
|
v
Secret
For example, a .NET application might use:
varcredential=newDefaultAzureCredential();
varclient=newSecretClient(
newUri(keyVaultUrl),
credential);
KeyVaultSecretsecret=
awaitclient.GetSecretAsync("MySecret");
stringvalue=secret.Value;
The important architectural point is that the application doesn’t contain a Key Vault password.
DefaultAzureCredential can use an appropriate Microsoft Entra credential depending on the environment. During local development, it can use developer credentials, while an Azure-hosted application can use its managed identity.
8. Secret Versions
Key Vault supports versioning for secrets.
Suppose an application has:
DatabasePassword
The secret might have:
DatabasePassword
├── Version 1
├── Version 2
└── Version 3
When a new value is stored, Key Vault creates a new version rather than simply overwriting the existing version in place.
This is extremely useful for rotation.
Versionless retrieval
An application can retrieve the current version of a secret by requesting the secret without specifying a version.
Conceptually:
GetSecret("DatabasePassword")
This allows the application to receive the current version.
Version-specific retrieval
An application can also request a specific version.
Conceptually:
GetSecret("DatabasePassword", "specific-version")
This can be useful when an application intentionally needs a known version.
However, hard-coding a secret version can prevent the application from automatically receiving the newest rotated credential.
9. Secret Rotation
Secret rotation means periodically replacing an existing credential with a new credential.
For example:
Old password
|
| rotation
v
New password
Regular rotation limits the amount of time a compromised credential remains useful.
Rotation is especially important for:
Database passwords
API keys
Service credentials
Application passwords
Other long-lived secrets
Azure’s guidance emphasizes minimizing secrets and rotating credentials when they are required.
10. Secret Rotation vs. Key Rotation
Don’t confuse secret rotation with cryptographic key rotation.
Azure Key Vault provides specific automatic rotation capabilities for cryptographic keys.
For secrets, rotation commonly involves an automation process that:
Generates or obtains a new credential.
Updates the target service.
Stores the new credential as a new Key Vault secret version.
Causes applications to retrieve the updated value.
Eventually invalidates the old credential.
For example:
+----------------------+
| Credential Provider |
+----------+-----------+
|
v
Generate new secret
|
+------------+------------+
| |
v v
Target service Azure Key Vault
gets new password stores new version
| |
+------------+------------+
|
v
Application
retrieves new
version
Key Vault’s automatic rotation capabilities vary by object type. For secrets, rotation commonly requires integration with the systems that use those credentials rather than simply turning on the same type of automatic key-rotation policy used for cryptographic keys.
11. Zero-Downtime Secret Rotation
A major concern with rotation is avoiding application outages.
Imagine:
Application ---> Database
password = OLD
If you immediately disable the old password before the application has started using the new password, requests can fail.
A safer approach is a coordinated rotation process.
Example
Suppose the database supports two valid credentials temporarily.
The rotation process can be:
Step 1 — Create new credential
Database:
OLD credential
NEW credential
Step 2 — Store new credential
Key Vault:
DatabasePassword
├── Version 1 = OLD
└── Version 2 = NEW
Step 3 — Application retrieves the new version
New application instances begin using the new credential.
Step 4 — Verify
Confirm that applications are successfully authenticating.
Step 5 — Revoke old credential
Only after applications have migrated should the old credential be invalidated.
This approach reduces the risk of downtime.
12. Event-Driven Secret Rotation
Polling Key Vault continuously to determine whether a secret needs to be updated is generally inefficient.
Azure Key Vault can integrate with Azure Event Grid to publish events associated with secret lifecycle changes.
Events include notifications related to:
A new secret version
A secret approaching expiration
A secret expiring
For example:
Azure Key Vault
|
| SecretNearExpiry
v
Azure Event Grid
|
v
Azure Function
|
+--> Generate new credential
|
+--> Update target service
|
+--> Store new Key Vault version
This event-driven pattern can automate credential rotation workflows.
13. Secret Expiration
Secrets can have expiration information.
An application should not assume that a secret remains valid indefinitely.
Key Vault can produce lifecycle-related events such as:
SecretNearExpiry
SecretExpired
SecretNewVersionCreated
These events can be used to trigger monitoring, notification, or automated rotation processes.
Important exam concept
A near-expiry event is not the same thing as automatic secret rotation.
The event can notify or trigger another component, such as an Azure Function, which then performs the appropriate rotation workflow.
14. Retrieving Secrets Efficiently
Applications shouldn’t necessarily call Key Vault every time they need a secret.
For example, consider an API receiving 10,000 requests per minute.
Doing this for every request:
Request
|
v
Key Vault
|
v
Secret
can create unnecessary network calls and dependency on Key Vault availability.
A better pattern is to retrieve the secret and cache it for an appropriate period.
Application
|
+-- Local/in-memory cache
|
+-- Secret available?
| |
| YES ---> use cached value
|
+-- NO ---> retrieve from Key Vault
The cache lifetime should be balanced against security requirements and rotation frequency.
A very long cache lifetime could cause the application to continue using an old credential after rotation.
Microsoft’s AI-200 training specifically emphasizes caching patterns that reduce Key Vault API calls while maintaining credential freshness.
15. Handling Rotation with Caching
Suppose:
10:00 AM -> Application retrieves Version 1
10:15 AM -> Secret is rotated to Version 2
If the application caches Version 1 for several hours, it may continue using the old credential.
Therefore, applications should have a strategy for detecting or recovering from credential changes.
Possible approaches include:
Short-lived cache
Refresh the secret periodically.
Event-driven refresh
Use an event such as SecretNewVersionCreated to initiate a refresh.
Retry and refresh
If authentication fails because a credential may have changed:
Refresh the secret from Key Vault.
Retry the operation.
Avoid repeatedly retrying a permanently invalid credential.
The appropriate strategy depends on the application’s requirements.
16. Key Vault Networking
Security isn’t limited to identity and permissions.
Key Vault access can also be restricted through network controls.
Depending on the architecture, you may use mechanisms such as:
Public network access restrictions
Firewall rules
Virtual network integration
Private endpoints
The goal is to reduce unnecessary network exposure while ensuring authorized applications can reach the vault.
A secure architecture can therefore involve multiple layers:
Application
|
| Managed Identity
v
Microsoft Entra ID
|
| Authorization
v
Azure Key Vault
|
| Network controls
v
Secret
17. Monitoring Key Vault Access
Key Vault operations can be logged.
Examples include operations such as:
Secret get
Secret update
Secret delete
Secret list
Secret version listing
These logs can help organizations determine:
Who accessed a secret
When it was accessed
What operation was performed
Whether suspicious access patterns occurred
Key Vault diagnostic logging can capture secret-related operations, including SecretGet and SecretUpdate.
For security-sensitive applications, logging and monitoring should be part of the overall secret-management strategy.
18. Common Design Pattern
A strong AI application architecture might look like this:
+----------------------+
| Azure Key Vault |
| |
| API credentials |
| DB credentials |
| Other secrets |
+----------+-----------+
^
|
Microsoft Entra ID
^
|
Managed Identity
^
|
+----------------+ +-------+-------+
| Azure Function | | Container App |
+----------------+ +---------------+
\ /
\ /
+---------------------+
AI solution
The application:
Uses a managed identity.
Authenticates through Microsoft Entra ID.
Receives authorization through Azure RBAC.
Retrieves only the secrets it needs.
Caches values appropriately.
Handles secret rotation.
Avoids exposing secret values in logs.
19. Common Mistakes to Avoid
Mistake 1: Storing secrets in source code
Avoid:
stringapiKey="secret-value";
Use Key Vault instead.
Mistake 2: Using a client secret just to access Key Vault
If the workload supports managed identity, use it rather than creating another credential that must itself be protected.
An Azure Function needs to retrieve the value of a database password stored in Azure Key Vault. The Function App has a system-assigned managed identity. The application must not store any credentials for accessing Key Vault.
What should you configure?
A. Assign the Key Vault Secrets User role to the Function App’s managed identity.
B. Store a Key Vault administrator password in the Function App settings.
C. Assign the Owner role to the Function App’s managed identity.
D. Create a client secret for the Function App and store it in Azure App Configuration.
Answer: A
Explanation: The Function’s managed identity can authenticate to Azure without storing credentials. The Key Vault Secrets User role allows the identity to read secret contents. Owner is unnecessarily privileged, and storing another credential defeats the purpose of managed identity.
Question 2
An organization wants to rotate a database password stored in Azure Key Vault. The application must continue operating while the password is changed.
Which approach provides the best zero-downtime strategy?
A. Delete the existing secret before creating the new password.
B. Disable the application’s managed identity during rotation.
C. Replace the Key Vault with Azure App Configuration.
D. Create the new credential, update the target database, store the new secret version, allow applications to transition, and revoke the old credential afterward.
Answer: D
Explanation: A coordinated rotation allows both the old and new credentials to coexist temporarily. The new credential is deployed and verified before the old credential is revoked. This reduces the likelihood of authentication failures during rotation.
Question 3
An application currently retrieves a Key Vault secret by explicitly specifying Version 4. Version 5 has now been created as part of a credential rotation. The application continues using Version 4.
What is the most likely reason?
A. Key Vault cannot contain multiple versions of a secret.
B. Azure RBAC prevents version changes.
C. The application explicitly requested Version 4 instead of retrieving the current version.
D. Managed identities can only access the first version of a secret.
Answer: C
Explanation: A version-specific request intentionally retrieves that particular version. If an application needs to follow the current secret version, it should retrieve the secret without hard-coding a specific version.
Question 4
A company wants to automatically detect when an Azure Key Vault secret is approaching expiration and start a rotation workflow.
Which service is most appropriate for detecting and routing the lifecycle event?
A. Azure Load Balancer
B. Azure DNS
C. Azure Storage Queue
D. Azure Event Grid
Answer: D
Explanation: Azure Key Vault integrates with Event Grid and can emit events associated with secret lifecycle changes, including near-expiry and expiration events. Event Grid can route those events to handlers such as Azure Functions.
Question 5
An application only needs to read the value of a secret from a Key Vault that uses the Azure RBAC permission model.
Which built-in role is the most appropriate?
A. Key Vault Secrets User
B. Owner
C. Key Vault Contributor
D. Key Vault Secrets Officer
Answer: A
Explanation: Key Vault Secrets User provides read access to secret contents. Secrets Officer is intended for managing secrets and therefore grants broader permissions than the application requires.
Question 6
An AI application makes thousands of requests per minute. Each request currently retrieves the same API key from Azure Key Vault. The API key changes infrequently.
What should the developer consider to reduce unnecessary Key Vault calls?
A. Grant the application Owner permissions.
B. Copy the API key into source code.
C. Cache the secret for an appropriate period while implementing a strategy to refresh it when necessary.
D. Disable Key Vault logging.
Answer: C
Explanation: Caching can substantially reduce unnecessary Key Vault calls. However, the cache lifetime must be selected carefully because an excessively long cache can cause the application to continue using an old secret after rotation.
Question 7
An administrator grants an application’s managed identity the Azure Key Vault Contributor role. The application still cannot retrieve a secret’s value.
What best explains this behavior?
A. Managed identities cannot access Key Vault.
B. Key Vault Contributor is a control-plane management role and does not provide access to secret contents.
C. Key Vault requires a storage account before secrets can be retrieved.
D. The application must use a user-assigned managed identity.
Answer: B
Explanation: Key Vault separates management of the vault from access to data stored within it. Key Vault Contributor allows management of the Key Vault resource but does not grant access to secret contents. A suitable data-plane role, such as Key Vault Secrets User, is required.
Question 8
A security team wants applications to authenticate to Azure Key Vault without storing usernames, passwords, client secrets, or certificates in application configuration.
Which solution should the developer use?
A. Store a service principal secret in Azure App Configuration.
B. Embed an administrator credential in the application.
C. Use a shared Key Vault access password.
D. Use an Azure managed identity with Microsoft Entra authentication.
Answer: D
Explanation: Managed identities provide Azure-managed identities that applications can use to authenticate to supported Azure services without embedding credentials in application code or configuration.
Question 9
A developer implements an automated secret-rotation process. The process receives a SecretNearExpiry event from Azure Event Grid.
What should the developer understand about this event?
A. The event itself automatically replaces the secret in every dependent system.
B. The event means the secret has already expired.
C. The event can trigger automation that performs the required rotation workflow.
D. The event permanently disables the existing secret.
Answer: C
Explanation: Event Grid provides event delivery. A receiving service, such as Azure Functions, can respond by performing the rotation workflow. A near-expiry event does not itself rotate credentials in every system.
Question 10
A developer needs to secure an AI application’s API credential stored in Azure Key Vault. The developer wants to follow least-privilege principles.
Which design is best?
A. Give the application’s managed identity Owner access to the subscription.
B. Store the API key in the application’s source code and restrict repository access.
C. Give the application’s managed identity Key Vault Secrets Officer permissions even though it only reads the secret.
D. Give the application’s managed identity only the Key Vault data-plane permissions required to retrieve the secret.
Answer: D
Explanation: Least privilege means granting only the permissions necessary for the workload. If the application only needs to retrieve a secret, it should receive a read-oriented Key Vault role rather than Owner or a broader secret-management role.
Final Study Summary
For “Secure secrets by using Azure Key Vault, including rotation and retrieval,” focus especially on these exam relationships:
A particularly important exam distinction is that storing a new secret version does not automatically mean every application has switched to the new credential. Applications and the systems they connect to must be designed to recognize and safely adopt rotated credentials.
Likewise, Event Grid can notify or trigger a rotation workflow, but it isn’t itself the complete rotation mechanism. A Function, automation process, or other handler may need to update the target resource and Key Vault.
Finally, favor managed identities and least-privilege Azure RBAC over embedded credentials and excessive permissions. These patterns reduce secret exposure and make AI workloads easier to operate securely.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Connect to and consume Azure services (20–25%) --> Develop and implement Azure Functions --> Configure and deploy function apps
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Azure Functions is a serverless compute service that enables developers to execute application code in response to events without managing the underlying server infrastructure.
For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how to configure and deploy function apps, including:
Function app hosting plans
Function app configuration
Application settings
Runtime and operating-system configuration
Deployment methods
Zip deployment
Running functions from deployment packages
Deployment slots
Flex Consumption deployment
Continuous deployment
Configuration considerations for production
Common deployment problems and troubleshooting
The key exam skill is not simply knowing how to create a function app. You need to understand why you would choose a particular hosting or deployment approach for a given scenario.
1. What Is an Azure Function App?
An Azure Function is a piece of code that executes in response to a trigger.
A function app is the Azure resource that provides the execution environment for one or more functions.
For example, an AI application might contain functions that:
Receive an HTTP request.
Process a message from Azure Service Bus.
Respond to an Event Grid event.
Read a file uploaded to Azure Blob Storage.
Process a timer event.
Write results to a database.
The function app provides the common configuration and hosting environment for these functions.
Conceptually:
Azure Function App
|
+----------------+----------------+
| | |
HTTP Function Queue Function Timer Function
| | |
REST API AI Processing Scheduled Job
Functions within the same function app generally share:
Runtime configuration
Application settings
Deployment configuration
Hosting resources
Some networking configuration
Monitoring configuration
Authentication configuration
Therefore, functions that have significantly different configuration or scaling requirements may be better placed in separate function apps.
2. Function App Hosting Plans
One of the most important concepts for AI-200 is understanding that the hosting plan affects scaling, cost, networking, deployment, and available features.
Current Azure Functions hosting options include:
Consumption
Flex Consumption
Elastic Premium
Dedicated/App Service
Azure Container Apps
The exact capabilities differ between plans.
Consumption Plan
The traditional Consumption plan is designed around serverless execution.
You generally pay based on function execution and resource consumption rather than maintaining dedicated compute capacity.
Characteristics include:
Automatic scaling
Serverless execution model
Consumption-based pricing
Potential cold starts
Limited control compared with Premium or Dedicated plans
The traditional Consumption plan should not be confused with Flex Consumption, which is the newer serverless option.
3. Flex Consumption
Flex Consumption is a newer Azure Functions hosting plan and is particularly important for current Azure development.
It is:
Linux-based
Serverless
Dynamically scalable
Consumption-based
Designed to provide more configuration flexibility than the traditional Consumption plan
Microsoft currently describes Flex Consumption as the recommended serverless hosting plan for Azure Functions.
Flex Consumption provides capabilities such as:
Configurable instance memory
Fast or large-scale-out options
Private networking
Always-ready instances for reducing cold starts
Support for deployment packages
Rolling updates for zero-downtime deployments
One particularly important exam distinction is that Flex Consumption uses a different deployment model from traditional Consumption.
Flex Consumption uses One Deploy as its deployment technology.
Important distinction
Do not assume:
“Zip deployment is the standard deployment method for every Functions hosting plan.”
That is no longer correct.
For example:
Hosting plan
Deployment approach
Flex Consumption
One Deploy
Consumption
Zip deploy and other supported methods
Elastic Premium
Zip deploy and other supported methods
Dedicated
Zip deploy and other supported methods
Container Apps
Container-based deployment
4. Elastic Premium Plan
The Elastic Premium plan provides more control and capabilities than Consumption-based hosting.
It is useful when applications require features such as:
More predictable performance
Larger compute resources
VNet integration
Reduced cold-start impact
Longer-running workloads
More control over scaling
Premium plans also support deployment slots.
This can be useful when deploying AI applications where a new version needs to be tested before being exposed to production users.
5. Dedicated/App Service Plan
A Function App can also run on a dedicated App Service plan.
In this model, the application runs on dedicated App Service compute.
This can be appropriate when:
You already have App Service infrastructure.
Predictable compute capacity is required.
You want to run functions alongside other App Service workloads.
The workload does not fit the serverless consumption model.
The tradeoff is that you are paying for allocated compute capacity rather than relying exclusively on consumption-based serverless execution.
6. Azure Container Apps
Azure Functions can also be hosted in Azure Container Apps.
This approach is particularly useful when:
You want containerized Functions.
You need container-specific capabilities.
You want Azure Container Apps scaling and infrastructure.
Your application architecture already uses containers.
This is different from simply deploying function source code to a normal Function App.
7. Choosing the Hosting Plan
For the exam, think in terms of requirements.
Requirement
Likely consideration
Serverless execution
Consumption or Flex Consumption
Modern recommended serverless option
Flex Consumption
Private networking with serverless model
Flex Consumption
Reduce cold starts
Flex Consumption/Premium
Predictable dedicated compute
Dedicated
Advanced scaling/performance
Premium
Containerized Functions
Azure Container Apps
Deployment slots
Consumption, Premium, Dedicated
Zero-downtime Flex deployment
Rolling updates
Test deployment before production
Deployment slots where supported
The exam may give you a scenario and ask you to select the most appropriate hosting model.
8. Function App Configuration
After selecting the hosting environment, you need to configure the function app.
Important configuration areas include:
Runtime
Operating system
Application settings
Connection strings
Authentication
Networking
Storage
Monitoring
Deployment configuration
The configuration determines how the Functions runtime executes your code and accesses external services.
9. Application Settings
Application settings are environment variables made available to your function application.
They are commonly used for configuration such as:
FUNCTIONS_WORKER_RUNTIME
AzureWebJobsStorage
APPLICATIONINSIGHTS_CONNECTION_STRING
SERVICE_BUS_CONNECTION
DATABASE_CONNECTION
OPENAI_ENDPOINT
For example, an application might use:
SERVICE_BUS_CONNECTION
instead of embedding a Service Bus connection string directly in source code.
The application reads the setting at runtime.
This allows the same application code to be deployed into different environments:
Development
|
v
SERVICE_BUS_CONNECTION = Dev connection
Test
|
v
SERVICE_BUS_CONNECTION = Test connection
Production
|
v
SERVICE_BUS_CONNECTION = Production connection
This is a fundamental cloud-development practice.
10. Never Hard-Code Secrets
A common mistake is placing credentials directly into source code.
Instead, use configuration and preferably a secure secret-management solution such as Azure Key Vault.
For example:
Function App
|
v
Managed Identity
|
v
Azure Key Vault
|
v
Secret
This allows the code to remain unchanged when credentials change.
11. Function App Settings and Restarts
Changes to function app settings can cause the application to restart.
This matters in production environments.
If an application setting is changed, developers should understand that the change isn’t necessarily a completely isolated configuration update with no runtime impact.
For production applications, configuration changes should therefore be managed carefully.
12. Runtime Configuration
A Function App must use a compatible Functions runtime and language stack.
Examples include:
.NET
Java
JavaScript/Node.js
Python
PowerShell
The runtime configuration must match the application being deployed.
For example, a Python function app should not be configured as a .NET runtime application.
13. The host.json File
The host.json file contains configuration settings that apply to the entire function app.
Examples of configuration areas include:
Logging
Extension behavior
Retry policies
Concurrency
Durable Functions behavior
HTTP configuration
A simplified example:
{
"version":"2.0",
"logging":{
"applicationInsights":{
"samplingSettings":{
"isEnabled":true
}
}
}
}
The host.json file is different from application settings.
host.json
Controls Functions host behavior.
Application settings
Provide environment-specific configuration and values to the application.
Not every method is supported for every hosting plan.
15. Zip Deployment
Zip deployment packages the function app into a .zip file and deploys it to Azure.
For Consumption, Elastic Premium, and Dedicated plans, zip deployment is the default and recommended deployment technology.
For example:
Function Project
|
v
Build
|
v
function.zip
|
v
Azure Function App
A ZIP package must contain the application files in the expected structure.
One important requirement is that host.json must be located at the root of the package.
Incorrect:
function.zip
|
+-- my-function-project
|
+-- host.json
Correct:
function.zip
|
+-- host.json
+-- Function1
+-- Function2
+-- requirements.txt
If the parent project directory is accidentally included, Azure Functions may not find the expected files.
16. Deploying with Azure CLI
For supported hosting plans, Azure CLI can be used to perform ZIP deployment.
A typical command is:
az functionapp deployment source config-zip \
-g <resource-group> \
-n <function-app-name> \
--src <zip-file>
This uploads the ZIP package to the Function App.
The important exam concept is not memorizing every CLI parameter.
Instead, recognize:
config-zip is associated with ZIP deployment for supported Function App hosting plans.
17. Run From Package
Azure Functions can also run directly from a deployment package instead of extracting the application files into the normal application directory.
For supported plans, this can be enabled with:
WEBSITE_RUN_FROM_PACKAGE=1
When enabled, the deployment package is mounted as a read-only filesystem.
Advantages include:
Reduced file-copy problems
More predictable deployments
Improved deployment performance
Verification of the exact package being executed
Reduced cold-start impact in some scenarios
18. Important Flex Consumption Deployment Difference
One of the most important current exam distinctions is:
Flex Consumption does not use traditional Zip Deploy.
Flex Consumption uses One Deploy.
With One Deploy, the application is packaged and uploaded to a deployment storage container. The Function App retrieves the package and runs the application from it.
Therefore:
Scenario:
You create a new Function App using the Flex Consumption plan. You want to deploy the application using the supported deployment mechanism.
The appropriate answer should point toward:
One Deploy, rather than traditional Zip Deploy.
19. Deployment Slots
Deployment slots allow supported Function Apps to have multiple environments associated with the same application.
For example:
Function App
|
+-- Production
|
+-- Staging
You can deploy a new version to the staging slot, test it, and then swap it with production.
The general process is:
Development
|
v
Staging Slot
|
Test
|
v
Swap
|
v
Production
This reduces the risk of deploying an untested version directly to production.
20. Deployment Slots and Hosting Plans
Deployment slots are not available on every hosting model.
Current slot support includes:
Hosting option
Deployment slots
Consumption
Production + 1 slot
Flex Consumption
Not currently supported
Premium
Production + multiple slots
Dedicated
Production + multiple slots
Container Apps
Uses revisions rather than Functions deployment slots
This is an excellent area for scenario-based exam questions.
Example
A developer wants to deploy a new version to staging and swap it into production. The Function App uses Flex Consumption.
The traditional deployment-slot solution is not available.
Flex Consumption instead supports zero-downtime deployment through its site update strategies, including rolling updates.
21. Continuous Deployment
For production applications, deployment is often automated through CI/CD.
A typical pipeline looks like:
Developer
|
v
Source Repository
|
v
Build
|
v
Automated Tests
|
v
Package
|
v
Azure Function App
Possible tools include:
GitHub Actions
Azure Pipelines
Azure CLI
Azure Functions Core Tools
Visual Studio Code
Infrastructure-as-code tools
The goal is to make deployments:
Repeatable
Automated
Testable
Auditable
Consistent
22. Development vs. Production Deployment
The deployment method should reflect the environment.
Development
A developer may deploy directly from:
Visual Studio Code
Azure Functions Core Tools
Azure CLI
This is convenient for rapid development.
Production
Production deployments should generally use an automated CI/CD process.
A production pipeline might:
Build the application.
Install dependencies.
Run unit tests.
Run security checks.
Package the application.
Deploy to a staging environment.
Run validation tests.
Promote the application to production.
23. Configuration by Environment
A common architecture is to keep application code identical across environments while changing configuration.
For example:
Same Code
|
+------------+------------+
| | |
v v v
Development Test Production
| | |
v v v
Dev settings Test settings Prod settings
This is preferable to maintaining three separate codebases.
Environment-specific values should be supplied through:
Application settings
Key Vault
Managed identity
App Configuration
CI/CD variables
24. Infrastructure as Code
Function Apps can also be deployed using infrastructure-as-code technologies such as:
Bicep
ARM templates
Terraform
This allows the application infrastructure to be described declaratively.
For example:
Infrastructure Definition
|
v
Resource Group
|
+-----+-----+
| |
v v
Function App Storage
|
v
Application Insights
Infrastructure as code is especially useful when deploying consistent development, test, and production environments.
25. Function App Storage
Azure Functions generally requires an associated storage account for runtime operations.
The storage account may be used for Functions platform requirements such as:
Host state
Trigger management
Function keys
Other runtime-related data
The exact storage requirements vary depending on the hosting model.
This is especially important when designing secure or network-restricted applications.
26. Monitoring Configuration
Production Function Apps should generally be integrated with Application Insights/Azure Monitor.
Monitoring can provide information about:
Requests
Exceptions
Dependencies
Performance
Traces
Availability
Failures
An application can then be diagnosed using telemetry rather than relying exclusively on application output.
For an AI application, this can be particularly valuable.
For example:
HTTP Request
|
v
Azure Function
|
+----> Azure OpenAI
|
+----> Cosmos DB
|
+----> Service Bus
|
v
Application Insights
Telemetry can help identify whether a slow request is caused by the function itself or by a downstream dependency.
27. Networking Considerations
Function Apps may need to communicate with resources that are not publicly accessible.
Examples include:
Azure SQL
Azure Database for PostgreSQL
Azure Storage
Azure Key Vault
Cosmos DB
Internal APIs
Depending on the hosting plan and architecture, networking features such as VNet integration and private endpoints can be used.
This is one reason hosting-plan selection matters.
A requirement such as:
“The serverless application must access resources through a private network.”
should cause you to carefully consider whether the selected hosting plan supports the required networking capabilities.
Understanding deployment failures is useful for both real-world development and AI-200.
Problem 1: Incorrect ZIP structure
The package does not contain host.json at the root.
Result: Functions may not be discovered correctly.
Solution: Package the contents of the application directory rather than the parent directory.
Problem 2: Incorrect runtime
The Function App is configured for a different runtime than the deployed application.
Result: Functions may fail to start.
Solution: Verify the runtime and language stack.
Problem 3: Missing application setting
The function expects:
SERVICE_BUS_CONNECTION
but the setting isn’t configured.
Result: The function cannot connect to Service Bus.
Solution: Configure the required application setting or use a managed identity-based connection.
Problem 4: Deployment method incompatible with hosting plan
For example, attempting to use traditional Zip Deploy on Flex Consumption.
Result: The deployment approach isn’t supported.
Solution: Use the deployment technology appropriate for the hosting plan—One Deploy for Flex Consumption.
Problem 5: Expecting deployment slots on Flex Consumption
Flex Consumption currently does not support traditional deployment slots.
Solution: Use supported Flex Consumption site update strategies for zero-downtime deployment.
29. Key AI-200 Exam Distinctions
Memorize these concepts rather than isolated commands.
Function App vs. Function
Function
A unit of code triggered by an event.
Function App
The hosting and configuration environment for functions.
host.json vs. Application Settings
host.json
Controls Functions host behavior.
Application settings
Provide configuration and environment-specific values to the application.
Consumption vs. Flex Consumption
Consumption
Traditional serverless hosting option.
Flex Consumption
Modern serverless hosting option with additional configuration and networking capabilities.
Zip Deploy vs. One Deploy
Zip Deploy
Used with Consumption, Premium, and Dedicated plans.
One Deploy
The deployment technology for Flex Consumption.
Deployment Slots vs. Flex Rolling Updates
Deployment slots
Useful for supported hosting plans when you want to stage and swap deployments.
Flex Consumption
Doesn’t currently support deployment slots; use supported site update strategies such as rolling updates for zero-downtime deployments.
30. AI-200 Study Checklist
Before considering this topic mastered, make sure you can answer the following:
What is a Function App?
How does a Function differ from a Function App?
What are the major Azure Functions hosting plans?
What is the difference between Consumption and Flex Consumption?
Why would you choose Premium?
When would Dedicated hosting make sense?
What is host.json used for?
What are application settings?
Why shouldn’t secrets be hard-coded?
What is Zip Deploy?
What is One Deploy?
Which hosting plan requires One Deploy?
What does WEBSITE_RUN_FROM_PACKAGE do?
What are deployment slots?
Which plans support deployment slots?
What is the alternative to deployment slots in Flex Consumption?
How should production deployments be automated?
Why is CI/CD preferable for production?
How does Application Insights help troubleshoot Function Apps?
What are common deployment failures?
Practice Exam Questions
Question 1
A development team is creating a new Azure Function App using the Flex Consumption hosting plan. The team needs to deploy the application using the deployment technology supported by this hosting plan.
Which deployment technology should the team use?
A. Zip Deploy B. FTP deployment C. One Deploy D. Local Git
Answer: C
Explanation: Flex Consumption uses One Deploy as its deployment technology. Traditional Zip Deploy, FTP, and Local Git aren’t the deployment mechanism for Flex Consumption. One Deploy packages the application and stores the deployment package in the configured deployment storage.
Question 2
A Function App is configured with the following application setting:
SERVICEBUS_CONNECTION
The application uses this setting to obtain the connection information required to communicate with Azure Service Bus.
What is the primary purpose of an application setting in this scenario?
A. To define the Functions host version B. To provide configuration values to the application at runtime C. To define the HTTP trigger schema D. To control the number of function instances
Answer: B
Explanation: Application settings provide configuration values to the Function App and its code. They are commonly used for environment-specific configuration such as endpoints, connection information, and other runtime values. host.json, rather than an application setting, is used for many Functions host-level behaviors.
Question 3
A company deploys an Azure Function App to a supported hosting plan. Developers want to test a new version of the application before making it the production version. They want to deploy the new version separately and then swap it into production.
Which feature should they use?
A. Azure Event Grid B. Function keys C. Deployment slots D. Application settings
Answer: C
Explanation: Deployment slots allow supported Function Apps to run separate application instances such as staging and production. Developers can deploy and test the application in a staging slot and then swap the slot into production. Flex Consumption currently does not support traditional deployment slots.
Question 4
A developer creates a ZIP package for an Azure Function App. The ZIP file has this structure:
functionapp.zip
|
+-- MyFunctionProject
|
+-- host.json
+-- Function1
+-- Function2
The deployment succeeds, but Azure Functions cannot correctly locate the application files.
What is the most likely problem?
A. The ZIP package is too small B. The Function App requires a deployment slot C.host.json must be configured as an application setting D.host.json isn’t located at the root of the deployment package
Answer: D
Explanation: For ZIP deployment, host.json must be at the root of the extracted package. The common mistake is including the parent project directory inside the ZIP. The package should contain the application files directly at its root.
Question 5
A production Function App runs on a Consumption, Premium, or Dedicated plan. The development team wants to deploy the application as a ZIP package.
Which deployment technology should they generally use?
A. Zip Deploy B. One Deploy C. FTP only D. Docker Compose
Answer: A
Explanation: Zip Deploy is the default and recommended deployment technology for Function Apps running on Consumption, Elastic Premium, and Dedicated plans. Flex Consumption is the important exception because it uses One Deploy.
Question 6
An organization wants to run an Azure Functions application using a serverless hosting model. The application requires private networking capabilities and the organization wants to use a modern serverless Functions hosting option.
Which hosting plan is the best fit?
A. Dedicated App Service only B. Flex Consumption C. Classic Windows-only Consumption D. Local development hosting
Answer: B
Explanation: Flex Consumption is a Linux-based serverless hosting plan that provides additional capabilities such as private networking, configurable instance memory, and scaling options. It is currently Microsoft’s recommended serverless hosting plan for Azure Functions.
Question 7
A developer wants an Azure Function App to execute directly from a deployment package rather than copying the package contents into the normal application directory.
Which application setting is associated with running functions from a package for supported hosting plans?
Explanation: WEBSITE_RUN_FROM_PACKAGE is used to configure supported Function Apps to run from a deployment package. When configured appropriately, the package is mounted as a read-only filesystem. Flex Consumption runs from a package by default and uses its own deployment model.
Question 8
A company has a Function App running on Flex Consumption. The development team wants to use the traditional deployment-slot model to deploy a staging version and then swap it into production.
What should the team do?
A. Create a second deployment slot B. Enable FTP deployment C. Convert the app to a Consumption plan automatically D. Use a supported Flex Consumption site update strategy instead
Answer: D
Explanation: Traditional deployment slots are not currently supported on Flex Consumption. Flex Consumption instead provides site update strategies, including rolling updates, for scenarios requiring zero-downtime deployments.
Question 9
A production Function App needs to access a database. The developer proposes putting the database password directly into the function’s source code.
Which approach is most appropriate?
A. Store the password in source control B. Store the secret in Azure Key Vault and provide secure access through configuration or managed identity C. Put the password in host.json D. Store the password in the function name
Answer: B
Explanation: Secrets should not be hard-coded into application source code or committed to source control. Azure Key Vault combined with managed identity is a strong approach for securely retrieving secrets. Application configuration can then provide non-secret configuration and references as appropriate.
Question 10
A development team is creating a production deployment pipeline for an Azure Function App. The team wants deployments to be repeatable and automatically tested before production deployment.
Which approach is most appropriate?
A. Manually upload files through the Azure portal for every release B. Edit the production Function App directly in the portal C. Use a CI/CD pipeline that builds, tests, packages, and deploys the Function App D. Store production code only on the developer’s workstation
Answer: C
Explanation: A CI/CD pipeline provides repeatable and automated deployment. A typical pipeline can build the application, run tests, package the application, deploy it to an appropriate environment, validate it, and promote it to production. This is much more reliable and auditable than manual production deployments.
Final Exam Takeaways
For AI-200 – Configure and deploy function apps, concentrate especially on the distinctions between hosting plans, configuration, and deployment technologies.
The highest-value concepts to remember are:
A Function App provides the hosting environment for one or more functions.
The hosting plan affects cost, scaling, networking, and deployment capabilities.
Flex Consumption is the modern serverless Functions hosting option and is currently the recommended serverless plan.
Flex Consumption uses One Deploy rather than traditional Zip Deploy.
Zip Deploy is the recommended deployment technology for Consumption, Elastic Premium, and Dedicated plans.
host.json controls Functions host behavior.
Application settings provide runtime/environment configuration.
Secrets should not be hard-coded into function code.
Deployment slots allow supported hosting plans to stage and swap releases.
Flex Consumption doesn’t currently support deployment slots.
Flex Consumption can use rolling updates for zero-downtime deployments.
WEBSITE_RUN_FROM_PACKAGE allows supported Function Apps to execute from a deployment package.
ZIP packages must have host.json at the package root.
CI/CD is the preferred approach for repeatable production deployments.
Application Insights/Azure Monitor should be part of a production observability strategy.
These distinctions are particularly important because AI-200 scenario questions are likely to test which Azure Functions configuration or deployment approach best satisfies a set of requirements, rather than simply asking you to recall definitions.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Connect to and consume Azure services (20–25%) --> Develop and implement Azure Functions --> Build serverless APIs, including implementing triggers and bindings
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Azure Functions is a serverless compute service that allows developers to execute code in response to events without managing the underlying servers. For AI-enabled applications, Azure Functions can provide lightweight, scalable APIs and backend processing components that connect AI workloads to databases, messaging services, storage, and other Azure services.
For the AI-200 exam, an important area is understanding how to build serverless APIs using Azure Functions, particularly how triggers and bindings work together.
The key concepts include:
HTTP triggers
HTTP output bindings
Function routes
Authorization levels
Input bindings
Output bindings
Binding expressions
Multiple bindings
Trigger versus binding
Stateless serverless API design
Connecting Functions to other Azure services
Appropriate use of HTTP-triggered Functions
1. What Is Azure Functions?
Azure Functions is an event-driven serverless compute platform.
Instead of provisioning and maintaining virtual machines or application servers, you deploy individual functions that execute when an event occurs.
A function can be triggered by events such as:
HTTP requests
Azure Storage queue messages
Blob changes
Service Bus messages
Event Grid events
Event Hubs events
Timer schedules
For example, an AI application might expose an HTTP endpoint:
POST /api/summarize
The request could contain a document that needs to be summarized.
The HTTP-triggered Function could:
Receive the request.
Validate the input.
Call an Azure AI service.
Store the result in a database.
Return the generated summary.
This allows the application to implement an API without maintaining a dedicated web server.
2. What Is a Trigger?
A trigger defines how a function is invoked.
Every Azure Function must have exactly one trigger.
For example:
HTTP request
|
v
HTTP trigger
|
v
Azure Function
The trigger provides the initial event or data that causes the function to execute.
Common triggers include:
Trigger
Function executes when…
HTTP
An HTTP request is received
Timer
A scheduled time is reached
Blob
A blob-related event occurs
Queue
A queue message is available
Service Bus
A Service Bus message is available
Event Grid
An Event Grid event is received
Event Hubs
Events arrive in an Event Hub
For serverless APIs, the HTTP trigger is particularly important.
3. What Is an HTTP Trigger?
An HTTP trigger allows an Azure Function to execute when an HTTP request is received.
This makes HTTP-triggered Functions particularly useful for building:
REST APIs
Webhooks
Backend endpoints
AI inference APIs
Data-processing APIs
Lightweight microservices
For example:
Client
|
| POST /api/analyze
v
Azure Function
|
+----> Azure AI service
|
+----> Database
|
v
HTTP response
The HTTP trigger can respond to specific HTTP methods such as:
GET
POST
PUT
PATCH
DELETE
The supported methods are configured as part of the HTTP trigger.
4. HTTP Trigger Versus HTTP Output Binding
One of the most important concepts for the exam is distinguishing the trigger from the output binding.
The HTTP trigger receives the request:
HTTP request
|
v
HTTP trigger
The HTTP output sends the response:
Function
|
v
HTTP output
|
v
HTTP response
Therefore:
HTTP trigger = how the function is invoked
HTTP output = how the function sends an HTTP response
In most Azure Functions programming models, the function’s return value can be used to produce the HTTP response.
5. HTTP Routes
An HTTP-triggered Function has a URL endpoint.
By default, the route generally follows this pattern:
Route parameters are particularly useful when designing REST-style APIs.
6. HTTP Methods
An API endpoint should normally expose only the HTTP methods it actually needs.
For example:
GET /api/products/{id}
POST /api/products
PUT /api/products/{id}
DELETE /api/products/{id}
A Function can be configured to respond to specific methods.
This allows a single Function endpoint to implement appropriate REST operations.
For example:
GET /api/orders/123
could retrieve an order, while:
POST /api/orders
could create an order.
Exam tip: Don’t confuse the HTTP method with the trigger. The HTTP trigger causes the Function to execute; the configured HTTP methods determine which types of requests the endpoint accepts.
7. Authorization Levels
HTTP-triggered Functions can use authorization levels to control who can invoke the function.
Common authorization levels include:
Anonymous
No Function key is required.
Useful for:
Public endpoints
Public webhooks
APIs where authentication is handled elsewhere
However, anonymous does not mean that the endpoint should necessarily be considered secure. If sensitive operations are exposed, authentication and authorization should be implemented appropriately.
Function
A Function key is required.
This provides a simple mechanism for restricting invocation of the Function.
Admin
An administrative key is required.
This provides a higher level of access and should be used carefully.
Exam consideration: If a question asks for an HTTP endpoint that should require a Function key, Function authorization is the relevant setting.
8. What Are Bindings?
Bindings provide a declarative way for Azure Functions to connect to other services.
There are two primary types:
Input bindings
Output bindings
Bindings allow developers to avoid writing all of the connection and resource-management code themselves.
For example, instead of manually creating an Azure Storage client, authenticating to Storage, and retrieving a blob, a Function can use a blob input binding.
Conceptually:
Function
|
+---- Input binding ----> Azure Storage
|
+---- Output binding ---> Database
Bindings are optional.
A Function can have:
A trigger only
A trigger + input binding
A trigger + output binding
A trigger + multiple input/output bindings
9. Trigger Versus Input Binding
A trigger and an input binding are related but serve different purposes.
Trigger
Determines when the function executes.
Input binding
Provides additional data to the function.
For example:
HTTP request
|
v
HTTP trigger
|
v
Function
|
+---- Blob input binding
| |
| v
| Blob data
The HTTP request causes the Function to execute.
The blob input binding provides additional data.
10. Output Bindings
An output binding allows a Function to write data to another service.
For example, an HTTP Function could receive a request and write the result to Azure Storage.
HTTP request
|
v
Function
|
+----> Storage output binding
Another example:
HTTP request
|
v
AI processing Function
|
+----> Cosmos DB
|
+----> HTTP response
Output bindings can simplify integration with supported Azure services.
11. Multiple Bindings
A Function can use multiple bindings.
For example, an AI API might:
Receive an HTTP request.
Read customer information from Cosmos DB.
Call an AI service.
Write the result to Blob Storage.
Return an HTTP response.
Conceptually:
+--> Cosmos DB input
|
HTTP request ---> Function ---> Blob Storage output
|
+--> HTTP response
The Function still has only one trigger, but it can have multiple additional bindings.
12. Binding Expressions
Binding expressions allow information from one binding to be used dynamically by another binding.
For example, suppose a queue message contains:
customer123
A binding expression could use that value to determine which resource should be accessed.
Conceptually:
Queue message
|
| customer123
v
Queue trigger
|
v
Binding expression
|
v
Customer-specific resource
This can reduce hardcoded configuration and make Functions more flexible.
Binding expressions commonly use curly-brace syntax such as:
{parameter}
13. Application Settings and Connection Information
Bindings commonly reference configuration values through application settings.
For example:
MyStorageConnection
could identify an application setting containing the connection information required by a storage binding.
This is preferable to hardcoding connection strings directly into source code.
For example, avoid:
connectionString = "DefaultEndpointsProtocol=..."
Instead, reference configuration:
connection = "MyStorageConnection"
The actual configuration can then be supplied through the Function App’s settings.
For production workloads, secrets should be managed securely, commonly using Azure Key Vault and managed identities where appropriate.
14. Building a Serverless API
A typical serverless API using Azure Functions can follow this architecture:
Client
|
| HTTPS
v
HTTP Trigger
|
v
Azure Function
/ | \
/ | \
v v v
Cosmos DB Azure AI Service Bus
| | |
+----------+-----------+
|
v
HTTP Response
The Function acts as the lightweight API layer.
This architecture is particularly useful for AI applications because the Function can coordinate several backend services without requiring a traditional application server.
15. Example: AI Inference API
Consider an AI application that exposes:
POST /api/analyze
The request contains:
{
"text":"Customer feedback..."
}
The Function could:
Receive the HTTP request.
Parse the JSON.
Validate the input.
Send the text to an AI service.
Store the result.
Return JSON to the client.
The response might look like:
{
"sentiment":"positive",
"confidence":0.94
}
The Function therefore acts as an API façade around the AI processing workflow.
16. Choosing Between HTTP Triggers and Other Triggers
The trigger should match how the workload is initiated.
Use an HTTP trigger when:
A client needs to call an API.
A web application needs an endpoint.
A webhook needs to invoke the Function.
An application needs synchronous request/response behavior.
Use a queue or messaging trigger when:
Work should be processed asynchronously.
Requests may arrive faster than they can be processed.
You need decoupling between components.
Long-running processing should not block an HTTP request.
For example:
HTTP API
|
v
Service Bus
|
v
Function
|
v
AI processing
may be preferable to:
HTTP API
|
v
AI processing
|
v
HTTP response
when AI processing could take significant time.
17. Synchronous Versus Asynchronous APIs
This distinction is important when designing serverless AI applications.
Synchronous
The client waits for the Function to complete.
Client
|
| Request
v
Function
|
| Process
v
Client receives response
This works well when processing is relatively quick.
Asynchronous
The API accepts the request and places work into a messaging system.
Client
|
v
HTTP Function
|
v
Service Bus
|
v
Processing Function
|
v
AI workload
The client doesn’t have to wait for the complete operation.
This architecture can improve resilience and scalability.
18. HTTP Function Response Codes
A well-designed API should return appropriate HTTP status codes.
Common examples include:
Status
Meaning
Example
200
OK
Successful GET
201
Created
Resource created
202
Accepted
Asynchronous processing accepted
204
No Content
Successful request with no response body
400
Bad Request
Invalid input
401
Unauthorized
Authentication required
403
Forbidden
Access denied
404
Not Found
Resource doesn’t exist
409
Conflict
Resource conflict
500
Internal Server Error
Unexpected server failure
For example, if an API accepts an AI processing request and queues it for asynchronous processing, a 202 Accepted response may be appropriate.
19. Error Handling
Serverless APIs should explicitly handle expected errors.
For example:
Request
|
v
Validate input
|
+---- Invalid ---> 400 Bad Request
|
v
Process request
|
+---- Resource missing ---> 404
|
+---- Unexpected failure -> 500
|
v
200 OK
Don’t expose sensitive internal information in error responses.
For example, avoid returning:
SQL connection string:
Server=...
Password=...
or detailed internal stack traces to clients.
20. Connection Management
An important practical consideration when developing HTTP-triggered Azure Functions is connection management.
Creating a new HTTP client or network connection for every Function invocation can lead to connection exhaustion and degraded performance.
Applications should use appropriate connection reuse patterns rather than repeatedly creating unmanaged HTTP clients.
This becomes particularly important for Functions that call:
Azure AI services
REST APIs
Databases
Storage
Other backend services
21. Serverless API Design Best Practices
Keep Functions focused
A Function should ideally have a clear responsibility.
Avoid creating one enormous Function that:
Validates requests
Performs database operations
Calls multiple AI models
Sends emails
Processes files
Publishes events
Performs unrelated business logic
Smaller, focused Functions are generally easier to test and maintain.
Use configuration instead of hardcoding
Store environment-specific configuration outside application code.
Protect sensitive APIs
Use appropriate authentication and authorization.
Validate requests
Don’t assume that incoming JSON is valid.
Return appropriate status codes
Use HTTP semantics consistently.
Design for retries
Backend services may retry operations. Functions should avoid unintended duplicate side effects.
Avoid unnecessary synchronous processing
If an operation can take a long time, consider an asynchronous architecture using messaging.
Reuse connections
Avoid connection exhaustion caused by creating network clients unnecessarily.
22. Important AI-200 Exam Distinctions
The following distinctions are especially important to remember.
Concept
What it does
Trigger
Causes the Function to execute
HTTP trigger
Executes the Function when an HTTP request arrives
Input binding
Provides additional data to the Function
Output binding
Writes Function output to another resource
HTTP output
Sends an HTTP response
Route
Defines the HTTP endpoint pattern
Authorization level
Controls Function-level invocation authorization
Binding expression
Dynamically resolves binding values
Application setting
Stores configuration used by the application/bindings
A particularly important exam rule is:
A Function has exactly one trigger, but it can have multiple input and output bindings.
23. Key Takeaways
For the AI-200 exam, remember these points:
Azure Functions provides serverless compute.
A trigger determines when a Function runs.
Every Function has exactly one trigger.
HTTP triggers are used to create serverless APIs and receive webhooks.
HTTP output provides the response to an HTTP-triggered request.
Input bindings provide additional data to a Function.
Output bindings allow a Function to write to supported services.
A Function can have multiple input and output bindings.
Binding expressions allow dynamic values to flow between bindings.
Application settings should be used for configuration rather than hardcoding secrets.
HTTP methods and routes define how an HTTP API endpoint behaves.
Asynchronous workloads can use messaging services rather than keeping HTTP requests open.
Appropriate HTTP status codes should communicate success and failure conditions.
Connection reuse is important for high-throughput HTTP Functions.
For production applications, authentication, authorization, secure configuration, validation, and error handling are essential.
Practice Exam Questions
Question 1
A developer is building a serverless API that should execute whenever a client sends an HTTP POST request. Which Azure Functions feature should the developer use to initiate the Function?
A. HTTP trigger B. HTTP output binding C. Queue output binding D. Timer trigger
Correct Answer: A
Explanation: An HTTP trigger causes an Azure Function to execute when an HTTP request is received. An HTTP output binding is used to produce the HTTP response, while a queue output binding sends data to a queue. A timer trigger executes according to a schedule.
Question 2
A Function receives an HTTP request and needs to write the resulting document to Azure Blob Storage without explicitly creating and managing a Blob Storage client in application code. What should the developer use?
A. HTTP trigger B. Blob Storage output binding C. Timer trigger D. HTTP route parameter
Correct Answer: B
Explanation: An output binding provides a declarative way for a Function to write data to another supported Azure service. A Blob Storage output binding can write the Function’s output to a blob without requiring the developer to implement all of the storage interaction manually.
Question 3
A Function needs to retrieve additional data from Azure Storage after being invoked by an HTTP request. Which configuration best satisfies this requirement?
A. Configure two HTTP triggers. B. Configure a second HTTP output binding. C. Configure an HTTP trigger and an input binding. D. Configure two Function authorization keys.
Correct Answer: C
Explanation: The HTTP trigger determines when the Function runs, while an input binding can provide additional data to the Function. A Function must have exactly one trigger, but it can have additional input bindings.
Question 4
An HTTP-triggered Function should only respond to requests using the POST method. What should the developer configure?
A. A storage input binding B. A timer schedule C. A custom output binding D. The HTTP trigger’s allowed HTTP methods
Correct Answer: D
Explanation: The HTTP trigger can be configured with the HTTP methods to which it responds. Restricting the endpoint to POST prevents other HTTP methods from invoking that endpoint.
Question 5
A developer needs an HTTP Function endpoint with the following URL pattern:
/api/orders/12345
where 12345 represents an order identifier. What Azure Functions feature should be used to define the 12345 portion dynamically?
A. Route parameter B. Output binding C. Timer expression D. Function key
Correct Answer: A
Explanation: HTTP route parameters allow portions of the URL to be captured and passed to the Function. A route such as /api/orders/{id} can capture 12345 as the id parameter.
Question 6
An Azure Function needs to receive an HTTP request, retrieve information from a database, write a result to storage, and return an HTTP response. How should the Function be configured?
A. Four triggers B. One HTTP trigger with appropriate input/output bindings C. One database trigger and three HTTP triggers D. Four separate timer triggers
Correct Answer: B
Explanation: A Function has exactly one trigger. In this scenario, the HTTP request should be the trigger, while database and storage interactions can be implemented using appropriate bindings. The HTTP response is also produced by the HTTP output mechanism.
Question 7
A developer wants to prevent an HTTP-triggered Function from being publicly invokable without a Function key. Which authorization level should be used?
A. Anonymous B. Public C. Function D. None
Correct Answer: C
Explanation: The Function authorization level requires a Function key when invoking the HTTP endpoint. Anonymous does not require a Function key. Authentication and authorization requirements should still be evaluated in the context of the overall application architecture.
Question 8
An AI API accepts a request and places the work into a queue for processing by another Function. The API should immediately tell the client that the request has been accepted for processing rather than waiting for the AI operation to finish. Which HTTP status code is most appropriate?
A. 404 B. 500 C. 201 D. 202
Correct Answer: D
Explanation:202 Accepted is appropriate when a request has been accepted for processing but the processing has not completed. This pattern is useful for asynchronous AI workloads where the client shouldn’t have to maintain an open HTTP request while the backend performs potentially lengthy processing.
Question 9
A Function receives a queue message and uses information from that message to determine which blob should be accessed through another binding. Which Azure Functions feature can dynamically pass values between bindings?
A. Binding expressions B. Authorization levels C. HTTP methods D. Function keys
Correct Answer: A
Explanation: Binding expressions allow values from trigger metadata, binding data, and other supported sources to be incorporated dynamically into binding configuration. This allows Functions to avoid hardcoding resource names and paths.
Question 10
An HTTP-triggered Function calls an external AI service. Under heavy load, the Function begins experiencing connection exhaustion because a new HTTP client is created for every invocation. What is the best approach?
A. Increase the HTTP response timeout indefinitely. B. Disable the HTTP trigger. C. Use an appropriate connection-reuse pattern rather than repeatedly creating HTTP clients. D. Add another HTTP trigger to the same Function.
Correct Answer: C
Explanation: Repeatedly creating and disposing HTTP clients can contribute to connection exhaustion and poor performance. HTTP clients and connections should be managed using an appropriate reuse pattern for the runtime and language being used. Adding triggers or changing the response timeout does not address the underlying connection-management problem.
Final Exam Review
If you remember only a handful of concepts for this AI-200 topic, make them these:
Trigger = starts the Function.
Binding = connects the Function to another resource.
Input binding = brings data into the Function.
Output binding = sends data from the Function to another resource.
HTTP trigger = serverless API entry point.
HTTP output = response to the API caller.
One Function = exactly one trigger, potentially multiple bindings.
And for scenario questions, focus on why the Function is being invoked and what resources it needs to interact with. Those two questions usually reveal whether the correct answer involves a trigger, an input binding, an output binding, or an HTTP configuration.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Connect to and consume Azure services (20–25%) --> Develop event- and message-based AI solutions --> Implement event-driven workflows by using Azure Event Grid, including filters, custom events, and retries
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Modern AI applications frequently need to react to events rather than continuously poll systems for changes. For example:
A document is uploaded and needs to be processed.
A new customer record is created and should trigger enrichment.
An AI model finishes processing a request.
A database record changes and downstream systems need to respond.
A custom application event needs to trigger a serverless workflow.
Azure Event Grid is an event-routing service designed to connect event producers with event handlers. It can receive events from Azure services, custom applications, and partner sources and route matching events to subscribers.
For the AI-200 exam, you should understand how to:
Design event-driven workflows with Event Grid.
Create and use custom events and custom topics.
Configure event subscriptions.
Filter events.
Understand Event Grid delivery and retry behavior.
Configure retry policies and dead-lettering.
Design consumers to tolerate duplicate or out-of-order events.
Event Grid is particularly useful when an application needs to react to something that has happened rather than explicitly requesting something to happen.
1. What Is Azure Event Grid?
Azure Event Grid is a managed event-routing service.
At a high level, the architecture looks like this:
A file upload can generate an event. Event Grid receives that event and routes it to an Azure Function, which processes the file.
Another example might be:
Application → Custom Event Grid Topic → Event Grid Subscription → AI Processing Service
The application publishes an event such as:
DocumentUploaded
Event Grid determines which subscriptions are interested in the event and delivers it to the appropriate handlers.
Event Grid supports system events from Azure services, custom application events, and partner events. It also provides filtering so subscribers receive only the events they need.
2. Event-Driven Architecture
An event-driven architecture separates the component that produces an event from the components that consume the event.
Consider an AI document-processing application.
A user uploads a document:
User
|
v
Blob Storage
|
| BlobCreated event
v
Event Grid
|
+----> Document Processing Function
|
+----> Audit Function
|
+----> Notification Service
The Blob Storage service doesn’t need to know how each consumer processes the event.
This provides several advantages:
Loose coupling
Independent scaling
Easier integration
Asynchronous processing
Multiple consumers
Reduced polling
Easier addition of new workflows
This is especially valuable for AI workloads because AI processing can be computationally expensive or time-consuming.
Instead of having an application constantly check whether something changed, an event can initiate processing only when necessary.
3. Important Event Grid Concepts
Several Event Grid terms are important for the AI-200 exam.
Event
An event describes something that happened.
Examples include:
ImageUploaded
DocumentCreated
OrderCompleted
ModelTrainingCompleted
CustomerCreated
An event generally contains information about the occurrence rather than instructions for what the receiver must do.
For example:
{
"eventType":"DocumentUploaded",
"subject":"/documents/invoice-123.pdf",
"data":{
"documentType":"invoice",
"customerId":"C1001"
}
}
Event Source
The event source is the system that generates the event.
Examples include:
Azure Storage
Azure resources
Custom applications
Partner services
Topic
A topic provides an endpoint through which events can be published.
For custom applications, you can create a custom topic and publish application-specific events to it.
For example:
OrderEvents
could receive:
OrderCreated
OrderUpdated
OrderCancelled
OrderCompleted
A custom topic allows an application to publish its own events without having to use an Azure service’s built-in event source.
Event Subscription
An event subscription tells Event Grid:
“Send matching events to this destination.”
A subscription connects an event source or topic to an event handler.
A subscription can define:
Destination
Event type filters
Subject filters
Advanced filters
Retry behavior
Dead-letter configuration
For example:
Custom Topic
|
+---- Subscription A → Azure Function
|
+---- Subscription B → Webhook
|
+---- Subscription C → Service Bus
Each subscription can independently determine which events it wants.
4. Event Handlers
The event handler is the destination that processes the event.
Depending on the Event Grid scenario, event handlers can include services such as:
Azure Functions
Azure Logic Apps
Webhooks
Azure Service Bus
Azure Event Hubs
Other supported Azure destinations
For AI applications, Azure Functions are particularly useful for lightweight event processing.
For example:
BlobCreated
|
v
Event Grid
|
v
Azure Function
|
+---- Extract text
+---- Generate embedding
+---- Store metadata
+---- Update search index
5. Event Grid vs. Message Queues
A common exam distinction is between events and messages/commands.
Event Grid is primarily an event-routing service.
It is appropriate when you want to communicate:
“Something happened.”
For example:
DocumentUploaded
A messaging service such as Azure Service Bus is more appropriate when you need durable message processing, commands, queues, transactions, sessions, or more sophisticated competing-consumer patterns.
For example:
ProcessThisDocument
is more command-like.
A useful rule is:
Requirement
Common choice
React to an event
Event Grid
Route events to multiple consumers
Event Grid
Serverless event triggering
Event Grid
Durable command/message processing
Service Bus
Queue-based workload processing
Service Bus
Pub/sub event routing
Event Grid
The services can also be combined.
For example:
Blob Storage
|
v
Event Grid
|
v
Service Bus Queue
|
v
AI Worker
Event Grid detects the event, while Service Bus provides durable message-processing capabilities.
6. Custom Events
A custom event is an event generated by your own application rather than an Azure service.
For example, an AI application might generate:
DocumentClassificationCompleted
with data such as:
{
"eventType":"DocumentClassificationCompleted",
"subject":"/documents/12345",
"data":{
"documentId":"12345",
"classification":"Invoice",
"confidence":0.97
}
}
The application publishes the event to a custom Event Grid topic.
Other applications can subscribe to that topic.
For example:
AI Processing Application
|
| DocumentClassificationCompleted
v
Event Grid Topic
|
+------> Billing System
|
+------> Audit System
|
+------> Notification System
This provides a loosely coupled architecture.
The AI processing application doesn’t need to know which systems are consuming the event.
7. Custom Topics
A custom topic provides a user-defined Event Grid endpoint for publishing application events.
For example:
CustomerEvents
The application publishes events to the topic, and subscribers consume matching events.
A custom topic is appropriate when:
Your application generates its own events.
You need an application-specific event endpoint.
You want multiple applications to subscribe to your events.
You want Event Grid to perform routing and filtering.
The topic can support Event Grid or CloudEvents schemas depending on the configuration. Event Grid supports multiple event schemas, including Event Grid schema and CloudEvents schema.
8. Event Types
Event types identify what happened.
For example:
DocumentCreated
DocumentDeleted
DocumentProcessed
DocumentFailed
A single topic can publish multiple event types.
A subscriber may only be interested in one or two.
For example:
Topic
|
+-- DocumentCreated
+-- DocumentUpdated
+-- DocumentDeleted
+-- DocumentProcessed
A subscription could specify:
Included event types:
DocumentProcessed
DocumentFailed
The subscriber would not receive the other event types.
Event type filtering is one of the simplest and most important forms of Event Grid filtering.
9. Event Filtering
Event filtering is one of the most important AI-200 concepts.
Suppose a topic receives thousands of events:
DocumentCreated
DocumentUpdated
DocumentDeleted
ImageUploaded
VideoUploaded
A particular Function might only care about:
DocumentCreated
Instead of sending every event to the Function and filtering them in application code, Event Grid can filter the events before delivery.
This reduces:
Unnecessary network traffic
Function executions
Processing
Cost
Application complexity
Event Grid supports several filtering approaches.
10. Event Type Filtering
Event type filtering allows a subscription to receive only specific event types.
For example:
Included event types:
DocumentCreated
DocumentUpdated
Events such as:
DocumentDeleted
would not be delivered to that subscription.
This is appropriate when the routing decision is based primarily on the type of event.
11. Subject Filtering
Events have a subject that identifies the resource or object associated with the event.
For example:
/documents/invoices/2026/invoice-123.pdf
A subscription can filter based on whether the subject:
Begins with a specified value
Ends with a specified value
For example:
Subject begins with:
/documents/invoices/
would select events associated with invoice documents.
Another example:
Subject ends with:
.pdf
could be used to select PDF-related events.
Subject filtering is useful when the event type is the same but the resource or path differs.
12. Advanced Filtering
Advanced filtering provides more precise filtering based on event properties.
For example:
{
"data":{
"department":"finance",
"priority":5,
"environment":"production"
}
}
A subscription could filter on:
data.department = "finance"
or:
data.priority > 3
or:
data.environment = "production"
Advanced filters support different data types and operators, including string, numeric, Boolean, and array-based filtering.
13. Common Advanced Filter Operators
Important operators include:
String operators
Examples include:
StringIn
StringNotIn
StringContains
StringNotContains
StringBeginsWith
StringNotBeginsWith
StringEndsWith
StringNotEndsWith
Numeric operators
Examples include:
NumberIn
NumberNotIn
NumberLessThan
NumberLessThanOrEquals
NumberGreaterThan
NumberGreaterThanOrEquals
Boolean
BoolEquals
There are also operators for null/undefined values and range-based comparisons.
For the exam, focus on understanding why you would use advanced filtering rather than memorizing every operator.
14. Example: Advanced Filtering
Imagine the application publishes:
{
"eventType":"DocumentUploaded",
"data":{
"documentType":"invoice",
"priority":8,
"environment":"production"
}
}
A subscription might filter for:
data.documentType = invoice
This means the subscriber only receives invoice events.
Another subscription might use:
data.priority >= 7
to receive only high-priority documents.
This is much more efficient than delivering every event and performing the filtering inside the application.
15. Combining Filters
You can use multiple filters to create more selective subscriptions.
For example:
Event Type = DocumentUploaded
AND
data.documentType = invoice
AND
data.environment = production
This creates a narrowly targeted event stream.
A good event design therefore includes meaningful event metadata.
For example:
{
"eventType":"DocumentUploaded",
"subject":"/documents/12345",
"data":{
"documentType":"invoice",
"environment":"production",
"priority":8
}
}
Good event metadata makes downstream routing much easier.
16. Designing Event Subjects
When designing custom events, don’t treat the subject as an arbitrary string.
A meaningful subject can make filtering easier.
For example:
/documents/invoices/2026/12345
is much more useful for routing than:
12345
A hierarchical subject can allow subscriptions to target broad or narrow groups of events.
For example:
/documents/invoices/
could represent all invoice documents.
A more specific path could identify:
/documents/invoices/2026/12345
This is particularly useful in large event-driven systems.
17. Event Delivery
Event Grid uses a push delivery model for many common Event Grid workflows.
When an event matches a subscription, Event Grid attempts to deliver it to the destination.
A successful HTTP response indicates successful delivery.
Event Grid considers HTTP status codes in the 200–204 range successful for delivery. Other responses are treated as failures and may result in retries or dead-lettering depending on the error and configuration.
18. At-Least-Once Delivery
One of the most important concepts for the exam is that Event Grid uses an at-least-once delivery model.
This means an event can potentially be delivered more than once.
For example:
Event published
|
v
Event Grid
|
+----> Consumer
|
+---- Processing succeeds
|
+---- Response delayed
If Event Grid cannot determine that delivery succeeded, it may retry.
The consumer could therefore receive the same event again.
Design implication
Event handlers should be idempotent whenever possible.
For example, instead of blindly performing:
Insert record
the consumer could use the event ID to determine whether it has already processed the event.
19. Event Ordering
Event Grid does not guarantee event ordering.
For example, an application might publish:
Event A
Event B
Event C
but the consumer could receive:
Event B
Event A
Event C
Therefore, applications that require strict ordering should not assume that Event Grid delivery preserves publication order.
If ordering is a hard requirement, another messaging design may be more appropriate.
20. Retry Behavior
If Event Grid cannot successfully deliver an event, it can retry delivery.
Event Grid uses an exponential-backoff-based retry schedule.
The current documented retry schedule includes progressively longer delays, beginning with short delays and eventually extending to hours. Event Grid may also delay or skip certain retries when an endpoint remains unhealthy.
The important exam concept is:
Event Grid does not immediately give up when an endpoint fails.
Instead, it attempts delivery again according to its retry behavior and configured retry policy.
21. Configurable Retry Policy
Event Grid allows you to configure two important retry limits:
Maximum delivery attempts
Event time-to-live (TTL)
The documented limits are:
Setting
Default
Valid range
Maximum delivery attempts
30
1–30
Event TTL
1,440 minutes
1–1,440 minutes
If both are configured, whichever limit is reached first determines when Event Grid stops attempting delivery.
Example
Suppose you configure:
Maximum attempts = 5
TTL = 30 minutes
If the event reaches five attempts before 30 minutes:
Stop retrying
If 30 minutes expires before five attempts occur:
Stop retrying
The retry schedule itself is not directly configurable. You configure the limits, not the individual retry intervals.
22. Dead-Lettering
When an event can no longer be delivered within the configured retry policy, you may want to preserve it instead of losing it.
This is where dead-lettering comes into play.
Event Grid can send undeliverable events to an Azure Storage Blob container.
Conceptually:
Event Grid
|
| delivery failures
v
Retry
|
| retry limit reached
v
Dead-letter storage
Dead-lettering is not enabled automatically for every subscription. You configure a storage account/container as the dead-letter destination.
23. Why Dead-Lettering Matters
Dead-lettering is particularly important when events represent business-critical operations.
Suppose an AI application generates:
DocumentProcessingCompleted
and the downstream billing system is temporarily unavailable.
Without a dead-letter destination, an event that ultimately cannot be delivered may be dropped.
With dead-lettering:
DocumentProcessingCompleted
|
v
Event Grid
|
v
Billing System
|
delivery fails
|
v
retries
|
v
Dead-letter Blob
An operations team or automated process can later inspect and reconcile those events.
24. Important HTTP Failure Behaviors
Not all HTTP errors are treated identically.
For example, certain configuration-related errors such as:
400 Bad Request
403 Forbidden
413 Request Entity Too Large
can cause Event Grid to stop retrying rather than repeatedly attempting an endpoint that is unlikely to succeed.
Other failures can result in retries.
For example:
503 Service Unavailable
is a typical transient failure for which retry behavior is appropriate.
Exam takeaway
Do not assume:
“Every failed HTTP request is retried forever.”
Event Grid distinguishes between failures and applies its delivery and retry rules accordingly.
25. Dead-Lettering vs. Retry
These concepts should not be confused.
Retry
Retry means:
“Try delivering the event again.”
Dead-letter
Dead-letter means:
“The event could not be successfully delivered within the applicable delivery policy, so preserve it for later investigation or processing.”
The general workflow is:
Publish
|
v
Deliver
|
+---- Success → Done
|
+---- Failure
|
v
Retry
|
+---- Success → Done
|
+---- Limits reached
|
v
Dead-letter
26. Delayed Delivery
Event Grid also protects unhealthy endpoints through delayed delivery.
If an endpoint repeatedly fails, Event Grid can delay subsequent deliveries to avoid overwhelming an already unhealthy system.
This is important in high-volume AI workloads.
Imagine an AI endpoint can process only 100 requests per second but suddenly receives thousands of events.
Repeatedly retrying failures immediately could make the problem worse.
Event Grid’s retry and delayed-delivery behavior helps prevent this type of cascading overload.
27. Event Grid and Azure Functions
A common AI-200 scenario is:
Event Source
|
v
Event Grid
|
v
Azure Function
For example:
Blob uploaded
|
v
Event Grid
|
v
Function
|
+---- Extract text
+---- Generate embedding
+---- Store vector
This architecture provides several advantages:
Serverless execution
Automatic scaling
Event-driven processing
Loose coupling
Reduced polling
Integration with other Azure services
However, the Function should still be designed for retries and duplicate events.
28. Event Grid and AI Workloads
Event-driven architectures are particularly useful for AI applications.
Consider a document ingestion pipeline:
Blob Storage
|
| BlobCreated
v
Event Grid
|
v
Azure Function
|
+---- Extract content
|
+---- Generate embedding
|
+---- Store in PostgreSQL
|
+---- Publish DocumentIndexed
|
v
Event Grid
|
+---- Notify application
+---- Update analytics
This creates a pipeline in which each stage can react to the completion of another stage.
29. Example: AI Image Processing
Suppose an application receives images.
When an image is uploaded:
Image Upload
|
v
Blob Storage
|
v
Event Grid
|
v
Azure Function
|
+---- Computer vision analysis
|
+---- Store results
|
+---- Publish ImageAnalyzed
Another subscriber might listen for:
ImageAnalyzed
and update a search index.
A third subscriber might send a notification.
The original uploader does not need to know about these downstream processes.
30. Designing Reliable Event Handlers
Because Event Grid can deliver events more than once, consumers should be designed appropriately.
Make operations idempotent
An operation is idempotent when executing it multiple times produces the same intended result as executing it once.
For example:
Set document status = "Processed"
is naturally more idempotent than:
Increment processed-count
If an event is delivered twice, an increment operation could incorrectly increase the count twice.
Track Event IDs
Consumers can maintain a record of processed event IDs.
For example:
Event ID: 8f72...
Status: Processed
When the same event arrives again:
Event already processed
The consumer can safely ignore it.
31. Avoiding Long-Running Event Handlers
Event handlers should generally acknowledge events promptly when possible.
A common architecture for longer AI operations is:
Event Grid
|
v
Function
|
v
Service Bus
|
v
Long-running AI Worker
The Function receives the event and places a durable work item into Service Bus.
The worker can then perform the longer operation.
This separates event notification from workload processing.
32. Event Grid Filtering vs. Application Filtering
Consider two designs.
Design A
Event Grid
|
v
Function
|
+---- Check event type
+---- Check priority
+---- Check environment
Design B
Event Grid
|
| Filter
v
Function
When the filtering criteria can be expressed through Event Grid subscription filters, Design B is generally preferable.
Benefits include:
Less unnecessary invocation
Lower processing overhead
Less network traffic
Lower cost
Simpler application code
This is an important architectural principle.
33. Multiple Subscribers
One of Event Grid’s strengths is that multiple subscriptions can consume the same event stream independently.
For example:
CustomerCreated
|
v
Event Grid
|
+---- Subscription 1 → CRM Function
|
+---- Subscription 2 → Analytics Function
|
+---- Subscription 3 → Notification Function
Each subscription can have its own:
Destination
Filter
Retry configuration
Dead-letter configuration
This allows one event to initiate multiple independent workflows.
34. Event Grid Delivery Batching
Event Grid normally delivers events individually.
For high-throughput scenarios, batching can be enabled.
Batching can improve HTTP efficiency by delivering multiple events in one request.
Current Event Grid push delivery supports configurable batch settings, including maximum events per batch and preferred batch size. Batching uses all-or-none semantics for a delivery request, so consumers must be able to process the entire delivered batch appropriately.
Exam consideration
If a question says:
“The application receives a very high volume of events and HTTP overhead is becoming significant.”
Consider event batching as a possible optimization.
35. Common Exam Scenario
Scenario
An AI application receives thousands of document events.
A Function should process only:
DocumentUploaded
events for:
/finance/
documents.
The best solution is to configure the Event Grid subscription with:
Event type filtering
Subject filtering
rather than sending every event to the Function.
The conceptual design is:
Event Grid
|
| Event Type = DocumentUploaded
| Subject begins with /finance/
v
Azure Function
This is more efficient than filtering inside the Function.
36. Common Exam Scenario: Custom Events
Scenario
A custom AI application needs to notify multiple independent applications whenever a document classification operation completes.
The application generates:
DocumentClassificationCompleted
Which Azure service should provide the event-routing mechanism?
Azure Event Grid is a natural choice.
A custom topic can receive the application’s events, and multiple subscriptions can route them to different handlers.
37. Common Exam Scenario: Temporary Endpoint Failure
Scenario
An Event Grid subscriber temporarily returns HTTP 503.
What should you expect?
Event Grid treats the delivery as unsuccessful and can retry according to its retry behavior.
This is different from simply assuming that the event is permanently lost.
38. Common Exam Scenario: Duplicate Events
Scenario
A Function processes an event successfully, but the response isn’t successfully acknowledged by Event Grid.
Event Grid may deliver the event again.
What should the Function do?
The Function should be designed to handle duplicate events safely.
Possible techniques include:
Event ID tracking
Idempotent writes
Upsert operations
Deduplication records
Transactional processing where appropriate
The key concept is:
Do not assume exactly-once delivery.
39. Common Exam Scenario: Event Loss
Scenario
A critical event must not simply disappear if the subscriber remains unavailable.
What should you configure?
Dead-lettering should be considered.
Configure an Azure Storage Blob container as the dead-letter destination so undeliverable events can be preserved for later reconciliation.
40. Common Exam Scenario: Retry Configuration
Scenario
An application should stop trying to deliver an event after either:
10 delivery attempts, or
60 minutes.
The Event Grid subscription can be configured with:
Maximum delivery attempts = 10
TTL = 60 minutes
Whichever limit is reached first stops the delivery attempts.
41. Key Distinctions to Remember
For the AI-200 exam, remember these distinctions:
Concept
Purpose
Event
Describes something that happened
Event source
Produces the event
Topic
Endpoint/channel for events
Custom topic
Topic for application-generated events
Event subscription
Defines routing to a destination
Event handler
Processes the event
Event type filter
Selects event types
Subject filter
Selects events by subject prefix/suffix
Advanced filter
Filters event properties
Retry
Attempts delivery again
TTL
Maximum time Event Grid attempts delivery
Maximum attempts
Maximum delivery attempts
Dead-letter
Stores undeliverable events
Idempotency
Safely handles duplicate delivery
42. AI-200 Exam Tips
Tip 1: Event Grid is about events
If the question says:
“Something happened, and another service should react.”
Think:
Event Grid
Tip 2: Service Bus is different
If the scenario emphasizes:
Commands
Queues
Durable messaging
Competing consumers
Sessions
Transactional messaging
think:
Azure Service Bus
Tip 3: Filter before invoking
If Event Grid can filter an event, don’t automatically filter it in application code.
Event subscription filtering can reduce unnecessary processing.
Tip 4: Expect duplicates
Event Grid delivery should be treated as at least once.
Design consumers accordingly.
Tip 5: Don’t assume ordering
Event Grid does not guarantee event ordering.
Tip 6: Know retry limits
Remember:
Maximum delivery attempts
+
Event TTL
Whichever limit is reached first stops delivery attempts.
Tip 7: Know dead-lettering
Dead-lettering provides a place to preserve events that could not be delivered.
For Event Grid, the dead-letter destination uses Azure Blob Storage.
Tip 8: Understand the three major filter types
Remember:
Event type
Subject
Advanced properties
43. Summary
Azure Event Grid provides a managed mechanism for building event-driven applications by routing events from producers to subscribers.
For AI-200, the most important concepts are:
Event sources produce events.
Topics provide event publishing endpoints.
Custom topics support application-generated events.
Event subscriptions define routing.
Event handlers process events.
Event type filters select specific types of events.
Subject filters select events based on their subjects.
Advanced filters can evaluate event properties.
Event Grid provides retry behavior for failed deliveries.
Retry limits can be configured using maximum attempts and TTL.
Dead-lettering can preserve events that cannot be delivered.
Event delivery should be treated as at least once.
Consumers should be designed to tolerate duplicates.
Event ordering should not be assumed.
Event Grid and Service Bus solve different messaging problems.
Event Grid is particularly useful for loosely coupled, event-driven AI workflows.
The most important mental model is:
Something happens → Event is generated → Event Grid routes it → Matching subscription receives it → Handler processes it → Retry/dead-letter mechanisms provide resilience.
Practice Exam Questions
Question 1
An AI application publishes a DocumentProcessed event whenever document processing finishes. Several independent applications need to react to this event, and the producing application should not need to know which applications consume it.
Which Azure service is the best fit for routing these events?
A. Azure Event Grid
B. Azure Key Vault
C. Azure App Configuration
D. Azure Container Registry
Answer: A
Explanation
Azure Event Grid is designed for event routing and pub/sub scenarios. A custom topic can receive application-generated events, while multiple event subscriptions can independently route those events to different handlers.
An Event Grid subscription should receive only events whose subject begins with:
/documents/invoices/
Which filtering mechanism should be used?
A. Advanced numeric filtering
B. Subject filtering
C. Event TTL
D. Maximum delivery attempts
Answer: B
Explanation
Subject filtering is specifically designed to select events based on the beginning or ending of an event’s subject.
TTL and maximum delivery attempts control delivery behavior rather than which events are selected.
Question 3
An application publishes the following event:
{
"eventType":"DocumentUploaded",
"data":{
"department":"finance",
"priority":8
}
}
A subscriber should receive only events where data.priority is greater than or equal to 7.
Which Event Grid capability should be used?
A. Subject filtering
B. Event TTL
C. Advanced filtering
D. Dead-lettering
Answer: C
Explanation
Advanced filtering allows subscriptions to evaluate properties within the event data using operators such as NumberGreaterThanOrEquals.
Subject filtering is appropriate for the event subject, while TTL and dead-lettering concern delivery reliability.
Question 4
An Event Grid subscriber temporarily returns HTTP 503 responses because the application is unavailable. What should you expect Event Grid to do?
A. Immediately delete all affected events
B. Permanently disable the subscription
C. Retry delivery according to its retry behavior and configured limits
D. Convert the events into Service Bus messages automatically
Answer: C
Explanation
HTTP 503 represents a service-unavailable condition. Event Grid can retry failed delivery using its retry behavior. Delivery continues until successful delivery or the applicable retry policy limits are reached.
Event Grid does not automatically convert the events into Service Bus messages or permanently disable the subscription.
Question 5
A critical Event Grid event cannot be delivered after the configured retry policy is exhausted. The organization needs to preserve the event for later investigation.
What should you configure?
A. A dead-letter destination in Azure Blob Storage
B. An Azure Container Registry
C. An Azure App Configuration store
D. An Azure Key Vault secret
Answer: A
Explanation
Event Grid supports dead-lettering to an Azure Storage Blob container. Undeliverable events can be stored there for later inspection and reconciliation.
The other services do not provide Event Grid dead-letter storage.
Question 6
An Event Grid subscription is configured with:
Maximum delivery attempts = 5
TTL = 60 minutes
The event reaches five delivery attempts after only 12 minutes. What happens next?
A. Event Grid continues retrying until 60 minutes have elapsed
B. Event Grid stops delivery attempts because the maximum attempt limit was reached
C. Event Grid automatically changes the maximum attempts to 30
D. Event Grid immediately sends the event to every other subscription
Answer: B
Explanation
When both maximum delivery attempts and TTL are configured, the first limit reached determines when Event Grid stops delivery attempts.
Because five attempts have occurred before the 60-minute TTL expires, the maximum-attempt limit is reached first.
If dead-lettering is configured, the event can then be dead-lettered.
Question 7
An AI application processes DocumentProcessed events. Occasionally, the same event is delivered twice. The application currently increments a counter every time it receives the event, causing inaccurate results.
What is the best design improvement?
A. Increase the event TTL
B. Disable event filtering
C. Make the event-processing operation idempotent
D. Increase the number of Event Grid subscriptions
Answer: C
Explanation
Event Grid uses at-least-once delivery semantics, so consumers must be prepared for duplicate events.
An idempotent operation can safely process the same event multiple times without producing an incorrect result. Event IDs can also be tracked to implement deduplication.
Changing TTL, filtering, or subscription count does not solve the fundamental duplicate-processing problem.
Question 8
An application generates its own events and needs an Event Grid endpoint to which it can publish those events.
Which resource should the application use?
A. Azure Service Bus session
B. Azure Event Hubs consumer group
C. Azure Storage queue
D. An Azure Event Grid custom topic
Answer: D
Explanation
A custom Event Grid topic provides a user-defined endpoint for applications to publish their own events.
Service Bus, Event Hubs, and Storage queues have different messaging purposes and do not represent the Event Grid custom-topic publishing model.
Question 9
An Event Grid subscription should receive only events of these types:
DocumentCreated
DocumentUpdated
It should not receive:
DocumentDeleted
Which configuration should be used?
A. Included event type filtering
B. Dead-lettering
C. Event TTL
D. Maximum delivery attempts
Answer: A
Explanation
Event type filtering allows a subscription to specify which event types it should receive.
The other options control delivery reliability rather than event selection.
Question 10
An AI application receives a very high volume of Event Grid events. HTTP request overhead is becoming significant, and the event-processing service can efficiently process multiple events in a single request.
Which Event Grid capability should be considered?
A. Dead-lettering
B. Event delivery batching
C. Subject filtering
D. Event TTL reduction
Answer: B
Explanation
Event Grid supports batching for push delivery. Instead of sending every event in an individual delivery request, multiple events can be delivered together.
Batching can improve HTTP efficiency in high-throughput scenarios. The consumer must be designed to process the batch appropriately because Event Grid uses all-or-none semantics for a batch delivery request.
Final Exam Takeaways
Before taking the AI-200 exam, make sure you can confidently answer these questions:
When should I use Event Grid? For event-driven routing and reacting to things that happened.
When should I consider Service Bus instead? When the scenario calls for durable messaging, queues, commands, sessions, or sophisticated message-processing patterns.
How do I create application-generated events? Publish them to an Event Grid custom topic.
How do I control which events a subscriber receives? Use event type, subject, and advanced filters.
What happens when delivery fails? Event Grid can retry according to its retry behavior.
What controls how long Event Grid retries? Event TTL and maximum delivery attempts.
What happens when delivery ultimately fails? With dead-lettering configured, the event can be stored in Azure Blob Storage.
Can an event be delivered more than once? Yes. Design consumers to tolerate duplicates.
Does Event Grid guarantee event ordering? No.
How can high-volume delivery be optimized? Consider event batching where the consumer supports it.
If you understand those ten points—and especially the distinctions between event filtering, retry, TTL, dead-lettering, and idempotent processing—you’ll have a strong foundation for the Event Grid portion of AI-200.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Connect to and consume Azure services (20–25%) --> Develop event- and message-based AI solutions --> Queue and process back-end operations by using Azure Service Bus, including dead-letter queue handling, messages, topics, and subscriptions
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
AI applications frequently perform operations that should not block a user’s request. Examples include processing documents, generating embeddings, running batch inference, sending notifications, executing long-running model operations, or enriching data.
Azure Service Bus provides reliable asynchronous messaging that allows application components to communicate without requiring them to be available or execute at the same time.
For the AI-200 exam, you should understand how to:
Use Service Bus queues for asynchronous point-to-point processing.
Use topics and subscriptions for publish/subscribe scenarios.
Design messages for AI workloads.
Process messages reliably.
Understand message settlement.
Use peek-lock processing.
Handle retries and poison messages.
Work with dead-letter queues (DLQs).
Understand message locks and delivery counts.
Choose between queues and topics based on application requirements.
The key architectural idea is decoupling.
Instead of:
AI application → immediately execute expensive operation
you can use:
AI application → Service Bus → worker → AI operation
This allows the producer and consumer to scale independently and protects downstream AI services from sudden workload spikes.
1. What Is Azure Service Bus?
Azure Service Bus is a fully managed enterprise message broker designed for reliable asynchronous communication between distributed applications.
A typical architecture might look like:
Client
|
v
AI API
|
v
Service Bus Queue
|
+------------------+
| |
v v
Worker 1 Worker 2
| |
+--------+---------+
|
v
AI Service
The API does not have to wait for the worker to finish.
Instead, it places a message onto the queue and can return a response indicating that the operation has been accepted.
The worker processes the message later.
This provides several important architectural benefits.
Temporal decoupling
The producer and consumer do not have to be running simultaneously.
A producer can place a message into the queue even when the consumer is temporarily unavailable.
Load leveling
Suppose an application normally receives 100 AI requests per minute but occasionally receives 5,000 requests per minute.
Rather than requiring the AI processing infrastructure to immediately handle all 5,000 requests, the application can place requests into a queue.
Workers can process the backlog at a sustainable rate.
Incoming requests
|
v
+----------------+
| Service Bus |
| Queue |
+----------------+
|
v
+----------------+
| AI Workers |
| 1 2 3 4 ... |
+----------------+
The queue acts as a buffer between the workload producer and the processing infrastructure.
Competing consumers
Multiple worker instances can consume messages from the same queue.
For example:
+--> Worker 1
|
Service Bus -+--> Worker 2
Queue |
+--> Worker 3
|
+--> Worker 4
Each message is normally processed by only one competing consumer.
This allows the processing tier to scale horizontally.
2. Azure Service Bus Messaging Entities
The three primary messaging entities you need to understand are:
Queues
Topics
Subscriptions
The most important distinction is:
Entity
Communication pattern
Typical use
Queue
Point-to-point
Work distribution
Topic
Publish/subscribe
Broadcasting events
Subscription
Receiver attached to a topic
Independent consumers
3. Service Bus Queues
A queue is appropriate when a message represents a unit of work that should generally be processed by one consumer.
For example:
AI API
|
| Submit document-processing request
v
Service Bus Queue
|
+---- Worker A
|
+---- Worker B
|
+---- Worker C
Although multiple workers can listen to the same queue, a particular message is delivered to one competing consumer for processing.
Example
Suppose an application accepts uploaded documents and needs to:
Extract text.
Generate embeddings.
Store vectors.
Update a search index.
The web application could put this message onto a queue:
{
"operation":"process-document",
"documentId":"12345",
"blobUrl":"https://storage/.../document.pdf",
"model":"embedding-model",
"correlationId":"abc-123"
}
A worker receives the message and performs the processing.
This is preferable to making the user’s HTTP request wait for the entire AI pipeline.
4. Topics and Subscriptions
Queues are primarily for point-to-point processing.
Topics and subscriptions are designed for publish/subscribe scenarios.
A topic can have multiple subscriptions:
+--> Subscription A --> Consumer A
|
Publisher --> Topic
|
+--> Subscription B --> Consumer B
|
+--> Subscription C --> Consumer C
Each subscription can receive its own copy of a published message.
For AI applications, this might be JSON containing:
Operation name
Entity ID
Storage location
Model information
Processing parameters
Application properties
Application properties can contain metadata used for routing, correlation, filtering, or processing decisions.
Examples include:
eventType
tenantId
priority
correlationId
contentType
Message ID
A producer can assign a unique message ID.
This can be useful for duplicate detection and application-level idempotency.
Correlation ID
A correlation ID allows related operations to be tracked across distributed components.
For example:
HTTP request
|
| correlationId = ABC123
v
Service Bus
|
v
AI worker
|
v
Azure AI service
Logging the same correlation ID throughout the workflow makes troubleshooting considerably easier.
8. Avoid Putting Large AI Payloads Directly in Messages
AI workloads can involve large documents, images, audio files, or other payloads.
Instead of putting a large file directly into the Service Bus message, a common architecture is the claim-check pattern.
The large payload is stored separately, such as in Azure Blob Storage.
The Service Bus message contains a reference:
{
"documentId":"12345",
"blobUri":"https://storage.example/document.pdf",
"operation":"extract-text"
}
The consumer retrieves the payload from storage.
This keeps messages smaller and allows the messaging layer to focus on coordinating work rather than transporting large files.
9. Message Processing Modes
Service Bus provides different approaches for receiving messages.
The two important concepts for the AI-200 exam are:
Peek-lock
Receive-and-delete
10. Peek-Lock Mode
Peek-lock is generally the preferred mode when losing a message is unacceptable.
The processing model is approximately:
Receive message
|
v
Message is locked
|
v
Process message
|
v
Complete message
When the consumer receives a message in peek-lock mode, the message is temporarily locked so another consumer cannot simultaneously process it.
After successful processing, the consumer explicitly completes the message.
11. Message Settlement
When using peek-lock, the consumer must settle the message.
Important settlement operations include:
Complete
The operation succeeded.
The message is removed from the queue or subscription.
Process successfully
|
v
Complete
|
v
Message removed
Abandon
The consumer cannot successfully process the message and wants it made available again.
Processing failure
|
v
Abandon
|
v
Message becomes available again
Dead-letter
The message is considered unsuitable for normal processing and is moved to the dead-letter queue.
This is useful for poison messages or messages that cannot be successfully processed after repeated attempts.
Defer
The consumer can defer a message when processing cannot currently continue but the application wants to retrieve it later using its sequence number.
12. Why Peek-Lock Is Important
Consider this sequence:
1. Worker receives message.
2. Worker starts AI processing.
3. Worker crashes.
4. Message was never completed.
Because the message wasn’t completed, Service Bus can make it available again after the lock expires.
This provides an at-least-once processing behavior.
The important consequence is:
A message can potentially be processed more than once.
Therefore, AI workers should ideally be designed to be idempotent.
For example, before inserting an embedding, the application could check whether that document/version has already been processed.
13. Receive-and-Delete
In receive-and-delete mode, the message is removed as soon as it is received.
Receive
|
v
Message deleted
|
v
Process
This can provide simpler and potentially higher-throughput processing, but it introduces a major risk.
If the worker crashes after receiving the message but before completing the work, the message is already gone.
Therefore:
Use peek-lock when message loss is unacceptable.
Use receive-and-delete only when occasional message loss is acceptable.
14. Message Locks
When a message is received using peek-lock, it is temporarily locked.
The lock prevents another receiver from processing the same message simultaneously.
However, the lock has a limited duration.
If processing takes too long, the application can renew the lock where supported.
For long-running AI operations, this is important.
For example:
Receive
|
v
Lock acquired
|
+---- Process AI request
|
+---- Renew lock
|
+---- Renew lock
|
v
Complete
If the lock expires before the message is completed, the message can become available again.
This can result in duplicate processing.
15. Dead-Letter Queues
A dead-letter queue (DLQ) is a secondary subqueue associated with a Service Bus queue or topic subscription.
It stores messages that cannot be successfully processed or delivered.
Common causes include:
Exceeding the maximum delivery count.
Message expiration when dead-lettering on expiration is enabled.
Explicit application dead-lettering.
Certain forwarding or routing failures.
Invalid processing conditions.
The DLQ is therefore an important mechanism for handling poison messages.
16. What Is a Poison Message?
A poison message is a message that repeatedly fails processing.
For example:
Message received
|
v
AI worker fails
|
v
Message retried
|
v
AI worker fails
|
v
Message retried
|
v
...
|
v
Dead-letter queue
Without a DLQ, the same bad message could continuously consume processing capacity.
17. Maximum Delivery Count
Service Bus queues and topic subscriptions have a maximum delivery count.
The default value is commonly 10.
When a message is repeatedly delivered under peek-lock and the processing attempt fails—for example, because the message is abandoned or its lock expires—the delivery count increases.
Once the configured maximum is exceeded, Service Bus moves the message to the DLQ.
The important exam concept is:
Increasing the maximum delivery count does not fix a poison message. It only allows more failed delivery attempts before dead-lettering.
The appropriate value depends on the workload.
18. Handling the Dead-Letter Queue
A DLQ should not simply become a place where failed messages are forgotten.
A production application should monitor it.
A typical operational workflow is:
Normal Queue
|
v
AI Worker
|
Processing
/ \
Success Failure
| |
v v
Complete Retry
|
v
Max attempts
|
v
DLQ
|
v
Investigate
|
+----------+----------+
| |
Correct Reject
| |
v v
Reprocess Discard
The application or operations team can inspect DLQ messages, determine why processing failed, correct the underlying problem, and potentially resubmit appropriate messages.
Dead-lettered messages include dead-letter reason information that can help diagnose the failure.
19. Explicit Dead-Lettering
An application can explicitly dead-letter a message.
This is appropriate when the application determines that retrying will not solve the problem.
For example:
Message:
customerId = 123
operation = generate-report
format = "INVALID_FORMAT"
If the application knows that the message is permanently invalid, repeatedly retrying it is wasteful.
The worker can dead-letter the message instead.
This is different from a transient error such as:
AI service temporarily unavailable
A transient failure may justify retrying.
A permanently invalid message generally should not.
20. Retry vs. Dead-Letter
A useful exam distinction is:
Situation
Appropriate response
Temporary network failure
Retry
Temporary AI service throttling
Retry
Worker temporarily unavailable
Retry
Invalid message structure
Potentially dead-letter
Unsupported operation
Potentially dead-letter
Poison message
Dead-letter after appropriate retries
Processing repeatedly fails
Dead-letter
Successful processing
Complete
The key is distinguishing transient failures from permanent failures.
21. Time to Live (TTL)
Messages can have a time-to-live (TTL).
TTL determines how long a message is considered valid.
For example:
Message created
|
|---------------- TTL ----------------|
| |
v v
Valid Expired
An expired message should generally no longer be processed.
If dead-lettering on message expiration is enabled for the entity, expired messages can be moved to the DLQ.
This can be useful when stale AI requests are no longer useful.
For example, an AI recommendation request that is several hours old may no longer have business value.
22. Idempotent AI Processing
At-least-once delivery means that duplicate processing is possible.
Consider:
Worker receives message
|
v
Generate embedding
|
v
Store embedding
|
X
Worker crashes before Complete
The message may be delivered again.
The worker might generate and store the embedding again.
A robust application should therefore make important operations idempotent.
One strategy is to use a deterministic identifier:
documentId + documentVersion
The worker can check whether that specific version has already been processed.
Another approach is to use Service Bus duplicate-detection capabilities where appropriate, combined with application-level safeguards.
Do not assume that messaging infrastructure alone eliminates every duplicate-processing scenario.
23. Sessions and Ordered Processing
Some applications require related messages to be processed in order.
Service Bus supports sessions for this purpose.
A session groups related messages using a session identifier.
For example:
Session: Customer-1001
Message 1
Message 2
Message 3
Message 4
A session-enabled consumer can process the messages associated with the session as an ordered sequence.
Sessions are useful when an AI workflow contains stateful or order-dependent operations.
For example:
Document uploaded
|
v
Text extracted
|
v
Embedding generated
|
v
Index updated
If later operations depend on earlier ones, ordering can become important.
24. Service Bus in an AI Architecture
A common AI architecture might look like:
+----------------+
| Client |
+-------+--------+
|
v
+----------------+
| AI API |
+-------+--------+
|
v
+----------------+
| Service Bus |
| Queue |
+-------+--------+
|
+----------+----------+
| | |
v v v
Worker 1 Worker 2 Worker 3
| | |
+----------+----------+
|
v
+----------------+
| Azure AI |
| Services |
+----------------+
This design provides:
Asynchronous processing.
Load leveling.
Horizontal scalability.
Failure isolation.
Retry capabilities.
Durable message storage.
Better control of downstream AI workloads.
25. Service Bus Topics in AI Event Architectures
Topics are especially useful when one AI event needs to trigger multiple independent workflows.
This avoids tightly coupling the document-uploading application to every downstream service.
26. Monitoring Service Bus Workloads
Operational monitoring is important because messaging problems can be difficult to see from the front-end application alone.
Useful indicators include:
Active message count.
Dead-letter message count.
Message processing failures.
Message age.
Processing latency.
Receiver throughput.
Queue backlog.
Delivery counts.
A growing active-message count can indicate that producers are generating messages faster than consumers can process them.
A growing DLQ count can indicate a processing or data-quality problem.
For AI workloads, also monitor downstream dependencies such as model-service throttling and latency.
27. Common AI-200 Exam Traps
Trap 1: Choosing a topic when only one worker should process each message
Use a queue for a competing-consumer workload.
Trap 2: Choosing a queue when multiple independent consumers need every event
Use a topic with subscriptions.
Trap 3: Assuming peek-lock means exactly-once processing
Peek-lock supports reliable processing, but duplicate processing can still occur.
Design consumers to be idempotent.
Trap 4: Using receive-and-delete for critical workloads
The message is removed before processing completes.
If the worker fails, the message can be lost.
Trap 5: Treating the DLQ as a retry queue
A DLQ is primarily a place to isolate messages that cannot be successfully processed or delivered.
Investigate the cause before reprocessing them.
Trap 6: Increasing MaxDeliveryCount to solve permanent failures
If the message itself is invalid, more retries simply waste resources.
Trap 7: Putting large documents directly into Service Bus messages
Consider storing large payloads in Blob Storage and placing a reference in the message.
Trap 8: Forgetting duplicate processing
At-least-once processing means consumers should tolerate duplicates.
28. Quick Decision Guide
Use this mental model for the exam:
Need asynchronous processing?
|
v
Azure Service Bus
|
+-----+------+
| |
One path Many paths
| |
v v
Queue Topic
|
v
Subscriptions
For message processing:
Critical message?
|
+---- Yes ---> Peek-lock
|
+---- No ----> Receive-and-delete may be acceptable
For processing failures:
Failure
|
+--> Temporary? ----> Retry
|
+--> Permanent? ----> Dead-letter
|
+--> Repeated failure? ----> DLQ
For large AI payloads:
Large file
|
v
Blob Storage
|
v
Service Bus message
(reference + metadata)
29. Key Takeaways
For AI-200, remember these concepts:
Queues provide point-to-point messaging and competing-consumer processing.
Topics provide publish/subscribe messaging.
Subscriptions allow independent consumers to receive copies of topic messages.
Peek-lock is appropriate when message loss is unacceptable.
Receive-and-delete removes a message before processing completes and can result in message loss.
Complete removes a successfully processed message.
Abandon makes a message available for another delivery attempt.
Dead-letter moves a message into the DLQ for isolation and investigation.
At-least-once processing means duplicate processing is possible.
AI workers should be designed to be idempotent where duplicate execution is possible.
Maximum delivery count controls how many delivery attempts occur before dead-lettering.
TTL controls message lifetime.
Topics are ideal for fan-out scenarios.
Subscription filters can selectively route messages.
Correlation IDs are valuable for distributed tracing and troubleshooting.
Large payloads should generally be stored externally, with a reference in the Service Bus message.
Sessions can be used when ordered, stateful message processing is required.
A growing DLQ is an operational signal that requires investigation.
A growing active-message backlog can indicate insufficient consumer capacity.
Service Bus is particularly valuable in AI architectures because it decouples request ingestion from potentially expensive or long-running AI processing.
Practice Exam Questions
Question 1
An AI application receives document-processing requests through an HTTP API. Each request should be processed by exactly one available worker. Multiple worker instances must be able to process requests concurrently.
Which Azure Service Bus entity should you use?
A. Queue
B. Topic with one subscription
C. Topic with multiple subscriptions
D. Event Grid topic
Answer: A. Queue
Explanation
A Service Bus queue is designed for point-to-point communication and competing consumers. Multiple workers can receive messages from the same queue while each message is processed by one consumer.
A topic is more appropriate when the same event needs to be delivered independently to multiple subscribers. Event Grid is primarily designed for event notification and event-driven architectures rather than work-queue semantics.
Question 2
An AI application publishes a DocumentUploaded event. Three independent services must receive the event: an embedding service, an auditing service, and a notification service.
Which Service Bus design should you use?
A. Three separate queues with the application sending the message to each queue
B. One queue with three competing consumers
C. One topic with three subscriptions
D. One subscription attached to three queues
Answer: C. One topic with three subscriptions
Explanation
A Service Bus topic with multiple subscriptions implements a publish/subscribe pattern. Each subscription can independently receive a copy of the event.
Using a queue with multiple competing consumers would not guarantee that all three services receive the message because competing consumers process a message rather than each receiving an independent copy.
Question 3
An AI worker receives a message using peek-lock mode. The worker successfully completes the AI operation but crashes before completing the Service Bus message.
What can happen?
A. The message is permanently deleted
B. The message can become available for redelivery
C. The message is automatically moved to another subscription
D. The message is converted into a scheduled message
Answer: B. The message can become available for redelivery
Explanation
With peek-lock, the message is not removed until the consumer successfully settles it, typically by completing it.
If the lock expires before completion, Service Bus can make the message available again. This creates the possibility of duplicate processing and is why consumers should be designed to be idempotent.
Question 4
An AI worker repeatedly receives a malformed message that cannot ever be processed successfully. The application should prevent the message from continually consuming worker capacity.
What is the most appropriate action?
A. Increase the message TTL
B. Dead-letter the message
C. Schedule the message for later
D. Extend the message lock indefinitely
Answer: B. Dead-letter the message
Explanation
A permanently invalid message is a good candidate for dead-lettering. The DLQ isolates the message from normal processing while allowing operators or application logic to investigate it.
Increasing retries or extending locks does not solve a permanent data problem.
Question 5
An AI application processes messages that occasionally fail because an external AI service is temporarily unavailable. What should the application generally do first?
A. Retry the operation
B. Immediately delete the message
C. Immediately dead-letter every message
D. Disable the Service Bus queue
Answer: A. Retry the operation
Explanation
A temporary service outage is a transient failure. Retrying the operation is generally appropriate, assuming the retry strategy is bounded and incorporates appropriate delay/backoff.
Permanent failures should generally be dead-lettered rather than repeatedly retried.
Question 6
An AI application uses Service Bus to process critical inference requests. The application must minimize the possibility of losing a request if a worker crashes while processing it.
Which receive mode should be used?
A. Receive-and-delete
B. Peek-lock
C. Browse-only
D. Scheduled delivery
Answer: B. Peek-lock
Explanation
Peek-lock allows the worker to receive and lock the message without immediately removing it. The worker completes the message after successful processing.
If the worker crashes before completion, the message can become available for redelivery after the lock expires.
Receive-and-delete removes the message as soon as it is received, so a worker failure can result in message loss.
Question 7
A document-processing AI solution needs to pass a 20-MB document to a background worker. The development team wants to avoid putting the entire document into the Service Bus message.
What is the best design?
A. Store the document in Blob Storage and place a reference to it in the Service Bus message
B. Convert the document to Base64 and place it directly in the message
C. Split the document into hundreds of unrelated messages
D. Store the document in the message’s correlation ID
Answer: A. Store the document in Blob Storage and place a reference to it in the Service Bus message
Explanation
The claim-check pattern is appropriate for large payloads. The document can be stored in Blob Storage while the Service Bus message contains the document identifier or URI plus relevant metadata.
This keeps the messaging layer focused on coordinating work rather than transporting large payloads.
Question 8
A Service Bus queue has a configured maximum delivery count of 10. A worker receives a message but repeatedly abandons it because processing fails.
What eventually happens when the message exceeds the configured delivery limit?
A. The message is automatically copied to every topic
B. The message is permanently deleted without any record
C. The message is moved to the dead-letter queue
D. The message is automatically sent to Event Grid
Answer: C. The message is moved to the dead-letter queue
Explanation
When a message repeatedly fails processing and exceeds the configured maximum delivery count, Service Bus moves it to the DLQ.
The DLQ provides a separate location where the message can be investigated and, when appropriate, corrected and reprocessed.
Question 9
An AI system publishes messages describing uploaded documents. The application has separate consumers for compliance, analytics, and embedding generation. Each consumer should receive its own copy of applicable messages.
Which feature should the developer use to route only relevant messages to each consumer?
A. Queue sessions
B. Topic subscription filters
C. Message lock renewal
D. Receive-and-delete mode
Answer: B. Topic subscription filters
Explanation
Topic subscriptions can use filters to determine which messages are delivered to each subscription.
For example, a compliance subscription could receive only documents belonging to a particular business category while an embedding subscription receives all document events.
Question 10
An AI worker processes a message successfully and writes the result to a database. Before the worker completes the Service Bus message, it crashes. The message is subsequently delivered again.
What is the best way for the application to handle this possibility?
A. Assume Service Bus guarantees exactly-once application processing
B. Disable message retries
C. Design the processing operation to be idempotent
D. Use receive-and-delete mode
Answer: C. Design the processing operation to be idempotent
Explanation
Peek-lock processing provides reliable message handling but does not eliminate the possibility of duplicate processing. A worker can successfully perform its business operation and then fail before completing the Service Bus message.
The message may therefore be delivered again.
An idempotent application can safely recognize that the operation has already been performed—for example, by using a document ID and version as an idempotency key—rather than creating duplicate results.
Receive-and-delete would actually increase the risk of losing messages if the worker fails before completing its work.
This exam topic is especially worth mastering for AI-200 because exam scenarios often combine Service Bus + asynchronous AI processing + retries + competing consumers + DLQs rather than asking about those features in isolation.
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub. This topic falls under these sections: Develop AI solutions by using Azure data management services (25–30%) --> Integrate Azure Managed Redis in AI solutions --> Implement vector indexing to enable similarity search
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Vector similarity search is a foundational capability for modern AI applications. It allows an application to retrieve data based on semantic similarity rather than requiring an exact keyword match.
For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how Azure Managed Redis can be used as a low-latency vector database, how vectors are stored and indexed, the difference between FLAT and HNSW indexing, how distance metrics affect similarity calculations, and how vector indexes are queried.
Azure Managed Redis provides vector search through the RediSearch module. Vector data can be stored in Redis hashes or JSON documents and indexed for similarity searches.
1. What Is Vector Similarity Search?
Traditional database searches generally look for exact or textual matches.
For example:
"How do I reset my password?"
A keyword-based search might look for documents containing:
password
reset
credentials
account
Vector search takes a different approach.
The text is converted into an embedding, which is a numerical representation of the semantic meaning of the text.
For example:
"How do I reset my password?"
↓
Embedding model
↓
[0.021, -0.134, 0.087, ..., 0.442]
A document such as:
“Steps for recovering your account credentials”
may have an embedding that is mathematically close to the query embedding even though the document does not contain the exact phrase “reset my password.”
This allows vector search to find semantically related information.
2. What Is an Embedding?
An embedding is a high-dimensional numerical representation of data.
Embeddings can represent:
Text
Documents
Images
Products
Audio
Other types of content
The embedding model transforms the original content into a vector.
For example:
Document
↓
Embedding model
↓
[0.12, -0.04, 0.81, 0.23, ...]
The number of dimensions depends on the embedding model.
Important exam concept
The vectors being indexed and the query vectors must be compatible.
In particular, the vector index configuration must match the characteristics of the embedding model, including:
Vector dimensions
Distance metric
Vector representation/type
Using inconsistent embedding models can produce poor or invalid search results.
3. Azure Managed Redis as a Vector Database
Azure Managed Redis is primarily known for high-performance in-memory data operations, but it can also support vector workloads.
With the appropriate Redis functionality enabled, it can:
Store embeddings.
Create vector indexes.
Search vectors.
Return the nearest vectors.
Combine vector searches with metadata filtering.
This makes Azure Managed Redis useful for applications such as:
Semantic search
Retrieval-augmented generation (RAG)
Recommendation systems
Semantic caching
Conversational memory
Document retrieval
Similarity matching
The major advantage is low-latency access, particularly when vector search is being performed alongside other Redis-based application data.
4. RediSearch and Vector Indexing
Azure Managed Redis uses the RediSearch functionality to provide vector search.
For Azure Managed Redis vector search, RediSearch must be enabled when the Redis instance is created. It cannot simply be added later to an existing instance.
Current Azure Managed Redis documentation identifies RediSearch support for:
Memory Optimized
Balanced
Compute Optimized
The Flash Optimized tier does not support RediSearch. Azure Managed Redis vector workloads also require the Enterprise clustering policy.
Exam tip
If a scenario says:
“An existing Azure Managed Redis instance does not have RediSearch enabled. The application now needs vector similarity search.”
The important consideration is that the required module must be enabled during provisioning. You should not assume that the module can simply be installed onto an existing Azure Managed Redis instance.
5. Storing Vectors in Redis
Azure Managed Redis supports storing vector data in Redis data structures such as:
Hashes
JSON documents
Hashes
Hashes are useful when the application has relatively straightforward fields.
Conceptually:
document:123
title = "Azure AI"
category = "AI"
embedding = [ ... ]
JSON
JSON can be useful when the application has more complex or nested document structures.
Conceptually:
{
"id":"document-123",
"title":"Azure AI",
"category":"AI",
"embedding":[ ... ],
"metadata":{
"author":"Norm",
"year":2026
}
}
The choice between hashes and JSON depends on the application’s data model and how the data will be accessed.
Microsoft’s current guidance specifically identifies both hashes and JSON as supported approaches for vector storage.
6. Why Metadata Matters
A vector should generally not exist by itself.
Applications often store metadata alongside the vector, such as:
Document ID
Document title
Category
Source URL
Timestamp
Tenant ID
Author
Security/access-control information
For example:
Document:
id = 1001
title = "Azure Container Apps"
category = "Azure"
tenant = "Contoso"
embedding = [...]
Metadata enables filtered vector search.
For example:
Find the 5 documents most similar to this question, but only search documents belonging to the Azure category.
Or:
Find similar documents that the current user is authorized to access.
This becomes particularly important in multi-tenant and RAG applications.
7. Vector Indexing Strategies
The two important vector indexing strategies you should know for AI-200 are:
Index
Description
Typical use
FLAT
Exact/brute-force search
Smaller datasets or maximum accuracy
HNSW
Approximate nearest-neighbor graph
Larger datasets and lower latency
Understanding the trade-off between these approaches is important for the exam.
8. FLAT Index
A FLAT index performs an exhaustive comparison.
Conceptually:
Query vector
|
+---- Compare with Vector 1
+---- Compare with Vector 2
+---- Compare with Vector 3
+---- Compare with Vector 4
+---- ...
+---- Compare with Vector N
Every candidate vector is evaluated.
Advantages
Exact search
High recall
Straightforward behavior
Useful for relatively small datasets
Disadvantages
More computationally expensive as the dataset grows
Latency can increase with the number of vectors
FLAT is therefore appropriate when exhaustive accuracy is more important than minimizing search computation.
9. HNSW Index
HNSW stands for Hierarchical Navigable Small World.
Instead of comparing the query against every vector, HNSW organizes vectors into a graph that allows the search to navigate toward likely nearest neighbors.
Conceptually:
Vector A
/ \
Vector B Vector C
/ \
Vector D Vector E
\ /
Vector F
The actual structure is considerably more sophisticated, but the important idea is that the index provides an efficient path toward nearby vectors.
Advantages
Fast similarity searches
Well suited to larger datasets
Reduces the amount of computation required
Supports approximate nearest-neighbor search
Disadvantages
Search is approximate rather than exhaustive
Indexing requires additional resources
There is a trade-off between search speed, recall, and resource consumption
Microsoft identifies HNSW as a common choice for larger datasets where lower latency is more important than exhaustive precision.
10. FLAT vs. HNSW
A useful way to remember the difference is:
FLAT = accuracy through exhaustive search
HNSW = speed through approximate search
For example:
Scenario A
You have 10,000 vectors and require exact results.
FLAT may be appropriate.
Scenario B
You have millions of vectors and require very low search latency.
HNSW is generally a better candidate.
The correct choice depends on:
Dataset size
Required latency
Accuracy/recall requirements
Available resources
Workload characteristics
11. Distance and Similarity Metrics
Once vectors are indexed, Redis needs a way to determine how close two vectors are.
Common metrics include:
Cosine
Cosine similarity measures the angle between vectors.
It is commonly used for text embeddings.
Conceptually:
Vector A
↘
angle
↗
Vector B
The smaller the angular difference, the more semantically similar the vectors generally are.
Euclidean / L2
Euclidean distance measures the straight-line distance between vectors.
A ●----------------● B
distance
A smaller distance indicates greater similarity.
Inner Product
Inner product, also called dot product in many contexts, can be used for similarity/ranking depending on how embeddings are generated and normalized.
The appropriate metric depends on the embedding model and how its vectors are represented.
12. KNN Search
A common vector-search operation is K-nearest neighbors (KNN).
Suppose the application asks:
“Which five documents are most similar to this question?”
The application sets:
K = 5
The vector search returns the five nearest vectors according to the selected similarity/distance metric.
Conceptually:
Query
|
+-- Result 1 ← most similar
+-- Result 2
+-- Result 3
+-- Result 4
+-- Result 5
KNN is especially useful in:
Semantic search
Recommendation systems
RAG
Similarity matching
Azure Managed Redis supports KNN and vector range queries.
13. Approximate Nearest Neighbor Search
ANN, or approximate nearest neighbor search, attempts to find vectors that are very close to the query without necessarily exhaustively comparing every vector.
This can dramatically reduce search latency and computational requirements.
The trade-off is:
You may sacrifice some recall for significantly better performance.
HNSW is an example of an indexing strategy commonly used to enable efficient approximate nearest-neighbor searches.
14. Vector Index Configuration
When creating a vector index, think about the following characteristics:
1. Data structure
Will the vectors be stored in:
Hashes?
JSON documents?
2. Vector field
Which property contains the embedding?
For example:
embedding
3. Vector dimensions
The index must accommodate the dimensionality of the embeddings.
4. Distance metric
Choose the appropriate metric, such as:
COSINE
L2
IP
5. Index algorithm
Choose between:
FLAT
HNSW
6. Metadata fields
Determine which fields need to support filtering.
15. Example Conceptual Data Model
Consider a RAG application containing technical documentation.
A Redis record might conceptually look like:
document:1001
title:
"Azure Container Apps"
category:
"Containers"
source:
"https://example.com/container-apps"
tenant:
"Contoso"
embedding:
[0.012, -0.081, 0.224, ...]
The application can then:
Receive a user’s question.
Generate an embedding for the question.
Submit the query vector to Redis.
Search the vector index.
Retrieve the closest documents.
Apply metadata/security filtering.
Send the retrieved content to the LLM.
Generate a grounded response.
16. Vector Search and RAG
Vector indexing is especially important for Retrieval-Augmented Generation (RAG).
A typical RAG pipeline looks like this:
DOCUMENT INGESTION
|
v
Split documents
|
v
Generate embeddings
|
v
Store vectors + metadata
|
v
Create vector index
|
|
USER QUERY
|
v
Generate query embedding
|
v
Vector similarity search
|
v
Apply metadata/security filters
|
v
Retrieve top K
|
v
Add retrieved context
|
v
LLM
|
v
Final response
The vector database does not generate the final natural-language response.
Its role is primarily retrieval.
17. Why Metadata Filtering Is Important in RAG
Suppose a company has documents belonging to multiple departments:
HR
Finance
Engineering
Legal
A user asks:
“What is our reimbursement policy?”
A pure vector search could potentially retrieve semantically relevant documents from multiple departments.
Instead, the application can use metadata:
department = "Finance"
or, more importantly:
tenant_id = current_user.tenant_id
and possibly:
access_level <= current_user.access_level
This helps ensure that retrieval is both relevant and appropriately scoped.
For RAG, metadata can also provide information needed to identify the source of retrieved content.
18. Hybrid Search
Vector search does not necessarily need to operate alone.
Azure Managed Redis can combine vector search with other search/filter capabilities, including:
Numeric filters
Text filters
Geospatial filters
Prefix matching
Fuzzy matching
Boolean conditions
This enables hybrid retrieval.
For example:
Find products semantically similar to this product, but only return products where category = 'laptop' and price < 1500.
The vector component handles semantic similarity while the metadata/filter component constrains the candidate results.
19. Choosing FLAT or HNSW
For the exam, think about the decision this way:
Choose FLAT when:
The dataset is relatively small.
Exact similarity results are important.
Exhaustive comparison is acceptable.
Search latency is less critical.
Choose HNSW when:
The dataset is large.
Low latency is important.
Approximate results are acceptable.
High-throughput vector search is required.
Do not assume that HNSW is always better. It is a trade-off.
20. Important Exam Considerations
When answering AI-200 questions involving Azure Managed Redis vector indexing, pay attention to these details.
RediSearch must be available
Vector search depends on the RediSearch functionality.
Vector indexing is different from ordinary Redis keys
A Redis key/value operation retrieves a known key. Vector indexing enables similarity-based retrieval.
HNSW is approximate
It is designed to improve search performance and reduce computation compared with exhaustive search.
FLAT is exhaustive
It compares the query against the indexed vectors rather than navigating an approximate graph.
Metadata is valuable
Metadata enables filtering and allows applications to associate retrieved vectors with meaningful application information.
Embedding compatibility matters
The query embedding and indexed embeddings need to be compatible with the index configuration.
Vector search is not generation
Redis retrieves relevant information. An LLM can subsequently use that information to generate a response in a RAG architecture.
21. Common Exam Traps
Trap 1: “HNSW always provides exact results”
Incorrect.
HNSW is an approximate nearest-neighbor approach.
Trap 2: “FLAT is always the best option”
Incorrect.
FLAT can become computationally expensive as the number of vectors increases.
Vector similarity determines semantic closeness. Metadata filters can constrain the search to the appropriate subset.
Trap 4: “The vector database generates the answer”
Incorrect.
The vector database retrieves relevant information. An LLM can use that retrieved information to generate the final response.
Trap 5: “Any embedding can be searched against any vector index”
Incorrect.
The embedding dimensions, representation, and similarity configuration need to be compatible.
Trap 6: “RediSearch can always be enabled later”
Incorrect for Azure Managed Redis provisioning.
Current Azure Managed Redis guidance states that required modules such as RediSearch need to be enabled when the instance is created.
22. AI-200 Exam Takeaways
Remember these concepts:
Concept
What to remember
Embedding
Numerical representation of semantic meaning
Vector
High-dimensional numerical representation
Vector index
Makes similarity searches efficient
RediSearch
Provides vector search capabilities
FLAT
Exact/exhaustive search
HNSW
Approximate nearest-neighbor search
KNN
Retrieves the K most similar vectors
ANN
Faster approximate similarity search
COSINE
Common metric for text embeddings
L2
Euclidean distance
IP
Inner-product similarity
Metadata
Enables filtering and contextual information
RAG
Retrieve relevant content before LLM generation
Hash
Redis structure suitable for vector + fields
JSON
Redis structure suitable for structured/nested vector records
Practice Exam Questions
Question 1
An AI application uses Azure Managed Redis to store 2 million document embeddings. The application requires very low-latency similarity searches and can tolerate a small reduction in recall in exchange for improved performance.
Which vector indexing strategy is most appropriate?
A. FLAT
B. HNSW
C. Hash-only retrieval
D. Key-based lookup
Answer: B
Explanation
HNSW is designed for approximate nearest-neighbor searches and is generally appropriate for larger datasets where low latency is important. It avoids exhaustive comparison with every vector and therefore can substantially reduce search work.
FLAT performs exhaustive searches and can become increasingly expensive as the number of vectors grows. A hash-only retrieval or normal key lookup cannot perform semantic vector similarity search.
Question 2
A development team has 5,000 product embeddings and requires exhaustive similarity comparisons because search accuracy is more important than minimizing computational cost.
Which indexing strategy should the team consider?
A. HNSW
B. FLAT
C. Boolean indexing
D. Prefix indexing
Answer: B
Explanation
FLAT performs an exhaustive comparison of the query vector against the indexed vectors. It is appropriate when the dataset is relatively small or when exhaustive accuracy is preferred.
HNSW is designed for approximate nearest-neighbor searches and trades some recall for performance.
Question 3
An application generates an embedding for a user’s question and wants to retrieve the five most semantically similar documents from Azure Managed Redis.
Which concept describes this operation?
A. Cache invalidation
B. Key-based lookup
C. K-nearest neighbors
D. Transaction processing
Answer: C
Explanation
K-nearest neighbors (KNN) retrieves the top K vectors that are closest to the query vector according to the configured similarity/distance metric.
With K = 5, the application requests the five nearest vectors.
Question 4
An organization stores document embeddings in Azure Managed Redis. Each document also contains a tenantId field. A RAG application must ensure that users retrieve documents only from their own tenant.
What is the primary purpose of the tenantId metadata?
A. Increasing the dimensionality of embeddings
B. Changing the embedding model
C. Replacing the vector index
D. Restricting vector retrieval to the appropriate tenant
Answer: D
Explanation
Metadata such as tenantId can be used to filter vector-search results so that retrieval is restricted to the appropriate tenant.
This is particularly important in multitenant AI and RAG applications where semantic similarity alone does not provide an authorization boundary.
Question 5
A team creates an Azure Managed Redis instance and later decides that it needs vector search. The instance was created without the required RediSearch functionality.
What should the team understand?
A. RediSearch must be enabled during instance provisioning
B. Vector search automatically becomes available when the first vector is stored
C. FLAT indexing eliminates the need for RediSearch
D. KNN automatically installs the required module
Answer: A
Explanation
Azure Managed Redis vector search requires RediSearch, and current Azure Managed Redis guidance states that the module must be enabled when the instance is created. Modules cannot simply be added to an existing instance afterward.
Question 6
An application uses text embeddings generated by an embedding model. Which consideration is most important when configuring the vector index?
A. The Redis key must contain the user’s password
B. The vector index must be compatible with the embedding dimensions and similarity configuration
C. Every embedding must be stored as plain text
D. The application must use FLAT regardless of dataset size
Answer: B
Explanation
The vector index needs to be configured consistently with the embeddings being generated. In particular, vector dimensions and the selected similarity metric need to be compatible with the embedding model and its vector representation.
Using an incompatible vector configuration can cause errors or poor search results.
Question 7
A RAG application retrieves documents from Azure Managed Redis using vector similarity search. What should happen after relevant documents are retrieved?
A. Redis automatically writes the final natural-language answer
B. The vector index generates a new embedding for every retrieved document
C. The retrieved content can be supplied to an LLM as grounding/context
D. The vectors are converted into relational database tables
Answer: C
Explanation
In a RAG architecture, vector search is the retrieval stage.
The application retrieves relevant content and supplies it as context to an LLM. The LLM then uses that context to generate the response.
The vector database does not itself generate the final natural-language answer.
Question 8
A team wants to find products semantically similar to a user’s query but only within the Laptops category.
Which approach best satisfies this requirement?
A. Perform only an exact key lookup
B. Delete all vectors outside the Laptops category
C. Use only the product title as the vector
D. Combine vector similarity search with a metadata filter
Answer: D
Explanation
Vector similarity identifies semantically similar products, while the metadata filter restricts results to the required category.
This is an example of combining vector retrieval with structured filtering.
Question 9
Which statement best describes the primary difference between FLAT and HNSW vector indexes?
A. FLAT performs exhaustive comparison, while HNSW uses an approximate graph-based approach
B. FLAT stores JSON while HNSW stores hashes
C. FLAT supports text only while HNSW supports vectors only
D. FLAT is used for metadata and HNSW is used for authentication
Answer: A
Explanation
The fundamental distinction is the search strategy.
FLAT performs exhaustive comparisons, while HNSW uses a graph-based approximate nearest-neighbor approach designed to improve search performance at scale.
The distinction is not based on whether the data is stored as hashes or JSON.
Question 10
An application uses Azure Managed Redis for vector similarity search. Which combination represents a valid vector-search design?
A. Store only Redis keys and perform exact string comparisons
B. Store embeddings, create a vector index, and query using a compatible similarity metric
C. Store embeddings only in application memory and use Redis for authentication
D. Store embeddings as passwords and use expiration to determine similarity
Answer: B
Explanation
A vector-search implementation requires embeddings to be stored, a compatible vector index to be created, and queries to use an appropriate similarity/distance configuration.
The other choices describe unrelated Redis capabilities and do not implement vector similarity search.
Final Exam Review
For “Implement vector indexing to enable similarity search”, the most important mental model is:
CONTENT
|
v
Embedding model
|
v
Vector embedding
|
v
+-------------------------+
| Azure Managed |
| Redis |
| |
| Vector + metadata |
| ↓ |
| Vector index |
| / \ |
| FLAT HNSW |
+-------------------------+
^
|
Query embedding
|
v
Similarity search
|
v
Top-K results
|
v
RAG / Application
If you remember only a handful of things for the exam, remember these:
RediSearch provides vector-search capabilities in Azure Managed Redis.
FLAT = exhaustive/exact search.
HNSW = approximate nearest-neighbor search optimized for performance.
KNN returns the top K similar vectors.
Cosine, L2, and inner product are important similarity/distance metrics.
Vectors should be compatible with the embedding model and index configuration.
Store metadata alongside vectors when applications need filtering or source information.
Vector search retrieves information; an LLM can use that information for RAG generation.
Vector search requires appropriate Redis provisioning, including RediSearch and supported configuration.
The right index is determined by dataset size, latency requirements, accuracy/recall requirements, and resource considerations.
