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.
A company hosts an AI inference API in Azure Container Apps.
The current production revision is v17. A new revision, v18, contains a significant change to the inference pipeline.
The development team wants to:
deploy v18 without immediately sending all users to it,
send 5% of production traffic to v18,
monitor the new revision,
increase traffic gradually,
immediately return traffic to v17 if errors increase.
No changes should be made to the container image itself.
Which approach should you use?
A. Configure a KEDA scaler to maintain 5% of replicas on v18.
B. Create a new Container Apps revision and use revision traffic splitting.
C. Create a new ACR repository for v18 and configure both repositories as application replicas.
D. Deploy v18 as an AKS Deployment and use a Service to distribute traffic.
Answer: B
Explanation
Container Apps revisions are designed for versioned application deployments. Multiple revisions can coexist, and traffic can be assigned between revisions.
KEDA controls scaling, not deployment traffic percentages. ACR repositories store images, while moving the workload to AKS would introduce an unnecessary architecture change.
A particularly important distinction for AI-200 is:
Revision management controls application versions and traffic; KEDA controls scaling.
The current study guide explicitly calls out Container Apps environments, revision management, and KEDA event-driven scaling.
Question 2 — Scenario: ACR Image Lifecycle
A company has an ACR repository containing:
ai-api:1.0
ai-api:1.1
ai-api:1.2
ai-api:latest
Production deployments must always use an immutable version rather than a mutable tag such as latest.
The deployment pipeline should also be able to identify exactly which image version was deployed.
Which approach is best?
A. Deploy ai-api:latest and record the deployment timestamp.
B. Deploy ai-api:1.2 and use immutable image identification such as its digest for deployment traceability.
C. Rebuild the image every time the application starts.
D. Store the Dockerfile in Azure Key Vault and rebuild the image during deployment.
Answer: B
Explanation
A versioned tag is preferable to latest for predictable deployments, and an image digest provides stronger immutability because it identifies the exact image content.
Using latest makes it possible for the same deployment configuration to resolve to different image content later.
The question tests the distinction between image versioning and mutable deployment references, both relevant to the ACR portion of AI-200. The study guide explicitly includes generating, storing, versioning, and managing container images in ACR.
Question 3 — Scenario: KEDA Scaling
An AI document-processing application runs in Azure Container Apps.
The application consumes messages from a queue.
During peak periods:
Queue messages: 18,000
CPU utilization: 22%
Memory utilization: 31%
Application replicas: 2
Messages are waiting several minutes before being processed.
The application currently scales based only on CPU utilization.
What should you change?
A. Increase the CPU limit for each replica.
B. Configure KEDA-based event-driven scaling using the queue workload.
C. Configure a Container Apps revision with 100% traffic.
D. Move the queue data into ACR.
Answer: B
Explanation
CPU is not the appropriate workload signal here. The actual bottleneck is the growing queue.
KEDA allows Container Apps to scale according to an external event source, making it appropriate for queue-driven workloads.
This is exactly the type of diagnostic reasoning that AI-200 expects: identify the workload signal rather than automatically scaling based on CPU.
The current Microsoft objectives explicitly identify KEDA event-driven scaling in Container Apps.
Kubernetes manifests → declarative AKS resource configuration.
These distinctions are explicitly reflected in the current AI-200 containerization objectives.
Question 5 — Scenario: AKS Connectivity
An AI service is deployed to AKS.
The following observations have been made:
The Deployment reports the expected number of replicas.
Pods are in Running state.
Application logs show successful startup.
Requests through the application’s public endpoint fail.
Direct requests from within the pod to the application port succeed.
What should you investigate next?
A. The container registry’s image retention policy.
B. The Kubernetes Service, Ingress, selectors, and port mappings.
C. The application’s vector index.
D. The PostgreSQL connection pool.
Answer: B
Explanation
The evidence isolates the problem:
Container starts ✓
Application responds ✓
External access ✗
Therefore, the next layer to investigate is the connectivity path between the external endpoint and the pod.
Important areas include:
Service selectors
Service ports
target ports
Ingress configuration
ingress controller
routing/network configuration
The AI-200 study guide specifically calls for troubleshooting AKS and Container Apps by inspecting logs, events, and end-to-end connectivity.
Question 6 — Multiple Answers
A team wants to deploy the same containerized AI API to three environments:
Development
Test
Production
Which two practices are appropriate?
A. Build separate images solely because environment configuration differs.
B. Externalize environment-specific configuration.
C. Use environment variables/application settings where appropriate.
D. Embed production secrets in the Dockerfile.
Answers: B, C
Explanation
The same image should generally be reusable across environments.
Environment-specific configuration should be supplied externally, such as through application settings/environment variables or appropriate configuration services.
Production secrets should never be embedded in the image.
Microsoft explicitly includes configuring App Service to provide environment variables and secrets in the AI-200 objectives.
Question 7 — Scenario: AKS vs. Container Apps
A company is building an AI platform with these requirements:
Kubernetes manifests must be used.
The team needs direct access to Kubernetes resources.
Several specialized Kubernetes controllers will be installed.
The team already has substantial Kubernetes operational expertise.
Developers need Kubernetes-native workload configuration.
Which service should be selected?
A. Azure Container Apps
B. Azure App Service
C. Azure Functions
D. Azure Kubernetes Service
Answer: D
Explanation
The requirements explicitly depend on Kubernetes-native capabilities.
AKS is therefore the appropriate choice.
Container Apps provides a managed container application platform, but it intentionally abstracts away much of Kubernetes. When direct Kubernetes control is a requirement, AKS is the better fit.
The AI-200 objectives explicitly include deploying and managing AKS applications using manifest files.
Section 2 — Develop AI Solutions Using Azure Data Management Services
Question 8 — Cosmos DB Partitioning Scenario
An Azure Cosmos DB for NoSQL container stores documents for millions of customers.
The current partition key is:
/documentType
There are only a few document types, and one type contains approximately 80% of all documents.
The application experiences uneven request distribution and a heavily utilized partition.
What is the most likely underlying issue?
A. The partition key has poor cardinality and creates a hot partition.
B. The consistency level is necessarily too strong.
C. The vector embeddings are too large.
D. The container requires an Event Grid subscription.
Answer: A
Explanation
A good partition key should help distribute data and workload across logical partitions.
Using a low-cardinality property where one value dominates can result in uneven distribution and a hot partition.
This question is deliberately more architectural than simply asking which Cosmos DB query syntax to use.
Question 9 — Cosmos DB Query Optimization
A Cosmos DB query is:
SELECT*
FROM c
WHERE c.tenantId = @tenantId
AND c.status ="Active"
AND c.createdDate >= @date
ORDERBY c.createdDate DESC
The query executes frequently and consumes more RUs than expected.
The development team wants to investigate whether the indexing strategy matches the query workload.
What should they do?
A. Disable all indexing.
B. Examine the indexing policy and query characteristics, and optimize indexes for the actual query patterns.
C. Change the database to PostgreSQL.
D. Replace the query with an Event Grid event.
Answer: B
Explanation
Cosmos DB indexing is automatic by default, but indexing policies can be customized.
For performance-sensitive workloads, developers should understand which properties are being filtered/sorted and ensure that indexing aligns with query patterns rather than assuming that more indexing is always better.
Microsoft specifically identifies optimizing query performance and RU consumption through indexing policies and consistency levels.
Question 10 — Cosmos DB Change Feed Scenario
A document is inserted into Cosmos DB.
The application must automatically:
Detect the new document.
Generate an embedding.
Store the embedding.
Update a downstream search representation.
The application should not repeatedly query the entire container looking for new documents.
Which capability should be used?
A. Cosmos DB change feed processor
B. Cosmos DB strong consistency
C. Cosmos DB composite index
D. Redis expiration
Answer: A
Explanation
The change feed provides a mechanism for detecting changes to items.
A change feed processor can consume changes and drive downstream processing such as:
New document
↓
Change feed
↓
Embedding generation
↓
Vector storage
This is explicitly part of the AI-200 Cosmos DB objectives.
Question 11 — PostgreSQL Connection Optimization
An AI application creates a new PostgreSQL connection for every individual database operation.
Under heavy load, the application experiences:
high connection counts,
increased connection latency,
reduced throughput.
The database itself isn’t CPU-bound.
What should the developer investigate?
A. Connection pooling and connection reuse.
B. Increasing vector dimensionality.
C. Event Grid event filtering.
D. Cosmos DB consistency.
Answer: A
Explanation
Creating and tearing down database connections repeatedly introduces overhead.
Connection pooling and connection reuse can reduce connection establishment overhead and improve throughput and latency.
The current AI-200 study guide explicitly includes connection optimization to improve throughput and reduce latency for PostgreSQL.
Question 12 — PostgreSQL Vector Search
A RAG application stores:
document_id
tenant_id
document_type
content
embedding
Users should only retrieve documents belonging to their tenant.
The application needs semantic similarity retrieval.
Which approach should be implemented?
A. Search only on content.
B. Perform vector similarity search and apply the tenant metadata filter.
C. Use PostgreSQL connection pooling as the security boundary.
D. Use vector similarity scores as authorization decisions.
Queues are more appropriate for competing consumers where a message should normally be processed by one consumer.
Service Bus topics, subscriptions, messages, and dead-letter handling are part of the AI-200 objectives.
Question 17 — Service Bus Message Processing
A Service Bus worker receives a message and begins processing it.
The worker crashes before successfully completing the message operation.
What is the primary purpose of Service Bus message settlement/lock semantics in this situation?
A. To allow the message to be considered successfully processed without any acknowledgment.
B. To help prevent concurrent processing and allow unsuccessful processing to be retried according to the messaging semantics.
C. To convert the message into a vector embedding.
D. To permanently delete the message when the worker crashes.
Answer: B
Explanation
Service Bus supports message-lock and settlement concepts that help coordinate message processing.
A message isn’t simply considered successfully completed because a consumer received it.
If processing fails and the message isn’t successfully completed, it can become available for redelivery according to the applicable Service Bus behavior.
This is an important distinction between receiving and successfully completing a message.
Question 18 — Service Bus Dead-Letter Scenario
An AI processing service repeatedly receives a malformed message.
The message cannot be processed successfully.
The operations team wants failed messages separated from the normal processing path so that developers can inspect them later.
What should the application use?
A. Dead-letter queue
B. Redis cache
C. Event Grid custom event
D. Cosmos DB vector index
Answer: A
Explanation
The Service Bus dead-letter queue provides a dedicated location for messages that cannot be processed successfully or meet configured dead-lettering conditions.
It prevents a permanently problematic message from continuously interfering with normal processing.
Dead-letter queue management is explicitly included in AI-200.
Question 19 — Event Grid Filtering
A custom Event Grid topic receives:
DocumentUploaded
DocumentClassified
DocumentRejected
DocumentArchived
A subscriber is responsible only for rejected documents.
Which configuration minimizes unnecessary event delivery?
A. Increase the subscriber’s CPU.
B. Configure event subscription filtering.
C. Put all events into a Redis cache.
D. Use a Service Bus dead-letter queue.
Answer: B
Explanation
Event Grid subscription filters allow a subscriber to receive only events matching specified criteria.
Filtering is preferable to delivering every event and forcing the subscriber application to discard unwanted events.
Event filtering, custom events, and retries are explicitly listed in the current AI-200 objectives.
Question 20 — Event Grid Retry Scenario
An Event Grid subscriber is temporarily unavailable.
The publisher should not have to implement its own polling loop to repeatedly check whether the subscriber has recovered.
Which capability should be relied upon?
A. Event Grid retry behavior
B. Redis TTL
C. Cosmos DB consistency
D. AKS Horizontal Pod Autoscaler
Answer: A
Explanation
Event Grid provides delivery retry behavior for events that cannot initially be delivered successfully.
The purpose is to make event delivery more resilient to temporary endpoint failures.
Retry behavior is specifically included in the AI-200 Event Grid objectives.
Question 21 — Azure Functions Binding
A Function receives an HTTP request containing a document ID.
The Function must write a message to an Azure Service Bus queue.
The developer wants to use Azure Functions integration rather than manually implementing all of the Service Bus client code.
Which capability should be used?
A. HTTP trigger only
B. Service Bus output binding
C. Cosmos DB change feed
D. Event Grid event filter
Answer: B
Explanation
The HTTP trigger initiates function execution.
A Service Bus output binding can connect the function to the queue for output.
This illustrates the important distinction:
Trigger → causes execution
Binding → connects execution to data/services
Microsoft explicitly includes Functions triggers and bindings in the AI-200 objectives.
Question 22 — Fill in the Blank
Complete the statement:
An Azure Functions __________ determines what event or condition causes a function to execute.
Answer: trigger
Explanation
Examples include:
HTTP trigger
Service Bus trigger
Timer trigger
Event-based triggers supported by Functions
A binding is different: it provides a declarative connection to input or output data.
Question 23 — Scenario: Choosing Between Service Bus and Event Grid
An AI platform has these two requirements:
Requirement A
A document-processing job must be placed into a durable work queue. Multiple worker instances should compete for available jobs.
Requirement B
When processing completes, multiple independent systems should be notified that the document is complete.
Which design is best?
A. Event Grid for A and Redis for B
B. Service Bus queue for A and Event Grid for B
C. Redis queue for A and Cosmos DB change feed for B
D. Event Grid for both A and B
Answer: B
Explanation
Requirement A is a work-queue scenario:
Jobs → Service Bus queue → competing workers
Requirement B is an event notification/pub-sub scenario:
The distinction between messaging and event notification is important.
Microsoft’s AI-200 course specifically teaches both message-based and event-driven architectures using Service Bus and Event Grid.
Section 4 — Secure, Monitor, and Troubleshoot Azure Solutions
Question 24 — Key Vault and Application Identity
An Azure-hosted Function needs to retrieve a database password from Key Vault.
The security team prohibits storing a Key Vault credential in source code, configuration files, or the container image.
Which solution is most appropriate?
A. Embed the Key Vault credential in the Function package.
B. Store the password in App Configuration as plaintext.
C. Use an appropriate managed identity for the Function and grant it the required Key Vault access.
D. Put the password in an Event Grid event.
Answer: C
Explanation
A managed identity allows an Azure resource to authenticate to supported Azure services without the application having to maintain a long-lived credential for that identity.
Key Vault then remains responsible for storing the actual secret.
This follows the principle:
Application identity
↓
Key Vault authorization
↓
Secret retrieval
The AI-200 objectives explicitly include securing, rotating, and retrieving secrets using Key Vault.
Question 25 — App Configuration vs. Key Vault
An application has the following settings:
Feature:EnableSemanticCache = true
Feature:UseNewModel = false
AI:DeploymentName = gpt-production
Database:ConnectionPassword = ********
The team wants centralized configuration management while keeping secrets securely managed.
Which design is most appropriate?
A. Put all values in Key Vault.
B. Put all values in App Configuration.
C. Put non-secret configuration in App Configuration and secrets in Key Vault.
D. Put all values in environment variables inside the Docker image.
Answer: C
Explanation
App Configuration is intended for centralized application configuration.
Key Vault is intended for sensitive secrets.
Therefore:
App Configuration
├── feature flags/settings
├── deployment names
└── other non-secret configuration
Key Vault
└── passwords/API keys/secrets
The AI-200 study guide explicitly distinguishes the two capabilities.
Question 26 — Secret Rotation
A production AI service uses an API key stored in Key Vault.
The security team rotates the key regularly.
The development team wants the application to obtain the current secret without rebuilding or redeploying the container every time the key changes.
What design best meets the requirement?
A. Store the secret in the Dockerfile.
B. Store the secret in source control.
C. Retrieve the secret from Key Vault at runtime.
D. Put the secret into the container image during every deployment.
Answer: C
Explanation
Runtime retrieval separates the secret lifecycle from the application deployment lifecycle.
The container image remains unchanged while the secret can be rotated independently.
This is exactly the type of secret-management pattern targeted by AI-200.
Question 27 — OpenTelemetry Trace Analysis
An application exposes an HTTP endpoint.
A trace shows:
HTTP request 6,250 ms
│
├── Function execution 120 ms
├── Service Bus send 35 ms
├── PostgreSQL query 95 ms
├── Cosmos DB query 80 ms
└── External AI service 5,820 ms
The development team wants to reduce the endpoint’s response time.
What should they investigate first?
A. The external AI service call.
B. The Cosmos DB indexing policy.
C. The Service Bus queue’s dead-letter count.
D. The Docker image tag.
Answer: A
Explanation
The external AI service accounts for approximately 5.8 seconds of the 6.25-second request.
The trace therefore provides strong evidence that this dependency is the dominant contributor.
This is precisely why distributed tracing is valuable: it lets developers identify where time is being spent across service boundaries.
The AI-200 study guide specifically requires distributed tracing using OpenTelemetry SDKs.
Question 28 — KQL Interpretation
You have an AppRequests telemetry table containing:
TimeGenerated
DurationMs
Success
You need to identify the five-minute intervals during the last 30 minutes with the highest average request duration.
Which query is most appropriate?
A.
AppRequests
| where TimeGenerated > ago(30m)
| summarize AvgDuration = avg(DurationMs)
by bin(TimeGenerated, 5m)
| top 6 by AvgDuration desc
B.
AppRequests
| top 6 by DurationMs
C.
AppRequests
| summarize count() by Success
D.
AppRequests
| project TimeGenerated, DurationMs
Answer: A
Explanation
The requirement is to:
Restrict data to the last 30 minutes.
Group records into five-minute buckets.
Calculate average duration for each bucket.
Return the highest averages.
The query accomplishes all four.
Key KQL operators:
where → filters records.
bin() → creates time intervals.
summarize → aggregates.
avg() → calculates the average.
top → returns the highest values.
KQL analysis of logs and metrics is explicitly included in AI-200.
Question 29 — Multiple Answers: Troubleshooting
An AI application intermittently experiences slow requests.
Which two forms of telemetry would provide complementary information when diagnosing the problem?
A. Distributed traces showing the path and timing of individual requests.
B. Aggregate metrics showing latency, throughput, and error trends.
C. ACR image tags alone.
D. Dockerfile comments.
Answers: A, B
Explanation
Distributed traces answer questions such as:
“Where did this individual request spend its time?”
Metrics answer questions such as:
“Is latency increasing across the application?”
Using both provides a much stronger diagnostic picture than either alone.
OpenTelemetry distributed tracing and KQL-based analysis of logs and metrics are explicit AI-200 objectives.
Question 30 — Comprehensive Final Scenario
You are troubleshooting an AI document-processing platform:
HTTP API │ ▼ Azure Service Bus │ ▼ Azure Container Apps │ ┌────────┴────────┐ ▼ ▼ Cosmos DB PostgreSQL
The operations team reports:
HTTP requests remain fast.
The Service Bus queue backlog increases dramatically during peak periods.
Container Apps CPU averages only 25%.
Container Apps memory averages 35%.
PostgreSQL latency remains normal.
Cosmos DB RU consumption remains normal.
Distributed traces show that once processing begins, each document is processed normally.
The application currently uses CPU-based scaling for Container Apps.
The company wants to minimize processing delay while avoiding unnecessary compute costs.
Which two actions should you take?
A. Configure KEDA event-driven scaling based on the queue workload.
B. Increase PostgreSQL compute capacity.
C. Investigate the queue backlog as the workload signal and tune scaling thresholds accordingly.
D. Increase Cosmos DB consistency to Strong.
Answers: A, C
Explanation
The evidence strongly indicates a scaling-signal problem.
The important observations are:
Queue backlog HIGH
CPU LOW
Memory LOW
Database latency NORMAL
Processing time NORMAL
The processor is healthy once it receives work, but insufficient replicas are being created while work is waiting in the queue.
Therefore:
Use KEDA event-driven scaling based on the queue.
Tune the scaling configuration around the actual workload signal.
Increasing PostgreSQL capacity or Cosmos DB consistency would not address the observed bottleneck.
This scenario combines several AI-200 competencies:
Container Apps
KEDA
Service Bus
scalability
telemetry
troubleshooting
architecture reasoning
The current study guide specifically identifies KEDA scaling and troubleshooting using logs, events, and end-to-end connectivity.
A company operates an AI summarization API in Azure Container Apps.
Revision 12 is currently serving all production traffic. The development team deploys revision 13, which contains a new model-integration implementation.
The team wants to:
Send a small percentage of traffic to revision 13.
Compare its behavior with revision 12.
Increase traffic to revision 13 if testing is successful.
Roll back quickly if problems occur.
Which Azure Container Apps capability should be used?
A. KEDA scaling rules
B. Container Apps revisions and traffic splitting
C. Azure Container Registry Tasks
D. AKS Horizontal Pod Autoscaler
Answer: B
Explanation
Azure Container Apps revisions allow multiple versions of an application to coexist. Traffic can be distributed between revisions, making revisions appropriate for controlled rollouts, testing, and rollback scenarios.
KEDA addresses event-driven scaling, not deployment traffic management. ACR Tasks builds container images, while AKS-specific autoscaling mechanisms aren’t required for a Container Apps deployment.
Microsoft specifically includes Container Apps environment configuration and revision management in the AI-200 objectives.
Question 2 — Scenario-Based: ACR Tasks
A development team has the following workflow:
Git repository
↓
Dockerfile
↓
Container image
↓
Azure Container Registry
↓
Azure Container Apps
Every time a change is committed to the application’s source repository, the team wants Azure to automatically build the image and publish it to ACR.
The team does not want to maintain a build VM.
Which solution should you implement?
A. Azure Container Registry Tasks
B. Azure Functions with a timer trigger
C. Azure App Service deployment slots
D. Azure Managed Redis
Answer: A
Explanation
Azure Container Registry Tasks provide cloud-based automation for building container images and can be triggered by source-code changes.
This is preferable to creating a custom VM-based build process when the requirement is specifically automated container-image building.
ACR Tasks are explicitly included in the AI-200 containerization objectives.
Question 3 — AKS Manifest Troubleshooting
An AI application is deployed to AKS using a Kubernetes manifest.
The deployment contains:
a Deployment
a Service
an Ingress
The pods are running successfully and the container logs show that the application started correctly.
However, requests sent through the public endpoint return connection errors.
Which investigation is the most appropriate next step?
A. Change the Cosmos DB consistency level.
B. Rebuild the container image using ACR Tasks.
C. Inspect the Service, Ingress, port mappings, selectors, and end-to-end network path.
D. Increase the Redis cache expiration interval.
Answer: C
Explanation
The successful pod startup and application logs indicate that the problem is probably beyond the container’s basic startup process.
The next logical layer is the connectivity path:
Internet
↓
Ingress
↓
Service
↓
Pod
↓
Container port
Incorrect selectors, ports, ingress configuration, or networking can prevent an otherwise healthy pod from receiving external requests.
Microsoft specifically includes troubleshooting AKS and Container Apps by examining logs, events, and end-to-end connectivity.
Question 4 — Multiple Answers
A company deploys an AI API to Azure Container Apps.
The application experiences sudden bursts of requests generated by a backend messaging workload. CPU utilization isn’t a reliable indicator of pending work.
Which two capabilities are relevant to designing the scaling solution?
A. KEDA event-driven scaling
B. Container Apps revision management
C. An event-based scaler that responds to the workload source
D. Azure Container Registry image versioning
Answers: A, C
Explanation
KEDA provides event-driven autoscaling and can scale applications based on external event sources.
Revision management handles versions of the application but doesn’t determine how replicas are added based on workload.
ACR image versioning manages images rather than application replica counts.
The AI-200 study guide explicitly identifies KEDA event-driven scaling in Container Apps.
Question 5 — Scenario-Based: App Service Container Configuration
A containerized AI application is deployed to Azure App Service.
The same image must be deployed to development, test, and production environments.
Each environment has a different value for:
AI_ENDPOINT
MODEL_NAME
The development team wants to use the same image in all three environments.
Which approach is most appropriate?
A. Build a different container image for every environment.
B. Store environment-specific values in the Dockerfile.
C. Supply environment-specific configuration through App Service application settings/environment variables.
D. Create a separate Azure Container Registry for each environment.
Answer: C
Explanation
Environment-specific configuration should generally be separated from the container image.
App Service can supply application settings to the container, allowing the same image to run in different environments with different configuration.
This approach improves portability and prevents configuration values from becoming embedded in the image.
Microsoft specifically identifies configuring App Service to supply environment variables and secrets as an AI-200 objective.
Question 6 — Matching: Container Technologies
Match each requirement to the best Azure capability.
Requirement
Capability
1. Build container images in Azure based on source changes
A. Container Apps revisions
2. Run several application versions simultaneously
B. ACR Tasks
3. Automatically scale a containerized application based on an event source
C. KEDA
4. Deploy a Kubernetes application using declarative resource definitions
D. AKS manifests
Answers
1 → B
2 → A
3 → C
4 → D
Explanation
Each technology addresses a different part of the container lifecycle:
AKS manifests — declarative Kubernetes application configuration.
These capabilities correspond directly to the containerization objectives in the current AI-200 study guide.
Question 7 — Scenario-Based: Selecting AKS
A company has developed an AI inference platform consisting of multiple containerized components.
The architecture team requires:
Kubernetes APIs and resource definitions
Fine-grained Kubernetes workload configuration
Direct control over Kubernetes networking and workloads
The ability to manage Kubernetes resources through manifests
The team is willing to take on the additional operational responsibility associated with Kubernetes.
Which service should they select?
A. Azure Functions
B. Azure App Service
C. Azure Container Apps
D. Azure Kubernetes Service
Answer: D
Explanation
AKS is the appropriate choice when the architecture requires direct use of Kubernetes concepts, APIs, manifests, and Kubernetes workload management.
Container Apps provides a more managed abstraction over containerized application hosting and is preferable when the team doesn’t require direct Kubernetes control.
The AI-200 objectives explicitly include deploying and managing applications on AKS using manifest files.
Section 2 — Develop AI Solutions Using Azure Data Management Services
Question 8 — Cosmos DB Query Optimization
An application uses Azure Cosmos DB for NoSQL.
A query filters on:
customerId
status
createdDate
The query returns only a small number of documents, but its RU consumption is unexpectedly high.
The team discovers that the indexing policy was designed without considering the application’s actual query patterns.
What should the team investigate first?
A. The indexing policy and query execution characteristics
B. Azure Function trigger configuration
C. Event Grid retry settings
D. Container Apps revision traffic
Answer: A
Explanation
Cosmos DB indexing policies have a direct impact on query performance and RU consumption.
Rather than indiscriminately increasing provisioned throughput, developers should first examine query patterns and indexing configuration to determine whether the container is appropriately indexed.
The current AI-200 guide specifically includes optimizing Cosmos DB query performance and RU consumption using indexing policies and consistency levels.
Question 9 — Cosmos DB Change Feed
A document-ingestion application stores uploaded documents in Cosmos DB.
After each document is inserted or updated, a downstream process must:
Detect the change.
Extract information from the document.
Generate an embedding.
Store the embedding.
The downstream process should not continuously poll the entire container.
Which Cosmos DB capability is the best fit?
A. Strong consistency
B. Vector similarity search
C. Change feed processor
D. Composite indexing only
Answer: C
Explanation
The Cosmos DB change feed provides a mechanism for detecting changes to items in a container.
A change feed processor can consume those changes and invoke downstream processing without repeatedly scanning the entire container.
This is particularly useful in AI ingestion pipelines where document changes trigger embedding or enrichment operations.
The current AI-200 objectives explicitly include implementing a change feed processor.
Question 10 — Vector Search
A RAG application stores 1 million document chunks in Cosmos DB for NoSQL.
Each chunk contains:
documentId
tenantId
content
embedding
A user query is converted into an embedding.
The application must retrieve semantically similar chunks while restricting results to the user’s tenant.
Which approach is most appropriate?
A. Search the content property using exact string matching.
B. Perform vector similarity search and apply a tenant metadata filter.
C. Use the Cosmos DB change feed to retrieve matching documents.
D. Increase the container’s consistency level to Strong.
Answer: B
Explanation
Vector similarity search provides semantic retrieval based on embeddings.
The tenant filter ensures that candidate documents are restricted to the appropriate security boundary.
Increasing consistency does not implement semantic retrieval, and the change feed is for detecting data changes rather than answering semantic queries.
The AI-200 objectives specifically include storing/retrieving embeddings, vector similarity search, semantic retrieval, and RAG patterns.
Question 11 — PostgreSQL Schema Design
An AI application stores customer information and document embeddings in Azure Database for PostgreSQL.
The application frequently performs:
WHERE tenant_id = ?
AND document_type = ?
followed by vector similarity search over the resulting records.
Which design consideration is most important?
A. Put all values into a single unstructured text column.
B. Avoid indexes because vector search cannot use metadata.
C. Store metadata in appropriately typed relational columns and design indexes around the query pattern.
D. Store tenant IDs in Azure Key Vault.
Answer: C
Explanation
PostgreSQL provides relational modeling capabilities that should be used appropriately.
Metadata used for filtering should be stored in appropriately typed columns, and indexing strategies should reflect the actual query workload.
Vector search and metadata filtering can then be combined for RAG-style retrieval.
The current AI-200 guide specifically includes schema modeling, data types, indexing strategies, vector similarity search, and metadata filters.
Question 12 — PostgreSQL Vector Workload
A PostgreSQL-based AI application performs vector searches against a large embedding dataset.
Performance analysis shows that vector operations consume substantial CPU.
The development team wants to reduce pgvector compute overhead.
Which area should they investigate?
A. Vector indexing and query strategy
B. Event Grid event filtering
C. Key Vault secret rotation
D. Container Apps revision traffic
Answer: A
Explanation
Vector indexing and query strategy are key factors in the computational cost of pgvector workloads.
An appropriate indexing strategy can reduce the amount of vector computation required for searches.
The AI-200 study guide specifically calls out optimizing query latency and reducing pgvector compute overhead.
Question 13 — PostgreSQL Resource Configuration
A vector-search workload is consistently CPU-bound.
The database contains enough storage, but vector searches are slow under concurrent load.
Which resource should the development team investigate first?
A. Event Grid retry count
B. Container image size
C. PostgreSQL compute and memory resources
D. Azure Key Vault SKU
Answer: C
Explanation
Vector workloads can be computationally intensive. If the workload is CPU-bound, database compute resources should be evaluated.
The AI-200 objectives specifically include configuring compute, memory, and storage resources to support PostgreSQL vector workloads.
Question 14 — Azure Managed Redis
An AI application stores frequently requested retrieval results in Azure Managed Redis.
A cached result should no longer be used after 10 minutes.
Which mechanism should the application use?
A. Cosmos DB change feed
B. Redis key expiration/TTL
C. PostgreSQL vector index
D. Event Grid retry policy
Answer: B
Explanation
Redis supports expiration through TTL semantics.
An application can assign an expiration time to cached data so that stale entries are automatically removed or become unavailable after the specified period.
Caching, expiration, and invalidation are explicitly part of the AI-200 Azure Managed Redis objectives.
Question 15 — Multiple Answers: AI Data Services
A RAG application uses Azure data services.
Which two practices are appropriate?
A. Use vector similarity search for semantic retrieval.
B. Use metadata filtering to restrict candidate records.
C. Treat vector similarity as an authorization mechanism.
D. Store secrets directly in vector metadata.
Answers: A, B
Explanation
Vector similarity is appropriate for semantic retrieval, while metadata filtering can constrain retrieval to relevant records such as a tenant, document type, or access scope.
Vector similarity alone should not be treated as an authorization mechanism. Secrets also shouldn’t be embedded into searchable metadata.
The current AI-200 objectives explicitly include vector similarity search, semantic retrieval, and RAG patterns with metadata filtering.
Section 3 — Connect to and Consume Azure Services
Question 16 — Service Bus Messaging Architecture
An AI application processes financial documents.
Each submitted document must be processed by exactly one available worker. The system may have several worker instances running simultaneously.
If a worker fails while processing a message, the system needs the message to become available for processing again according to Service Bus messaging semantics.
Which messaging pattern is most appropriate?
A. A Service Bus queue with competing consumers
B. An Event Grid topic with three identical subscriptions
C. A Redis cache
D. A Cosmos DB vector index
Answer: A
Explanation
A Service Bus queue can support competing consumers, allowing multiple worker instances to process messages from the same queue.
This differs from a topic with multiple subscriptions, where each subscription receives its own copy of published messages.
Service Bus queues, messages, and dead-letter handling are part of the AI-200 objectives.
Question 17 — Dead-Letter Handling
A Service Bus message has repeatedly failed processing.
The development team does not want the same malformed message to continue consuming normal processing resources.
What should happen to the message?
A. It should be placed in a dead-letter queue according to the configured dead-lettering behavior.
B. It should automatically become a Cosmos DB vector.
C. It should be moved to Azure App Configuration.
D. It should be converted into an Event Grid subscription.
Answer: A
Explanation
Service Bus provides dead-letter queues for messages that cannot be successfully processed or meet configured dead-letter conditions.
Dead-lettering separates problematic messages from normal processing so they can be inspected, repaired, or handled separately.
Dead-letter queue handling is explicitly identified in the AI-200 study guide.
Question 18 — Event Grid vs. Service Bus
An AI system publishes the event:
DocumentAnalysisCompleted
Multiple independent applications need to react to the event.
One application updates analytics, another sends notifications, and another updates a search index.
The publisher should not need to know which applications consume the event.
Which service is the best fit?
A. Azure Service Bus queue
B. Azure Key Vault
C. Azure Event Grid
D. Azure Managed Redis
Answer: C
Explanation
Event Grid is designed for event-driven architectures in which publishers emit events and independent subscribers react to them.
Custom events, filtering, and retries are among the Event Grid capabilities identified in the AI-200 objectives.
Question 19 — Event Grid Filtering
An Event Grid custom topic receives:
DocumentUploaded
DocumentAnalyzed
DocumentRejected
A subscriber should receive only:
DocumentRejected
What should you configure?
A. A Redis TTL
B. An Event Grid event subscription filter
C. A Service Bus dead-letter queue
D. A Cosmos DB indexing policy
Answer: B
Explanation
Event Grid event subscriptions can filter events so that subscribers receive only the events relevant to them.
This prevents every subscriber from having to receive and discard unrelated events.
Filtering is explicitly included in the AI-200 Event Grid objectives.
Question 20 — Azure Functions Binding Design
An HTTP-triggered Azure Function receives a document-processing request.
The function should place a message onto a Service Bus queue without requiring the developer to manually create and manage the Service Bus client in the function’s application logic.
Which capability should the developer consider?
A. A Service Bus output binding
B. An Event Grid retry policy
C. A Cosmos DB vector index
D. An AKS manifest
Answer: A
Explanation
Azure Functions bindings provide declarative integration with external services.
An output binding can allow a function to write to a Service Bus queue without requiring the application code to manually implement all of the messaging client plumbing.
The AI-200 objectives specifically include Functions triggers and bindings.
Question 21 — Functions Trigger Selection
A serverless AI backend must execute whenever a message arrives in a Service Bus queue.
Which trigger should be selected?
A. HTTP trigger
B. Timer trigger
C. Service Bus trigger
D. Cosmos DB output binding
Answer: C
Explanation
A Service Bus trigger causes an Azure Function to execute when the associated Service Bus messaging event occurs.
The distinction is important:
Trigger → initiates function execution.
Binding → provides an input/output connection to another service.
Azure Functions triggers and bindings are explicitly part of the AI-200 objectives.
Question 22 — Multiple Answers
An application uses Azure Event Grid for an event-driven workflow.
Which two capabilities can be used to make the workflow more resilient and selective?
A. Event filtering
B. Event delivery retries
C. PostgreSQL pgvector indexes
D. Container Apps revisions
Answers: A, B
Explanation
Event filtering prevents irrelevant events from being delivered to a subscriber.
Retry behavior allows Event Grid to attempt delivery again when a subscriber endpoint temporarily fails.
Both are specifically included in the AI-200 Event Grid objectives.
Question 23 — Fill in the Blank
Complete the statement:
In Azure Functions, a __________ initiates function execution, while a binding provides a declarative connection to input or output data.
Answer: trigger
Explanation
A trigger defines the event that causes a function to execute.
For example, an HTTP trigger can execute a function when an HTTP request arrives, while a Service Bus trigger can execute a function when a message becomes available.
Bindings provide connections to external services and data.
This distinction is fundamental to the Functions portion of AI-200.
Section 4 — Secure, Monitor, and Troubleshoot Azure Solutions
Question 24 — Key Vault Security
An application retrieves an API key from Azure Key Vault.
The development team wants the application to access the secret without embedding a permanent credential for Key Vault inside the application source code.
Which approach is most appropriate?
A. Store the Key Vault credential in the container image.
B. Store the credential in the Git repository.
C. Use an appropriate Azure identity-based authentication mechanism and grant the application the required Key Vault permissions.
D. Put the credential in an Event Grid event.
Answer: C
Explanation
The goal is to avoid introducing another hard-coded secret while accessing Key Vault.
An Azure-hosted application can use an appropriate managed identity or other supported identity mechanism, with permissions scoped to the required Key Vault operations.
The AI-200 security objectives include secure secret storage, retrieval, and rotation using Key Vault.
Question 25 — Key Vault vs. App Configuration
A development team identifies the following values:
MaxRetries = 5
EnableNewRAGPipeline = true
ModelDeployment = "production"
DatabasePassword = "..."
ExternalApiKey = "..."
Which design is most appropriate?
A. Store all five values in Key Vault.
B. Store all five values in App Configuration.
C. Store non-sensitive configuration in App Configuration and sensitive values in Key Vault.
D. Store all five values in Redis.
Answer: C
Explanation
App Configuration is designed for application settings and configuration values.
Key Vault is designed for secrets such as passwords and API keys.
The distinction is important because configuration management and secret management serve different purposes.
Microsoft explicitly identifies both Key Vault and App Configuration in the AI-200 security objectives.
Question 26 — Secret Rotation
A security policy requires an AI service API key to be rotated periodically.
The application should always retrieve the current valid value rather than requiring a code deployment whenever the key changes.
Which architecture is most appropriate?
A. Hard-code the key in the application.
B. Store the key in Key Vault and retrieve it at runtime using an appropriate identity.
C. Put the key into an Event Grid event.
D. Bake the key into the Docker image during the build.
Answer: B
Explanation
Key Vault provides secure storage and retrieval of secrets and supports secret lifecycle management.
Separating the secret from the application binary/container image allows the secret to be rotated independently of application deployment.
Secret rotation and retrieval are explicitly listed in the AI-200 objectives.
Question 27 — OpenTelemetry Troubleshooting
A distributed AI application produces the following trace:
HTTP request 4.8 seconds
├── API processing 150 ms
├── Cosmos DB query 120 ms
├── PostgreSQL query 210 ms
└── AI inference service 4.1 seconds
Which conclusion is best supported by this telemetry?
A. The container image is too large.
B. Cosmos DB indexing is necessarily incorrect.
C. Service Bus dead-lettering is causing the latency.
D. The AI inference service is the dominant contributor to request latency.
Answer: D
Explanation
The trace shows approximately 4.1 seconds of the 4.8-second request duration being spent in the AI inference service.
Distributed traces are particularly valuable because they expose timing across service boundaries and help isolate latency contributors.
OpenTelemetry distributed tracing is explicitly part of the AI-200 monitoring objectives.
Question 28 — KQL
You are analyzing an application telemetry table called AppRequests.
You need to calculate the average request duration by five-minute interval during the last hour.
Which query is the most appropriate?
A.
AppRequests
| where TimeGenerated > ago(1h)
| summarize avg(DurationMs) by bin(TimeGenerated, 5m)
B.
AppRequests
| top 5 by DurationMs
C.
AppRequests
| project DurationMs
D.
AppRequests
| where DurationMs > 5000
Answer: A
Explanation
The query needs three operations:
Restrict the time range to one hour.
Group records into five-minute intervals.
Calculate the average duration within each interval.
bin(TimeGenerated, 5m) creates the required time buckets, and avg(DurationMs) calculates the average duration.
KQL analysis of logs and metrics is explicitly included in the AI-200 objectives.
Question 29 — Multiple Answers: Telemetry
A distributed AI application is experiencing intermittent latency.
Which two telemetry approaches would provide the most useful information for diagnosing the problem?
A. Distributed traces showing individual request paths
B. Metrics showing aggregate latency/request behavior
C. Container registry repository names
D. Docker image tags
Answers: A, B
Explanation
Distributed traces can show where individual requests spend time across service boundaries.
Metrics provide aggregate information about application behavior, such as latency, request rate, and error rates.
Image tags and registry repository names are useful deployment metadata but aren’t substitutes for runtime telemetry.
OpenTelemetry instrumentation and telemetry analysis are explicitly included in the current AI-200 study guide.
Question 30 — Comprehensive Scenario
A company operates an AI document-processing platform:
┌───────────────────────┐
│ HTTP API │
│ Azure Functions │
└───────────┬───────────┘
│
▼
Azure Service Bus
│
▼
Containerized processor
│
┌─────────────┴─────────────┐
▼ ▼
Cosmos DB PostgreSQL
documents vector search
│
▼
Embedding data
The application has recently experienced intermittent failures.
The team observes:
The HTTP API responds quickly.
Service Bus message counts occasionally increase significantly.
Container processor CPU usage is low.
PostgreSQL latency remains normal.
Distributed traces show that some messages wait several minutes before processing begins.
The application currently scales the processor based primarily on CPU utilization.
What should the team implement to address the primary bottleneck?
A. Increase PostgreSQL compute.
B. Increase Cosmos DB consistency.
C. Implement event-driven scaling for the container processor based on the messaging workload.
D. Increase OpenTelemetry sampling.
Answer: C
Explanation
The most important clues are:
Service Bus backlog increases.
CPU remains low.
Messages wait before processing.
The current scaling strategy is CPU-oriented.
The processor therefore isn’t scaling in response to the actual workload.
For a containerized application running in Azure Container Apps, KEDA-based event-driven scaling can scale replicas according to an external event source or workload metric.
Increasing PostgreSQL resources would not address the observed queue backlog because PostgreSQL latency is normal.
OpenTelemetry has already provided useful diagnostic information, but increasing sampling would not resolve the scaling problem.
This question combines the AI-200 containerization, messaging, monitoring, and troubleshooting objectives and represents the type of cross-topic reasoning expected from an experienced Azure developer.
Section 1 — Develop Containerized Solutions on Azure
Questions 1–7
Question 1 — Scenario-Based: Azure Container Apps
A company has developed an AI inference service as a container image.
The application has the following requirements:
It must run continuously while requests are being processed.
It should scale horizontally when request volume increases.
The team does not want to manage Kubernetes control planes or nodes.
The application will eventually have multiple versions running during controlled releases.
The team wants to use container images stored in Azure Container Registry.
Which Azure service is the best hosting platform?
A. Azure Kubernetes Service B. Azure Functions C. Azure Container Apps D. Azure Storage static website
Answer: C
Explanation
Azure Container Apps is designed for running containerized applications without requiring the development team to manage Kubernetes infrastructure directly. It supports container images, scaling, revisions, and environment configuration.
AKS would provide considerably more Kubernetes control, but it also introduces additional management responsibilities. Azure Functions is appropriate for serverless functions rather than a continuously running containerized service of this type.
The AI-200 objectives specifically include deploying containers to Container Apps, configuring environments, managing revisions, and implementing event-driven scaling with KEDA.
Question 2 — Azure Container Registry Tasks
A development team has a Dockerfile stored in a Git repository.
Whenever changes are committed to the repository, the team wants Azure to automatically build a new container image and push it to Azure Container Registry.
The team does not want to maintain a dedicated build server.
Which solution should you implement?
A. Configure an Azure Container Registry Task with a source-code trigger B. Create an AKS CronJob that executes Docker C. Configure an App Service deployment slot D. Create an Azure Function with a timer trigger that builds the image
Answer: A
Explanation
Azure Container Registry Tasks can automate container image builds in Azure. They can be triggered by source-code changes and can build and push images to ACR.
The important distinction is that ACR Tasks are specifically designed for container image build automation. App Service slots and Azure Functions don’t provide the same purpose-built container build capability.
ACR Tasks are explicitly part of the AI-200 containerization objectives.
Question 3 — AKS Deployment Troubleshooting
You deploy an AI API to AKS using a Kubernetes deployment manifest.
The deployment reports that the pods have been created, but the application is inaccessible from outside the cluster.
You verify that:
The container image can be pulled.
The pods are running.
The application process is listening on the expected container port.
What should you investigate next?
A. The Azure Container Registry retention policy B. The PostgreSQL connection pool C. The Cosmos DB indexing policy D. The Kubernetes Service and ingress/network configuration
Answer: D
Explanation
If the pods are running and the application is listening correctly, the next logical area is connectivity between the pods and external clients.
In AKS, this can involve the Kubernetes Service, ingress configuration, ports, selectors, networking, and related resources.
The AI-200 study guide specifically calls out monitoring and troubleshooting AKS and Container Apps by inspecting logs, events, and end-to-end connectivity.
Question 4 — Multiple Answers
An application is deployed to Azure Container Apps.
The application has two revisions:
Revision A — currently serving production traffic
Revision B — newly deployed version
The development team wants to validate Revision B before directing production traffic to it.
Which two capabilities are relevant?
A. Azure Container Registry Tasks B. Container Apps revision management C. Revision traffic management D. Cosmos DB change feed
Answers: B, C
Explanation
Azure Container Apps supports revisions, allowing different versions of an application to coexist. Traffic can be managed between revisions, supporting controlled deployments and testing.
ACR Tasks handles container image builds and is not responsible for Container Apps traffic management.
Microsoft explicitly includes revision management in the AI-200 Container Apps objectives.
Question 5 — Container Apps Scaling
An AI application receives requests through an event-driven architecture.
Under normal conditions, there may be only a few messages waiting to be processed. During business events, thousands of messages may accumulate.
The application should automatically create additional container replicas when the message workload increases.
Which capability is most appropriate?
A. App Service deployment slots B. ACR geo-replication C. KEDA-based event-driven scaling D. AKS node autoscaling only
Answer: C
Explanation
KEDA—Kubernetes Event-driven Autoscaling—allows Container Apps to scale based on external event sources and metrics.
This differs from simply scaling based on CPU or memory. A queue-length or other event-based workload is a classic use case for event-driven scaling.
The AI-200 study guide specifically identifies KEDA as the mechanism for event-driven scaling in Container Apps.
Question 6 — Multiple Answers
You are diagnosing a failing AKS deployment.
Which two sources should you inspect to help determine why the application is not behaving as expected?
A. Kubernetes/application logs B. Kubernetes events C. Azure App Configuration feature flags only D. PostgreSQL vector indexes
Answers: A, B
Explanation
Application and container logs can reveal runtime failures, exceptions, and startup problems. Kubernetes events can reveal scheduling problems, image-pull failures, probe failures, container restarts, and other cluster-level conditions.
The AI-200 objectives explicitly include inspecting logs and events when troubleshooting AKS and Container Apps.
Question 7 — App Service Container Configuration
A containerized AI API runs on Azure App Service.
The application requires a configuration value named AI_ENDPOINT and a sensitive value named API_KEY.
The development team wants these values supplied to the container as environment variables rather than hard-coded into the image.
Which approach is most appropriate?
A. Configure App Service application settings/environment variables and use a secure secret-management approach for the sensitive value B. Add both values directly to the Dockerfile C. Store both values in the container image metadata D. Put both values in the ACR repository name
Answer: A
Explanation
App Service can supply application configuration to a container through application settings/environment variables. Sensitive values should not be baked into the container image.
The AI-200 study guide specifically includes configuring App Service to supply environment variables and secrets.
Section 2 — Develop AI Solutions Using Azure Data Management Services
Questions 8–15
Question 8 — Cosmos DB Consistency and RU Consumption
An AI application uses Azure Cosmos DB for NoSQL.
The application does not require every read to immediately reflect the latest write. However, it performs a very large number of reads, and the development team wants to optimize the workload’s consistency/performance tradeoff.
Which Cosmos DB configuration area should they investigate?
A. Container Apps revision settings B. Consistency level C. Azure Functions trigger type D. Event Grid retry policy
Answer: B
Explanation
Cosmos DB consistency levels determine the guarantees provided when reading data. Stronger consistency generally involves different performance and availability tradeoffs than weaker consistency levels.
The AI-200 study guide explicitly includes optimizing Cosmos DB query performance and RU consumption by using indexing policies and consistency levels.
Question 9 — Cosmos DB Query Optimization
A Cosmos DB query frequently filters documents using a property called departmentId.
The query is expensive and consumes more RUs than expected.
The development team discovers that the property is excluded from the container’s indexing policy.
What should they consider doing?
A. Increase the Service Bus lock duration B. Create a KEDA scaler C. Move the documents to Azure Managed Redis D. Modify the indexing policy to appropriately index the property
Answer: D
Explanation
Cosmos DB indexing policies determine which paths are indexed and therefore influence query execution and RU consumption.
If a frequently filtered property isn’t appropriately indexed, changing the indexing policy may improve query performance and reduce unnecessary RU consumption.
Indexing policies are explicitly part of the AI-200 Cosmos DB objectives.
Question 10 — Cosmos DB Vector Search
An AI application stores the following document:
{
"id": "doc-1024",
"tenantId": "contoso",
"text": "Azure provides cloud-based AI services...",
"embedding": [ ... ]
}
The application receives a query embedding and needs to retrieve semantically similar documents.
Which capability should be implemented?
A. Cosmos DB vector similarity search B. Cosmos DB change feed only C. Azure Functions timer trigger D. Service Bus topic filtering
Answer: A
Explanation
The embedding represents the semantic characteristics of the document. Vector similarity search compares the query embedding with stored embeddings to identify semantically similar content.
This is a core AI workload supported by Cosmos DB for NoSQL and is explicitly included in the AI-200 objectives.
Question 11 — Scenario-Based RAG
A RAG application stores documents for multiple customers in Azure Database for PostgreSQL.
Each vector record includes:
tenant_id
document_type
content
embedding
A user from tenant A asks a question.
The application must ensure that results from tenant B are never returned, even if tenant B contains documents that are more semantically similar.
Which approach should be used?
A. Increase vector dimensions B. Perform vector similarity search with a metadata filter for tenant_id C. Use Event Grid to filter documents D. Store tenant IDs in Azure Key Vault
Answer: B
Explanation
The vector search provides semantic similarity, while the metadata filter constrains the candidate records to the correct tenant.
This is especially important in multi-tenant RAG architectures. Semantic similarity alone should not be treated as an authorization boundary.
The AI-200 study guide specifically includes RAG patterns using vector search with metadata filters.
Question 12 — PostgreSQL Performance
An application performs thousands of short database operations against Azure Database for PostgreSQL.
Performance testing shows that establishing a new database connection for every request introduces significant latency.
Which optimization should be considered?
A. Increase the number of Event Grid subscriptions B. Use connection pooling or otherwise optimize connection reuse C. Replace PostgreSQL with ACR D. Store all database credentials in source code
Answer: B
Explanation
Creating and tearing down database connections repeatedly introduces overhead. Connection pooling allows connections to be reused across operations, improving throughput and reducing connection-establishment latency.
Connection optimization is explicitly listed in the current AI-200 study guide.
Question 13 — Azure Managed Redis
An AI application repeatedly retrieves the same expensive results from a backend data service.
The results can safely remain cached for five minutes.
After five minutes, the application should retrieve fresh data.
Which Azure Managed Redis capability is most directly applicable?
A. Change feed processing B. PostgreSQL vector indexing C. Service Bus dead-lettering D. Key expiration/TTL
Answer: D
Explanation
Redis supports expiration/TTL semantics, allowing cached data to automatically expire after a specified period.
This is useful when data should remain cached temporarily but must eventually be refreshed.
The AI-200 objectives specifically include caching, expiration, and invalidation using Azure Managed Redis.
Question 14 — Multiple Answers
An AI application uses Azure Managed Redis.
Which two capabilities are directly relevant to AI workloads covered by AI-200?
A. Vector indexing for similarity search B. Caching frequently accessed data C. Kubernetes manifest deployment D. Azure Function trigger execution
Answers: A, B
Explanation
Azure Managed Redis can be used for low-latency caching and supports vector storage/indexing capabilities for AI scenarios.
Kubernetes manifests belong to AKS, while Function triggers belong to Azure Functions.
The current AI-200 study guide specifically identifies Redis caching, expiration/invalidation, and vector indexing.
Question 15 — Matching: AI Data Services
Match each requirement to the best Azure technology.
Requirement
Technology
1. Detect newly inserted or modified Cosmos DB items
A. Azure Managed Redis
2. Perform relational vector search using PostgreSQL
B. Azure Cosmos DB change feed
3. Cache frequently accessed AI results with expiration
C. Azure Database for PostgreSQL with pgvector
4. Perform low-latency vector operations in Redis
D. Azure Managed Redis vector capabilities
Answers
1 → B
2 → C
3 → A
4 → D
Explanation
The Cosmos DB change feed is designed to detect item changes. PostgreSQL can use pgvector for vector workloads. Managed Redis provides low-latency caching and expiration as well as vector capabilities.
These capabilities map directly to the data-management objectives in the current AI-200 guide.
Section 3 — Connect to and Consume Azure Services
Questions 16–23
Question 16 — Service Bus vs. Event Grid
An AI application needs reliable asynchronous processing of individual work items.
Each work item represents a document that must be processed exactly as part of an application workflow. If processing fails, the message must remain available for retry or dead-letter handling.
Which service is the better fit?
A. Event Grid B. Azure App Configuration C. Azure Managed Redis D. Azure Service Bus
Answer: D
Explanation
Azure Service Bus is designed for enterprise messaging and reliable asynchronous processing. It supports queues, topics, subscriptions, message handling, and dead-letter queues.
Event Grid is primarily an event-routing service for reactive architectures. When the requirement centers on reliable message processing and dead-letter handling, Service Bus is generally the better fit.
These capabilities are explicitly included in the AI-200 messaging objectives.
Question 17 — Service Bus Topic Architecture
An AI document-processing application publishes a single event whenever a document is processed.
Three independent applications need to react to the event:
Billing
Analytics
Notification
Each application must independently receive the events.
Which Service Bus architecture should you use?
A. A topic with separate subscriptions B. A single queue consumed by all applications C. A Redis key with a five-minute expiration D. A Function timer trigger
Answer: A
Explanation
A Service Bus topic allows a publisher to send messages once while multiple subscriptions independently receive messages.
This is appropriate when several consumers need their own copy/stream of messages.
Queues are more appropriate when competing consumers share work rather than when independent applications each need to receive the published message.
Topics and subscriptions are explicitly part of the AI-200 objectives.
Question 18 — Event Grid Filtering
A custom Event Grid topic receives events from several types of AI processing operations.
A downstream service should receive only events where:
eventType = "DocumentAnalysisCompleted"
What should you configure?
A. A Service Bus dead-letter queue B. An App Service deployment slot C. An Event Grid event subscription with filtering D. A Cosmos DB indexing policy
Answer: C
Explanation
Event Grid subscriptions can use event filtering to restrict which events are delivered to a subscriber.
This allows a publisher to emit multiple event types while individual consumers receive only events relevant to them.
Event Grid filters, custom events, and retry behavior are explicitly listed in the AI-200 objectives.
Question 19 — Event Grid Retry Behavior
An Event Grid subscriber’s endpoint is temporarily unavailable.
The application should allow Event Grid to attempt delivery again rather than permanently losing the event immediately.
Which Event Grid capability should you configure?
A. Vector indexing B. Event delivery retry policy C. Container Apps revision D. Cosmos DB consistency level
Answer: B
Explanation
Event Grid provides retry capabilities for event delivery. Retry configuration allows applications to tolerate temporary endpoint failures.
Retry behavior is distinct from Service Bus dead-lettering. Service Bus is designed around reliable messaging and message processing, while Event Grid provides event routing with retry and delivery semantics.
The AI-200 study guide explicitly identifies Event Grid retries as an exam objective.
Question 20 — Azure Functions Architecture
An AI backend must expose an HTTP endpoint:
POST /documents
The endpoint accepts a document and places a processing request onto a Service Bus queue.
The backend should be serverless.
Which Azure Functions design is most appropriate?
A. Timer-triggered function that polls the HTTP endpoint B. Event Grid-triggered function with a Redis output C. Cosmos DB change-feed function D. HTTP-triggered function with a Service Bus output binding
Answer: D
Explanation
An HTTP trigger can expose the API endpoint. A Service Bus output binding can then send the processing message to a queue.
This design avoids unnecessary polling and allows the HTTP-facing function to remain lightweight while the actual document processing happens asynchronously.
The AI-200 objectives include serverless APIs, triggers, bindings, and function-app deployment.
Question 21 — Azure Functions Trigger vs. Binding
A developer creates an Azure Function that should execute whenever a new message arrives in a Service Bus queue.
Which component determines when the function executes?
A. Trigger B. Output binding C. Application setting D. Deployment slot
Answer: A
Explanation
The trigger defines the event that causes the function to execute.
A binding provides a declarative connection between the function and another service or data source. The trigger is therefore the component responsible for initiating execution.
Triggers and bindings are explicitly included in the AI-200 Functions objectives.
Question 22 — Multiple Answers
A development team is choosing between Azure Service Bus and Event Grid for an AI backend.
Which two statements are correct?
A. Service Bus is appropriate for reliable message-based processing. B. Event Grid is designed for event-driven routing and supports event filtering. C. Event Grid replaces Azure Key Vault for secret storage. D. Service Bus is primarily a container image registry.
Answers: A, B
Explanation
Service Bus provides messaging capabilities such as queues, topics, subscriptions, and dead-letter queues.
Event Grid provides event routing and supports capabilities such as custom events, filtering, and retries.
Neither service is a secret-management or container-registry service.
Question 23 — Fill in the Blank
Complete the statement:
In Azure Functions, a __________ defines the event or condition that causes a function to execute, while a binding provides a connection to input or output data.
Answer: trigger
Explanation
A Function trigger determines when the function executes. Bindings simplify access to external resources and can provide input or output data.
Understanding this distinction is fundamental to designing serverless AI backends with Azure Functions.
Section 4 — Secure, Monitor, and Troubleshoot Azure Solutions
Questions 24–30
Question 24 — Key Vault Secret Rotation
An AI application uses an API key stored in Azure Key Vault.
The security team requires the secret to be rotated periodically without requiring developers to modify application source code.
Which approach best addresses the requirement?
A. Implement secret rotation and have the application retrieve the current secret from Key Vault B. Store a second copy of the secret in the Dockerfile C. Put the secret in an Event Grid event D. Store the secret as a PostgreSQL vector
Answer: A
Explanation
Key Vault is designed to securely store secrets and supports secret lifecycle management. Applications can retrieve the current value rather than embedding secrets in source code or container images.
The current AI-200 study guide specifically includes secret rotation and retrieval using Azure Key Vault.
Question 25 — Key Vault vs. App Configuration
An application has the following configuration:
MaxDocumentsPerRequest = 25
EnableSemanticSearch = true
DatabaseConnectionPassword = [secret]
AIServiceApiKey = [secret]
Which approach is most appropriate?
A. Store everything in Azure Container Registry B. Store everything in Azure App Configuration C. Store non-secret configuration in App Configuration and secrets in Key Vault D. Store everything in Service Bus
Answer: C
Explanation
Azure App Configuration is designed for centralized application settings and configuration.
Azure Key Vault is designed for sensitive values such as passwords and API keys.
Separating ordinary configuration from secrets provides a more appropriate security and configuration-management architecture.
Both services are explicitly included in the AI-200 security objectives.
Question 26 — OpenTelemetry
A distributed AI application has this request path:
Client
↓
API
↓
Document service
↓
PostgreSQL
↓
AI inference service
Users report that some requests take 8–10 seconds.
The development team needs to determine which component contributes most of the latency for each individual request.
Which capability is most appropriate?
A. OpenTelemetry distributed tracing B. ACR image replication C. Cosmos DB change feed D. Service Bus topic filtering
Answer: A
Explanation
Distributed tracing allows developers to follow a request through multiple services and identify where time is being spent.
OpenTelemetry provides standardized instrumentation for collecting telemetry across distributed applications.
The AI-200 study guide specifically identifies tracing distributed systems using OpenTelemetry SDKs.
Question 27 — KQL
You have an Azure Monitor Logs table called AppRequests.
You need to find the 10 slowest requests from the previous hour.
Which query is the best starting point?
A.
AppRequests
| summarize count()
B.
AppRequests
| where TimeGenerated > ago(1h)
| summarize avg(DurationMs)
C.
AppRequests
| project DurationMs
D.
AppRequests
| where TimeGenerated > ago(1h)
| top 10 by DurationMs desc
Answer: D
Explanation
The query needs to:
Restrict records to the previous hour.
Sort/select the highest-duration requests.
Return only the top 10.
top 10 by DurationMs desc directly satisfies the requirement.
KQL is explicitly part of the AI-200 monitoring objectives for analyzing logs and metrics.
Question 28 — Multiple Answers
You instrument an AI application with OpenTelemetry.
Which two types of telemetry are particularly useful when diagnosing performance problems in a distributed application?
A. Container image tags B. Traces C. Metrics D. ACR repository names
Answers: B, C
Explanation
Traces can show the path and timing of individual requests across distributed services.
Metrics can reveal aggregate measurements such as latency, request rates, error rates, or resource-related behavior.
Container image tags and ACR repository names are deployment metadata rather than the primary telemetry types used for distributed performance analysis.
OpenTelemetry and telemetry analysis are explicitly included in the AI-200 monitoring objectives.
Question 29 — KQL Scenario
An AI application has started returning HTTP 500 errors.
You want to determine whether the errors increased significantly during the last 30 minutes.
Which KQL query is the most useful starting point?
A.
AppRequests
| where TimeGenerated > ago(30m)
| summarize count() by bin(TimeGenerated, 5m), ResultCode
B.
AppRequests
| project TimeGenerated
C.
AppRequests
| summarize avg(DurationMs)
D.
AppRequests
| top 1 by TimeGenerated
Answer: A
Explanation
The query:
restricts data to the last 30 minutes,
groups data into five-minute intervals,
separates results by HTTP result code,
and counts the requests.
This allows the development team to observe whether HTTP 500 responses increased during particular time intervals.
The ability to write KQL queries to analyze logs and metrics is part of the current AI-200 study guide.
Question 30 — Scenario-Based Troubleshooting
An AI API is running in Azure Container Apps.
The application works correctly under light load. Under heavy load, however:
request latency increases significantly,
CPU usage remains relatively low,
the application receives work from a messaging system,
and the number of pending messages increases continuously.
The development team wants the application to automatically add replicas based on the workload rather than CPU utilization.
What should you implement?
A. KEDA event-driven scaling based on the messaging workload B. A larger Azure Container Registry SKU C. A stronger Cosmos DB consistency level D. OpenTelemetry sampling alone
Answer: A
Explanation
The critical clue is that the workload is message-driven and the backlog is increasing while CPU utilization remains low.
CPU-based autoscaling would not necessarily respond appropriately. KEDA allows Container Apps to scale based on event-driven workload characteristics, such as the number of pending messages.
OpenTelemetry could help diagnose the latency, but instrumentation alone would not automatically add replicas.
KEDA-based event-driven scaling is explicitly identified in the AI-200 containerized-solutions objectives.
Section 1 — Develop Containerized Solutions on Azure
Questions 1–7
Question 1 — Single Answer
You are developing an AI-powered document-processing application. The application is packaged as a Docker image and must be deployed to Azure App Service.
The development team wants App Service to retrieve the image from Azure Container Registry (ACR).
Which configuration is required?
A. Configure the App Service container settings to use the ACR image and provide the required registry authentication B. Create an Azure Service Bus subscription between ACR and App Service C. Configure an Event Grid subscription that automatically converts the image into an App Service package D. Store the Docker image in Azure Blob Storage and configure App Service to mount the blob
Answer: A
Explanation: Azure App Service can run containerized applications using images stored in a container registry such as ACR. The App Service must be configured with the appropriate container image and registry authentication. A Service Bus subscription or Event Grid subscription is not required simply to deploy the image.
Question 2 — Single Answer
A development team wants to automatically build a container image whenever source code is committed. They want the container image to be built directly within Azure without maintaining a dedicated build server.
Which Azure Container Registry capability should you use?
A. ACR replication B. Azure Container Registry Tasks C. Azure Container Apps revisions D. AKS Jobs
Answer: B
Explanation: Azure Container Registry Tasks can automate container image builds and related tasks. They can build images in Azure and can be integrated with source-control or registry workflows. This eliminates the need to maintain a dedicated build environment for the image-building process.
Question 3 — Scenario-Based, Single Answer
A company deploys an AI inference API to Azure Container Apps.
The application receives normal traffic throughout the day, but occasionally receives bursts of messages from an Azure messaging system. The company wants the number of application instances to automatically increase based on the number of pending messages.
Which capability should you use?
A. Container Apps revision traffic splitting B. Azure App Service autoscale rules based on CPU C. Kubernetes Event-driven Autoscaling (KEDA) D. Azure Container Registry Tasks
Answer: C
Explanation: Azure Container Apps supports event-driven scaling through KEDA. KEDA allows scaling decisions to be based on external event sources, such as message queues, rather than relying solely on CPU or memory utilization.
Question 4 — Multiple Answers
You are troubleshooting an application running in Azure Container Apps.
Which two actions can help diagnose application problems?
A. Inspect application logs B. Inspect container/application events C. Change the Cosmos DB consistency level D. Create a Service Bus topic
Answers: A, B
Explanation: Container Apps troubleshooting can involve examining logs and events associated with the application and its containers. Changing Cosmos DB consistency or creating a Service Bus topic does not directly diagnose a Container Apps deployment problem.
Question 5 — Matching
Match each Azure container technology or feature with the most appropriate description.
Technology
Description
1. Azure Container Registry
A. Serverless container hosting with application revisions
2. Azure Container Apps
B. Managed container image registry
3. AKS
C. Managed Kubernetes orchestration
4. KEDA
D. Event-driven autoscaling
Answer:
1 → B
2 → A
3 → C
4 → D
Explanation: ACR provides container image storage and management; Container Apps provides managed application hosting for containers; AKS provides managed Kubernetes; and KEDA provides event-driven autoscaling capabilities used by Container Apps.
Question 6 — Single Answer
You have deployed an application to AKS using a Kubernetes manifest.
The application starts successfully, but users cannot reach it through the expected endpoint.
Which approach should you take first to investigate the problem?
A. Rebuild the container image using ACR Tasks B. Increase the Cosmos DB RU/s limit C. Inspect Kubernetes resources, events, logs, and connectivity configuration D. Create an Event Grid custom topic
Answer: C
Explanation: Microsoft specifically identifies monitoring and troubleshooting AKS applications through logs, events, and end-to-end connectivity as part of the AI-200 skill set. A deployment can succeed while networking, service, ingress, or application configuration prevents clients from reaching the application.
Question 7 — Single Answer
A new version of a containerized AI API is deployed to Azure Container Apps. The team wants to test the new version without immediately sending all production traffic to it.
Which Container Apps capability is most appropriate?
A. Container Apps revisions B. ACR Tasks C. Kubernetes DaemonSets D. Azure Functions bindings
Answer: A
Explanation: Azure Container Apps supports revisions, allowing different versions of an application to be deployed and managed independently. Traffic can then be managed between revisions, supporting controlled rollout scenarios.
Section 2 — Develop AI Solutions Using Azure Data Management Services
Questions 8–15
Question 8 — Single Answer
An AI application uses Azure Cosmos DB for NoSQL to store documents and their embeddings.
The application needs to retrieve documents whose embeddings are semantically similar to a query embedding.
Which capability should the application use?
A. Change feed B. Vector similarity search C. Azure Functions timer trigger D. Event Grid retry policy
Answer: B
Explanation: Azure Cosmos DB for NoSQL supports storing embeddings and performing vector similarity search. This capability is useful for semantic retrieval and AI/RAG scenarios.
Question 9 — Scenario-Based, Single Answer
An application frequently queries a Cosmos DB for NoSQL container using a property called category.
The query workload has grown significantly, and the development team wants to reduce unnecessary RU consumption by ensuring frequently queried properties are indexed appropriately.
What should the team investigate?
A. Cosmos DB indexing policy B. Azure Service Bus lock duration C. Container Apps revision settings D. Azure Key Vault rotation policy
Answer: A
Explanation: Cosmos DB indexing policies affect how queries are executed and can influence RU consumption and query performance. Designing an appropriate indexing policy is an important part of optimizing Cosmos DB workloads.
Question 10 — Multiple Answers
An AI application uses Azure Cosmos DB for NoSQL.
Which two capabilities are directly relevant to implementing AI retrieval workflows?
A. Storing embeddings B. Performing vector similarity searches C. Creating App Service deployment slots D. Configuring Service Bus dead-letter queues
Answers: A, B
Explanation: Cosmos DB for NoSQL can store embeddings and perform vector similarity searches. These capabilities support semantic retrieval and RAG-style AI applications.
Question 11 — Single Answer
A document-processing application needs to react whenever new or updated items are written to an Azure Cosmos DB for NoSQL container.
Which Cosmos DB capability is designed for this purpose?
A. Analytical store B. Change feed C. Vector index D. Consistency policy
Answer: B
Explanation: The Cosmos DB change feed provides an ordered record of changes to items in a container and can be used to detect and process new or updated items. The AI-200 study guide explicitly includes implementing a change feed processor.
Question 12 — Fill in the Blank
Complete the statement:
Azure Database for PostgreSQL can support vector similarity search for AI workloads by using the __________ extension.
Answer: pgvector
Explanation: PostgreSQL AI workloads can use the pgvector extension to store and search vector embeddings. Microsoft specifically identifies Azure Database for PostgreSQL with pgvector as an AI data service covered by the course and exam.
Question 13 — Scenario-Based, Single Answer
A company is implementing a RAG application using Azure Database for PostgreSQL.
Each document chunk contains:
an embedding
document text
a tenant ID
a document type
The application must retrieve semantically similar chunks but only from the current tenant.
What should the application implement?
A. Vector similarity search combined with metadata filtering B. A Service Bus subscription filtered by tenant ID C. An Azure Function timer trigger D. A Redis expiration policy
Answer: A
Explanation: Vector similarity search retrieves semantically related records, while metadata filtering restricts the result set to relevant records such as a particular tenant. The AI-200 study guide specifically calls out semantic retrieval and RAG patterns using metadata filters with PostgreSQL.
Question 14 — Single Answer
An AI application performs expensive vector searches against Azure Database for PostgreSQL.
The team wants to reduce vector-search latency and unnecessary computational overhead.
Which area should they investigate?
A. Azure Event Grid retry policies B. pgvector indexing and query optimization C. App Configuration feature flags D. Service Bus dead-letter queues
Answer: B
Explanation: PostgreSQL vector workloads can be optimized through appropriate indexing strategies and pgvector configuration. Microsoft specifically includes optimizing vector search and reducing pgvector compute overhead in the AI-200 objectives.
Question 15 — Matching
Match each Azure data technology with the most appropriate use case.
Technology
Use case
1. Cosmos DB for NoSQL
A. Distributed document storage and vector search
2. Azure Database for PostgreSQL
B. Relational data and pgvector-based AI workloads
3. Azure Managed Redis
C. Low-latency caching and vector storage/search
4. Cosmos DB change feed
D. Detecting new or updated Cosmos DB items
Answer:
1 → A
2 → B
3 → C
4 → D
Explanation: These are distinct but complementary AI data patterns. Cosmos DB supports NoSQL document workloads and vector search; PostgreSQL supports relational workloads and pgvector; Azure Managed Redis supports caching and vector capabilities; and Cosmos DB change feed supports processing item changes.
Section 3 — Connect to and Consume Azure Services
Questions 16–23
Question 16 — Single Answer
An AI application submits long-running document-processing requests.
The API should return quickly rather than waiting for processing to finish. A backend worker should process the requests asynchronously.
Which Azure service is most appropriate for queuing the work?
A. Azure Key Vault B. Azure Service Bus C. Azure App Configuration D. Azure Container Registry
Answer: B
Explanation: Azure Service Bus provides messaging capabilities appropriate for decoupling producers from consumers and processing backend operations asynchronously. The AI-200 objectives specifically include queuing and processing backend operations using Service Bus.
Question 17 — Scenario-Based, Single Answer
An AI application uses Azure Service Bus.
Messages that repeatedly fail processing should be isolated so that they do not continue to interfere with normal message processing.
What should the application use?
A. A dead-letter queue B. An Event Grid custom topic C. An App Configuration key D. A Cosmos DB change feed
Answer: A
Explanation: Azure Service Bus provides dead-letter queues for messages that cannot be successfully processed or that meet specified dead-lettering conditions. This allows problematic messages to be isolated for inspection or later processing.
Question 18 — Multiple Answers
You are designing an AI workflow using Azure Service Bus.
Which two capabilities are directly supported by Service Bus and relevant to the AI-200 objectives?
A. Topics and subscriptions B. Dead-letter queues C. Vector similarity search D. Container image versioning
Answers: A, B
Explanation: The AI-200 study guide explicitly includes Service Bus messages, topics, subscriptions, and dead-letter queue handling. Vector search and container image versioning are handled by other Azure services.
Question 19 — Single Answer
A company wants an application to react whenever a new image is added to an Azure Storage account.
The workflow should be event-driven rather than continuously polling the storage account.
Which Azure service should be used to route the event?
A. Azure Event Grid B. Azure Key Vault C. Azure Managed Redis D. Azure Container Registry Tasks
Answer: A
Explanation: Event Grid is designed for event-driven architectures. It can route events from Azure resources to handlers and supports event filtering and retry behavior.
Question 20 — Scenario-Based, Single Answer
An AI application needs a lightweight HTTP API that performs a small amount of processing and then returns a response.
The API does not require a continuously running server.
Which Azure service is most appropriate?
A. Azure Kubernetes Service B. Azure Functions C. Azure Container Registry D. Azure Service Bus
Answer: B
Explanation: Azure Functions provides serverless execution and supports HTTP-triggered functions that can implement APIs without requiring developers to manage a continuously running server infrastructure. The AI-200 objectives include building serverless APIs using triggers and bindings.
Question 21 — Single Answer
You are developing an Azure Function that should execute whenever a message arrives in a supported messaging system.
Which Azure Functions capability determines what causes the function to execute?
A. Binding B. Trigger C. Revision D. Indexing policy
Answer: B
Explanation: A Function trigger defines the event that causes a function to execute. Bindings provide a declarative way to connect a function to input and output data or services.
Question 22 — Multiple Answers
Which two statements correctly describe Azure Functions concepts?
A. A trigger determines when a function executes. B. Bindings can simplify interaction with external data or services. C. A trigger is primarily used to create a PostgreSQL vector index. D. Bindings replace all Azure authentication mechanisms.
Answers: A, B
Explanation: Triggers define function execution events, while bindings provide connections to data and services. They do not create database indexes or eliminate the need for authentication and authorization.
Question 23 — Scenario-Based, Single Answer
An organization publishes custom business events for its AI workflow. Several downstream applications should independently receive the events.
The organization also needs to apply event filters so that each subscriber receives only the events relevant to it.
Which Azure service is the best fit?
A. Azure Service Bus queue B. Azure Event Grid C. Azure Key Vault D. Azure App Service
Answer: B
Explanation: Event Grid is designed for event-driven architectures and supports custom events and event filtering. It is appropriate when publishers emit events and multiple subscribers independently react to those events.
Section 4 — Secure, Monitor, and Troubleshoot Azure Solutions
Questions 24–30
Question 24 — Single Answer
An AI application requires an API key to access an external AI service.
The development team currently stores the key directly in the application’s source code.
What is the best Azure-native solution?
A. Store the key in Azure Container Registry B. Store the key in Azure App Configuration as plain text C. Store the key in Azure Key Vault D. Store the key in an Azure Service Bus message
Answer: C
Explanation: Azure Key Vault is designed to securely store and retrieve secrets such as API keys, passwords, and other sensitive configuration information. Hard-coding secrets in source code should be avoided.
Question 25 — Scenario-Based, Single Answer
A company wants to change application configuration values without rebuilding and redeploying the application.
The configuration includes feature flags and non-secret application settings.
Which service should be used?
A. Azure App Configuration B. Azure Key Vault C. Azure Container Registry D. Azure Service Bus
Answer: A
Explanation: Azure App Configuration provides centralized management of application settings and configuration. Key Vault is primarily intended for secrets and other sensitive values.
Question 26 — Multiple Answers
A company is designing secure configuration management for an AI application.
Which two approaches are appropriate?
A. Store sensitive secrets in Azure Key Vault. B. Store application configuration information in Azure App Configuration. C. Store API secrets directly in application source code. D. Put database passwords into Event Grid event payloads.
Answers: A, B
Explanation: Key Vault is designed for secrets, while App Configuration provides centralized application configuration management. Secrets should not be embedded in source code or unnecessarily exposed in event payloads.
Question 27 — Single Answer
An AI application consists of multiple distributed services.
A request enters an API, invokes a backend service, calls a database, and then invokes another service.
The development team needs to follow the request across these components to identify where latency is occurring.
Which technology should they use?
A. Azure Container Registry Tasks B. OpenTelemetry C. Cosmos DB indexing D. Service Bus dead-lettering
Answer: B
Explanation: OpenTelemetry provides standardized application instrumentation for collecting telemetry such as traces, metrics, and related diagnostic information. Distributed tracing can help follow a request across multiple services.
Question 28 — Scenario-Based, Single Answer
You need to analyze application logs stored in Azure Monitor Logs.
You want to find all requests where the duration was greater than 2 seconds and return the most recent results first.
Which technology should you use?
A. Dockerfile B. KQL C. pgvector D. KEDA
Answer: B
Explanation: Kusto Query Language (KQL) is used to query and analyze data in Azure Monitor Logs and other Azure data platforms. The AI-200 study guide explicitly includes writing KQL queries to analyze logs and metrics.
Question 29 — Matching
Match each technology with its primary purpose.
Technology
Purpose
1. Azure Key Vault
A. Centralized application configuration
2. Azure App Configuration
B. Secure secret management
3. OpenTelemetry
C. Application telemetry and distributed tracing
4. KQL
D. Query and analyze telemetry/log data
Answer:
1 → B
2 → A
3 → C
4 → D
Explanation: Key Vault handles secrets, App Configuration manages application settings, OpenTelemetry provides instrumentation and telemetry, and KQL is used to query and analyze telemetry and log data.
Question 30 — Scenario-Based, Single Answer
An AI application is experiencing intermittent performance problems.
The application consists of several microservices running in Azure. Users report that some requests take several seconds to complete, but CPU utilization on the individual services does not consistently appear high.
The development team wants to determine which downstream service is contributing to the latency for individual requests.
Which approach is most appropriate?
A. Enable distributed tracing with OpenTelemetry B. Increase the Cosmos DB consistency level C. Create an additional Azure Container Registry D. Configure a Service Bus dead-letter queue
Answer: A
Explanation: Distributed tracing is particularly valuable when an application spans multiple services. OpenTelemetry instrumentation can provide trace information that helps developers follow a request across service boundaries and identify where latency is introduced.
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.
The Data Community 