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 --> 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.
The Data Community 