Category: azure

AI-200, azure, Microsoft Certification August 15, 2026August 15, 2026

Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container-orchestrated solutions
      --> Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files

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 Kubernetes Service (AKS) provides a managed Kubernetes environment for deploying and operating containerized applications. For AI solutions, AKS can be particularly useful when applications require container orchestration, multiple cooperating services, custom networking, persistent workloads, or more control over Kubernetes configuration.

One of the fundamental skills for working with AKS is the ability to define and deploy applications by using Kubernetes manifest files.

A Kubernetes manifest is a declarative configuration file, commonly written in YAML, that describes the desired state of Kubernetes resources. Rather than manually creating each resource with individual commands, developers can define the application’s resources in one or more manifest files and use kubectl to apply those definitions to an AKS cluster.

The AI-200 exam expects you to understand how these manifests are structured, how they are deployed, how Kubernetes resources work together, and how to manage and troubleshoot the resulting application.

1. Understanding Kubernetes Manifest Files

A Kubernetes manifest describes one or more Kubernetes resources.

A typical manifest specifies information such as:

The resource type
The resource name
The container image
The number of replicas
Container ports
Environment variables
Resource requests and limits
Configuration references
Secrets
Health probes
Labels and selectors
Service configuration
Storage requirements

A manifest is declarative.

That distinction is important.

Instead of telling Kubernetes:

Start three containers, then create a network endpoint, then connect the endpoint to those containers.

you describe the desired state:

I want a Deployment with three replicas and a Service that selects those replicas.

Kubernetes controllers continuously work toward making the actual state of the cluster match the desired state defined by the manifests.

2. YAML Manifest Structure

A basic Kubernetes manifest typically contains:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

		

The major sections are:

Property	Purpose
`apiVersion`	Specifies the Kubernetes API version used by the resource
`kind`	Specifies the type of Kubernetes resource
`metadata`	Provides identifying information such as name and labels
`spec`	Defines the desired configuration of the resource

For the exam, be comfortable recognizing the relationship between these sections.

3. The `apiVersion` Property

apiVersion identifies the API group and version used to create the resource.

For example:

apiVersion: apps/v1

is commonly used for a Deployment.

A Service generally uses:

apiVersion: v1

The API version matters because Kubernetes resources belong to different API groups and versions.

For example:

			
apiVersion: apps/v1
kind: Deployment

is different from:

			
apiVersion: v1
kind: Service

The apiVersion must be appropriate for the resource being defined.

4. The `kind` Property

The kind property identifies the Kubernetes resource being created.

Common resources include:

Deployment
Service
Pod
ConfigMap
Secret
StatefulSet
Job
CronJob
Ingress
HorizontalPodAutoscaler

For AI-200, pay particular attention to Deployment and Service, as these are fundamental to deploying and exposing applications.

5. Kubernetes Deployments

A Deployment manages a set of replicated Pods.

For example:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

		

The important relationship is:

Deployment → ReplicaSets → Pods

The Deployment controller creates and manages a ReplicaSet, which in turn maintains the requested number of Pods.

If:

replicas: 3

is specified, Kubernetes attempts to maintain three Pods matching the Deployment’s selector.

If a Pod fails, Kubernetes can create a replacement.

6. Labels and Selectors

Labels are extremely important in Kubernetes.

A label identifies or categorizes a resource:

			
labels:
  app: ai-api

A selector determines which resources should be associated with another resource.

For example:

			
selector:
  matchLabels:
    app: ai-api

The Deployment’s selector must correspond to labels on its Pod template.

A Service can then use the same label:

			
selector:
  app: ai-api

This allows the Service to route traffic to the appropriate Pods.

Exam Tip

A common exam scenario presents a Deployment and Service that aren’t communicating.

Check the Service selector and the Pod labels.

For example:

			
# Pod
labels:
  app: ai-api

and:

			
# Service
selector:
  app: ai-api

match.

But:

			
selector:
  app: api

does not.

A mismatch can result in a Service with no appropriate endpoints.

7. Container Images

A Deployment specifies the image that Kubernetes should run:

			
containers:
  - name: ai-api
    image: myregistry.azurecr.io/ai-api:v1

For Azure-based applications, the image may be stored in Azure Container Registry (ACR).

The image reference generally contains:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/inference-api:2.1

The tag identifies the particular version of the image.

Best Practice

Avoid relying on ambiguous tags such as:

latest

for production deployments when deterministic versioning is important.

Using an explicit version such as:

inference-api:2.1.4

makes deployments easier to reproduce and troubleshoot.

8. Connecting AKS to Azure Container Registry

An AKS application frequently pulls its container images from ACR.

The AKS cluster must have appropriate permissions to pull the image.

For example, Azure CLI can be used to attach an ACR to an AKS cluster:

			
az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --attach-acr myRegistry

The exact identity and authorization configuration can vary depending on how the AKS cluster is configured.

The important concept is:

AKS must be authorized to pull the private container image.

If the image cannot be pulled, Pods may enter states such as:

ImagePullBackOff

or:

ErrImagePull

9. Exposing an Application with a Service

A Pod’s IP address is generally not intended to be the stable endpoint for an application.

A Kubernetes Service provides a stable network abstraction for accessing a set of Pods.

Example:

			
apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  selector:
    app: ai-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

		

Here:

port: 80 is the Service port.
targetPort: 8080 is the container/application port.
selector: app: ai-api identifies the Pods receiving traffic.
type: LoadBalancer requests an externally accessible load-balancing endpoint through the cloud provider integration.

10. Service Types

The most important Service types to recognize are:

ClusterIP

type: ClusterIP

This is the default Service type.

It provides an internal cluster endpoint.

Use it when the application should be reachable from within the Kubernetes cluster but doesn’t need to be directly exposed externally.

NodePort

type: NodePort

Exposes the Service through a port on each node.

It is useful in certain scenarios but is generally less convenient than higher-level ingress or load-balancing approaches for production web applications.

LoadBalancer

type: LoadBalancer

Requests an external load balancer from the cloud provider.

In AKS, this can provide an externally reachable IP address for the application.

A newly created LoadBalancer Service may initially show:

EXTERNAL-IP   <pending>

until the Azure networking resources are provisioned.

11. Deploying a Manifest to AKS

Once kubectl is configured to communicate with the AKS cluster, the primary command for applying a manifest is:

kubectl apply -f deployment.yaml

For example:

kubectl apply -f ai-api.yaml

kubectl apply is an important command because it applies the desired configuration described by the manifest to the cluster.

Microsoft’s AKS documentation uses this pattern for deploying applications from YAML manifests.

You can also apply a directory:

kubectl apply -f ./manifests/

This is useful when an application consists of multiple YAML files.

12. Applying Multiple Resources in One File

A YAML file can contain multiple Kubernetes resources.

The resources are separated using:

---

For example:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  ...
---
apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  ...

		

This allows the Deployment and Service to be maintained together.

An AKS application can therefore be deployed using a single command:

kubectl apply -f ai-api.yaml

The manifest can create multiple Kubernetes objects.

13. Connecting `kubectl` to AKS

Before deploying an application, kubectl must be configured to communicate with the correct AKS cluster.

A common command is:

			
az aks get-credentials \
  --resource-group myResourceGroup \
  --name myAKSCluster

This configures the local Kubernetes client with credentials and cluster information.

You can then verify connectivity:

kubectl get nodes

If the connection is successful, the cluster’s nodes should be displayed.

Exam Tip

Know the distinction:

az aks ...

is used to manage/interact with the Azure AKS resource.

kubectl ...

is used to interact with Kubernetes resources running in the cluster.

14. Namespaces

Namespaces provide logical isolation within a Kubernetes cluster.

A manifest can specify a namespace:

			
metadata:
  name: ai-api
  namespace: production

Alternatively, the namespace can be supplied when using kubectl:

kubectl apply -f ai-api.yaml -n production

You can view resources in a namespace with:

kubectl get pods -n production

Namespaces are useful for separating environments or application components.

For example:

			
development
testing
production

can exist within the same cluster.

15. Environment Variables

Container applications often require configuration through environment variables.

A manifest can specify them directly:

			
env:
  - name: MODEL_NAME
    value: "my-model"
  - name: LOG_LEVEL
    value: "Information"

		

However, application configuration should generally be separated from the container image.

Kubernetes provides ConfigMaps for non-sensitive configuration and Secrets for sensitive information.

16. ConfigMaps

A ConfigMap stores non-sensitive configuration data.

Example:

			
apiVersion: v1
kind: ConfigMap
metadata:
  name: ai-config
data:
  MODEL_NAME: "my-model"
  LOG_LEVEL: "Information"

		

A Deployment can consume the values:

			
envFrom:
  - configMapRef:
      name: ai-config

This makes it possible to change configuration without rebuilding the container image.

17. Kubernetes Secrets

Sensitive information should not normally be hard-coded into a Deployment manifest.

Kubernetes Secrets can be used to store sensitive configuration such as:

Passwords
API keys
Connection strings
Certificates

For example:

			
env:
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: ai-secrets
        key: api-key

		

For production Azure applications, you should also understand Azure-native approaches for managing secrets, such as Azure Key Vault and workload identity, rather than treating a Kubernetes Secret as equivalent to a fully managed secret-management solution.

18. Resource Requests and Limits

Containers can specify CPU and memory requests and limits.

For example:

			
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

		

Requests

A request indicates the resources needed for scheduling.

Kubernetes uses requests when determining where a Pod can run.

Limits

A limit establishes the maximum resource usage permitted for the container.

For AI workloads, resource specifications can be particularly important because inference workloads can consume substantial CPU or memory.

19. Health Probes

Kubernetes supports health probes that help determine application health.

Three important probe concepts are:

Startup probe

Determines whether an application has successfully started.

This is particularly useful for applications that take a long time to initialize.

Readiness probe

Determines whether the application is ready to receive traffic.

If a container isn’t ready, Kubernetes can prevent traffic from being sent to it through a Service.

Liveness probe

Determines whether the container is still functioning correctly.

If the liveness probe repeatedly fails, Kubernetes can restart the container.

Example:

			
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

		

Exam Distinction

Remember:

Readiness = Should this Pod receive traffic?

Liveness = Is this container still healthy enough to keep running?

Startup = Has this application finished starting?

20. Updating an Application

One of the major benefits of declarative manifests is that you can modify the desired state and apply it again.

For example, changing:

image: myregistry.azurecr.io/ai-api:v1

to:

image: myregistry.azurecr.io/ai-api:v2

and running:

kubectl apply -f ai-api.yaml

causes Kubernetes to reconcile the Deployment with the new desired configuration.

A Deployment can perform a rolling update, gradually replacing existing Pods with Pods running the new version.

This reduces application downtime compared with manually deleting all existing Pods.

21. Checking Deployment Status

After deploying a manifest, use:

kubectl get deployments

For more detailed information:

kubectl describe deployment ai-api

To inspect Pods:

kubectl get pods

To obtain additional information:

kubectl get pods -o wide

You can also watch changes:

kubectl get pods --watch

These commands are important for verifying whether the application has successfully transitioned to its desired state.

22. Viewing Application Logs

If a container is running but the application isn’t behaving correctly, inspect its logs:

kubectl logs <pod-name>

If a Pod contains multiple containers:

kubectl logs <pod-name> -c <container-name>

Logs are often the first place to look for application-level failures.

23. Using `kubectl describe`

When Kubernetes reports an unexpected condition, kubectl describe provides useful diagnostic information.

For example:

kubectl describe pod <pod-name>

This can reveal:

Scheduling problems
Container image errors
Failed probes
Mount failures
Events
Resource issues

For a Service:

kubectl describe service ai-api

can help identify configuration problems.

24. Common Deployment Problems

Several problems are particularly useful to recognize for the exam.

`ImagePullBackOff`

Usually indicates that Kubernetes cannot successfully pull the specified image.

Potential causes include:

Incorrect image name
Incorrect tag
Image doesn’t exist
Authentication/authorization failure
Registry connectivity issue

`CrashLoopBackOff`

Indicates that a container repeatedly starts and then fails.

Potential causes include:

Application startup failure
Invalid configuration
Missing environment variables
Application exception
Dependency failure

Start troubleshooting with:

kubectl logs <pod-name>

and:

kubectl describe pod <pod-name>

Pod stuck in `Pending`

A Pod may remain Pending because:

No node has sufficient resources
Node selectors don’t match available nodes
A required volume cannot be provisioned
Scheduling constraints cannot be satisfied

Inspect:

kubectl describe pod <pod-name>

for scheduling events.

Service has no endpoints

If a Service exists but isn’t routing traffic, check:

Service selector
Pod labels
Pod readiness
Service and container ports

For example:

			
selector:
  app: ai-api

must correspond to:

			
labels:
  app: ai-api

25. Managing Applications Declaratively

The major conceptual advantage of manifests is that they allow infrastructure and application configuration to be represented as code.

Instead of manually configuring a production environment, the desired configuration can be stored in source control.

For example:

			
/manifests
    namespace.yaml
    configmap.yaml
    deployment.yaml
    service.yaml

		

A deployment pipeline can then apply these manifests to an AKS cluster.

This provides:

Repeatability
Version control
Change tracking
Easier rollback
Consistent environments
Automation
Infrastructure-as-code characteristics

26. Manifest Files and CI/CD

Manifest files fit naturally into CI/CD processes.

A typical workflow might look like:

			
Developer commits code
        ↓
Build container image
        ↓
Push image to ACR
        ↓
Update Kubernetes manifest
        ↓
CI/CD pipeline
        ↓
kubectl apply
        ↓
AKS Deployment
        ↓
Rolling update

		

The image and Kubernetes configuration should generally be treated as separate concerns.

The container image defines the application artifact.

The Kubernetes manifest defines how that artifact should be deployed.

27. Example Complete Manifest

The following example illustrates a simplified AI inference API deployed to AKS.

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference-api
  template:
    metadata:
      labels:
        app: inference-api
    spec:
      containers:
        - name: inference-api
          image: myregistry.azurecr.io/inference-api:1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: inference-api
spec:
  selector:
    app: inference-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

		

Deploy it with:

kubectl apply -f inference-api.yaml

Then verify:

			
kubectl get deployments
kubectl get pods
kubectl get services

The Service can expose the application externally through an Azure load balancer.

28. Important Commands to Know

Command	Purpose
`az aks get-credentials`	Configure `kubectl` to connect to an AKS cluster
`kubectl get nodes`	View cluster nodes
`kubectl apply -f file.yaml`	Create/update resources from a manifest
`kubectl get deployments`	View Deployments
`kubectl get pods`	View Pods
`kubectl get services`	View Services
`kubectl describe pod`	Inspect detailed Pod information
`kubectl describe deployment`	Inspect a Deployment
`kubectl logs`	View container logs
`kubectl get pods -o wide`	View Pods with additional placement/network information
`kubectl delete -f file.yaml`	Delete resources defined by a manifest
`kubectl get events`	View Kubernetes events

A particularly important distinction is:

kubectl apply -f manifest.yaml

is generally preferred for declarative management because it creates or updates the resources described by the manifest.

29. Key Exam Takeaways

For AI-200, make sure you understand these relationships:

Manifest

Defines the desired state of Kubernetes resources.

Deployment

Manages replicated Pods and supports controlled updates.

Pod

The basic execution unit containing one or more containers.

Service

Provides a stable network endpoint for a group of Pods.

Labels

Identify resources.

Selectors

Determine which resources another resource targets.

ConfigMap

Stores non-sensitive configuration.

Secret

Stores sensitive configuration within Kubernetes.

`kubectl apply`

Applies a declarative manifest.

ACR

Commonly stores the container images consumed by AKS.

Readiness probe

Determines whether a Pod should receive traffic.

Liveness probe

Determines whether a container should continue running.

Startup probe

Determines whether an application has successfully started.

`kubectl describe`

Useful for diagnosing Kubernetes resource and scheduling problems.

`kubectl logs`

Useful for diagnosing application/container failures.

Practice Exam Questions

Question 1

You have an AI inference application running in AKS. The application should run three identical instances, and Kubernetes should replace an instance if its Pod fails.

Which Kubernetes resource should you use?

A. Deployment

B. Service

C. ConfigMap

D. Ingress

Answer: A

Explanation

A Deployment manages replicated Pods and maintains the desired number of replicas. If a Pod managed by the Deployment fails, Kubernetes can create a replacement.

A Service provides network access to Pods but doesn’t manage their lifecycle. A ConfigMap stores configuration, and an Ingress manages HTTP/HTTPS routing.

Question 2

An AKS application has a Deployment with the following Pod label:

			
labels:
  app: inference-api

The application is exposed through a Service, but the Service isn’t routing traffic to the Pods.

The Service contains:

			
selector:
  app: ai-service

What should you change?

A. Change the Deployment’s replicas value

B. Change the Service selector to app: inference-api

C. Change the Service type to ClusterIP

D. Change the container’s containerPort

Answer: B

Explanation

The Service selector must match the labels assigned to the target Pods. The Pods are labeled:

app: inference-api

Therefore, the Service should use:

			
selector:
  app: inference-api

Changing the replica count or Service type does not correct the selector mismatch.

Question 3

You have modified a Kubernetes Deployment manifest to use version 2 of an AI inference container:

image: myregistry.azurecr.io/inference-api:v2

What command should you normally use to apply the change?

A. kubectl restart deployment

B. kubectl create deployment

C. kubectl apply -f deployment.yaml

D. az aks update --image v2

Answer: C

Explanation

kubectl apply -f applies the desired state represented by the manifest. When the Deployment’s Pod template changes, Kubernetes can perform a rolling update to replace Pods running the previous image.

Question 4

An AI API deployed to AKS takes several minutes to initialize because it loads a large machine-learning model. Kubernetes is restarting the container before initialization completes.

Which configuration is most appropriate?

A. Increase the Service’s targetPort

B. Add a startup probe

C. Add a ConfigMap

D. Change the Service to LoadBalancer

Answer: B

Explanation

A startup probe is designed for applications that require significant time to initialize. It allows Kubernetes to determine when startup has completed before normal liveness checking takes effect.

A readiness probe controls whether traffic should be sent to the application, while a startup probe is specifically useful during initialization.

Question 5

An AKS Deployment has been created, but its Pods remain in the Pending state.

Which command is most useful for investigating scheduling-related events for a specific Pod?

A. kubectl describe pod <pod-name>

B. kubectl logs <pod-name>

C. kubectl get service <service-name>

D. kubectl apply -f deployment.yaml

Answer: A

Explanation

kubectl describe pod provides detailed information about the Pod, including Kubernetes events. These events can reveal issues such as insufficient resources, unsatisfied scheduling constraints, or volume problems.

kubectl logs is more useful when a container has started and is producing application logs.

Question 6

You want an application in AKS to be reachable from outside the cluster using an Azure-provided external load balancer.

Which Service type should you specify?

A. ClusterIP

B. ExternalName

C. NodePort

D. LoadBalancer

Answer: D

Explanation

A Service with:

type: LoadBalancer

requests an external load balancer through the cloud provider integration. In AKS, this can provide an externally reachable IP address.

ClusterIP is primarily for internal cluster access.

Question 7

An AI application requires the following configuration:

			
MODEL_NAME=customer-support-model
LOG_LEVEL=Information

The values are not sensitive and should be changed independently of the container image.

Which Kubernetes resource is most appropriate?

A. Secret

B. ConfigMap

C. Deployment replica

D. Service

Answer: B

Explanation

A ConfigMap is designed to store non-sensitive configuration data separately from the application container image.

A Kubernetes Secret is intended for sensitive information such as credentials and keys.

Question 8

You have successfully deployed an AKS application, but the Pods show ImagePullBackOff.

The Deployment specifies:

image: myregistry.azurecr.io/inference-api:v5

Which is the most likely category of problem?

A. The Service selector doesn’t match the Pod labels

B. The readiness probe is failing

C. AKS cannot successfully retrieve the specified container image

D. The Deployment has too many replicas

Answer: C

Explanation

ImagePullBackOff indicates that Kubernetes is having difficulty pulling the container image. Potential causes include an incorrect image name or tag, an image that doesn’t exist, or insufficient authorization to access a private registry.

Service selectors and readiness probes are unrelated to the initial image-pull operation.

Question 9

You want an AKS application to receive traffic only after its /health endpoint indicates that it is ready.

Which probe should you configure?

A. Readiness probe

B. Liveness probe

C. Startup probe

D. Resource probe

Answer: A

Explanation

A readiness probe determines whether a container is ready to receive traffic. If the readiness probe fails, Kubernetes can keep the Pod out of the Service’s ready endpoints.

A liveness probe determines whether a container should continue running, while a startup probe is intended to determine whether a slow-starting application has completed initialization.

Question 10

An AKS application is deployed from a YAML file containing both a Deployment and a Service separated by ---.

Which command can be used to create or update both resources according to the manifest?

A. kubectl get -f application.yaml

B. kubectl logs -f application.yaml

C. kubectl describe -f application.yaml

D. kubectl apply -f application.yaml

Answer: D

Explanation

kubectl apply -f processes the resources defined in the manifest and creates or updates them to match the desired state.

The --- separator allows multiple Kubernetes resource definitions to be included in the same YAML file.

Final Review

For this AI-200 topic, the most important thing is to understand how a declarative Kubernetes manifest translates into a running application on AKS.

The core flow is:

			
Container image
      ↓
Azure Container Registry
      ↓
Kubernetes Deployment manifest
      ↓
kubectl apply
      ↓
Deployment
      ↓
ReplicaSet
      ↓
Pods
      ↓
Service
      ↓
Application endpoint

		

When troubleshooting, think systematically:

			
Can't deploy?
    ↓
Can AKS pull the image?
    ↓
Is the Pod scheduled?
    ↓
Is the container starting?
    ↓
Are startup/readiness/liveness probes correct?
    ↓
Do Service selectors match Pod labels?
    ↓
Are ports configured correctly?

		

If you understand that flow—and can recognize Deployment vs. Pod vs. Service vs. ConfigMap vs. Secret, along with the purpose of kubectl apply, labels/selectors, probes, and common Pod states—you will have a strong foundation for the manifest-based AKS questions in AI-200.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026

Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container Apps (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container-orchestrated solutions
      --> Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container 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

Modern AI applications frequently perform work asynchronously. Instead of processing every request synchronously, an application might place work onto a queue or event stream and have one or more containerized workers process those events.

This architecture creates an important scaling question:

How can the application automatically add or remove container instances based on the amount of work waiting to be processed?

Kubernetes Event-driven Autoscaling (KEDA) provides the answer.

Azure Container Apps uses KEDA to support event-driven autoscaling. A container app can use KEDA-based scaling rules to respond to events and metrics from supported sources such as Azure Service Bus, Azure Event Hubs, Apache Kafka, and Redis. Container Apps manages the KEDA integration for you, so you don’t install or operate KEDA yourself.

For the AI-200 exam, the important skill is understanding when to use KEDA, how KEDA determines replica counts, how scaling rules are configured, and how authentication and scale limits affect the resulting application behavior.

1. What Is KEDA?

Kubernetes Event-driven Autoscaling (KEDA) is an autoscaling component designed to scale containerized workloads based on events or external metrics.

Traditional autoscaling commonly uses resource metrics such as:

CPU utilization
Memory utilization

Those metrics can be useful, but they don’t always represent the actual workload.

Consider an AI document-processing application:

                ┌──────────────────┐
Documents ────► │  Service Bus     │
                │      Queue       │
                └────────┬─────────┘
                         │
                         │ Pending messages
                         ▼
                ┌──────────────────┐
                │ KEDA scaler      │
                └────────┬─────────┘
                         │
                  Scale decision
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
        Container App         Container App
          Replica 1             Replica 2

If there are only a few messages, the application may need only one replica.

If thousands of messages are waiting, additional replicas can be created to process the workload concurrently.

This is event-driven autoscaling.

2. KEDA in Azure Container Apps

Azure Container Apps incorporates KEDA into its scaling architecture.

This is an important exam distinction:

You don’t deploy and manage a separate KEDA installation for an Azure Container App.

Instead, you configure a scale rule on the container app. Azure Container Apps uses KEDA behind the scenes to evaluate the rule and determine how many replicas are needed.

Conceptually:

			
External event source
        │
        ▼
   KEDA scaler
        │
        ▼
Scale rule evaluation
        │
        ▼
Desired replica count
        │
        ▼
Azure Container Apps
        │
        ├── Replica 1
        ├── Replica 2
        ├── Replica 3
        └── ...

		

This makes KEDA particularly useful for background workers and asynchronous AI workloads.

3. Why Event-Driven Scaling Is Important for AI Applications

AI workloads frequently have unpredictable demand.

For example, imagine a document-processing application:

Users upload documents.
Documents are placed into an Azure Service Bus queue.
Containerized workers retrieve documents.
Workers send documents to an AI service.
Results are stored in a database.

During periods of low activity, perhaps only one worker is necessary.

During a large batch upload, hundreds or thousands of documents might be waiting.

A fixed number of replicas creates two problems:

Too few replicas

			
1 worker
   │
   ├── Document 1
   ├── Document 2
   ├── Document 3
   ├── ...
   └── Document 10,000

		

Processing becomes slow.

Too many replicas

			
20 workers
   │
   └── Almost nothing to process

Resources are unnecessarily consumed.

KEDA allows the application to dynamically respond to the workload.

4. KEDA Versus CPU-Based Autoscaling

A common exam scenario is determining whether resource-based scaling or event-based scaling is more appropriate.

Suppose a worker application consumes messages from Azure Service Bus.

CPU usage might look like this:

Queue Messages	CPU Usage
0	5%
100	15%
1,000	20%
10,000	25%

CPU isn’t necessarily a good representation of the amount of work waiting.

KEDA can instead monitor the queue itself.

For example:

			
Target = 20 messages per replica
messages → 1 replica
messages → 2 replicas
messages → 5 replicas
messages → 10 replicas

		

This makes the scaling decision directly related to the workload.

5. KEDA Scalers

A KEDA scaler connects KEDA to an external event source or metric.

Azure Container Apps supports KEDA-based custom scaling rules for various event sources.

Common examples include:

Azure Service Bus
Azure Event Hubs
Apache Kafka
Redis
Azure Queue Storage
Other supported KEDA scalers through custom rules

Azure Container Apps also supports HTTP and TCP scaling rules, but these aren’t the same thing as event-driven KEDA scaling.

For the exam, remember:

HTTP scaling and event-driven scaling are different scaling mechanisms.

6. Container Apps Scale Rules

Scaling is configured through the container app’s scale configuration.

A scale configuration contains concepts such as:

minReplicas
maxReplicas
rules
polling interval
cooldown period

A simplified conceptual configuration looks like this:

			
scale:
    minReplicas: 0
    maxReplicas: 10
    rules:
        - name: service-bus-rule
          type: azure-servicebus
          metadata:
              queueName: orders
              messageCount: 20

		

The exact metadata depends on the KEDA scaler being used.

The important exam concept is the relationship:

			
Scale Rule
   │
   ├── Scaler type
   ├── Metadata
   └── Authentication
          │
          ▼
        KEDA
          │
          ▼
   Desired replicas

		

7. `minReplicas`

minReplicas specifies the minimum number of replicas that the application can maintain.

For example:

minReplicas = 1

means that the application won’t scale below one replica.

This is useful when:

The application must always be available.
Cold-start latency is undesirable.
The workload can’t tolerate scaling to zero.

By contrast:

minReplicas = 0

allows the application to scale down to zero when there is no workload.

Azure Container Apps supports a minimum of zero replicas and a maximum configurable replica count of up to 1,000.

8. `maxReplicas`

maxReplicas establishes the upper limit on scaling.

For example:

			
minReplicas: 0
maxReplicas: 20

means:

0 ≤ replicas ≤ 20

Even if the event source contains a massive backlog, the application won’t exceed the configured maximum.

This is important for:

Controlling costs
Protecting downstream services
Preventing excessive concurrency
Preventing an application from overwhelming a database or AI service

Exam tip

If a question asks:

“How can you prevent an event-driven application from creating an excessive number of replicas?”

Look for:

Configure maxReplicas.

9. Target Values and Scaling

Many KEDA scalers use a target value that represents the desired workload per replica.

For example, consider:

messageCount = 20

Conceptually, this means the scaler targets approximately 20 messages per replica.

If there are 100 messages:

			
Desired replicas = ceil(100 / 20)
Desired replicas = 5

Therefore:

			
100 messages
      │
      ▼
Target = 20 messages/replica
      │
      ▼
5 replicas

		

Azure Container Apps describes the general scaling calculation as:

			
desiredReplicas =
    ceil(currentMetricValue / targetMetricValue)

subject to the configured scaling limits and Container Apps’ scaling behavior.

10. Example: Azure Service Bus

Suppose an AI application processes image-analysis requests from an Azure Service Bus queue.

The scaling rule specifies:

			
messageCount = 10
minReplicas = 0
maxReplicas = 10

The approximate relationship is:

Messages	Desired Replicas
0	0
1–10	1
11–20	2
21–30	3
51–60	6
91–100	10
500	10

The final example is limited by maxReplicas.

Therefore, even if 500 messages are waiting, the application won’t create 50 replicas when the maximum is 10.

11. Polling Interval

KEDA periodically checks the event source.

Azure Container Apps uses a default KEDA polling interval of 30 seconds for custom scale rules.

Conceptually:

			
T0
 │
 ├── KEDA checks queue
 │
T+30 sec
 │
 ├── KEDA checks queue
 │
T+60 sec
 │
 ├── KEDA checks queue
 │
...

		

This is important because event-driven scaling isn’t necessarily instantaneous.

If a question describes a workload that suddenly receives messages and asks why scaling doesn’t happen immediately, the polling interval may be relevant.

12. Cooldown Period

The cooldown period determines how long KEDA waits before scaling an application from its final active replica down to zero after the event source becomes inactive.

The default cooldown period for Container Apps custom scaling is 300 seconds.

For example:

			
Messages arrive
     │
     ▼
Scale out
     │
     ▼
Messages processed
     │
     ▼
Queue becomes empty
     │
     ▼
Cooldown period
     │
     ▼
Scale to zero

		

An important distinction is that the cooldown period specifically affects scaling from the final replica to zero; it isn’t simply a universal delay applied to every scale-in operation.

13. Scale-to-Zero

One of the major advantages of event-driven scaling is the ability to scale an application to zero.

For example:

			
No work
   │
   ▼
0 replicas
   │
   │ New event arrives
   ▼
1 replica
   │
   ▼
More events
   │
   ▼
5 replicas

		

This is especially useful for workloads that aren’t continuously active.

Examples include:

Document processing
Image processing
AI inference jobs
Data enrichment
Background processing
Queue consumers

When the workload disappears, the application can eventually return to zero replicas.

Azure Container Apps doesn’t charge usage charges for a container app while it is scaled to zero.

14. Authentication for KEDA Scale Rules

A KEDA scaler often needs permission to inspect the external event source.

For example, a Service Bus scaler needs access to Service Bus.

Azure Container Apps supports authentication for scale rules using:

Secrets
Managed identities for supported Azure resources

The authentication configuration is associated with the scale rule rather than requiring application code to perform the scaling operation.

Managed identity

For Azure resources, managed identity is often preferable because the application doesn’t need to store a long-lived credential.

Conceptually:

			
Container App
     │
     │ Managed Identity
     ▼
Microsoft Entra ID
     │
     ▼
Azure Service Bus

		

This is generally preferable to embedding credentials in application source code.

15. Secret-Based Authentication

Scale rules can also reference secrets.

Conceptually:

			
Container App
    │
    ├── Secret
    │
    ▼
KEDA scale rule
    │
    ▼
Event source

		

For example, a Service Bus connection string could be stored as a Container Apps secret and referenced by the scale rule.

Exam distinction

Don’t confuse:

Application authentication

with:

Scaler authentication

The application itself may have its own credentials or managed identity, while KEDA separately needs authorization to inspect the event source.

16. Multiple Scaling Rules

A container app can have multiple scaling rules.

For example:

			
Container App
     │
     ├── HTTP rule
     │
     ├── Service Bus rule
     │
     └── Redis rule

		

When multiple rules are configured, the application scales when the first applicable scaling condition is met.

This means you can combine different workload signals.

For example:

			
HTTP traffic ────────┐
                     │
Service Bus backlog ─┼──► Scaling decision
                     │
Redis events ────────┘

		

17. KEDA and Azure Container Apps Revisions

A particularly important Azure Container Apps concept is that changing scaling rules creates a new revision of the container app. A revision is an immutable snapshot of the application configuration.

Conceptually:

			
Revision 1
    │
    ├── Old scaling rules
    │
    ▼
Update scaling configuration
    │
    ▼
Revision 2
    │
    └── New scaling rules

		

This matters when managing production applications using revision-based deployment strategies.

18. KEDA and Dapr

KEDA can also be used with Dapr-based applications.

For example, an application could use Dapr pub/sub:

			
Publisher
    │
    ▼
Dapr Pub/Sub
    │
    ▼
Subscriber Container App
    │
    ▼
KEDA

		

KEDA can scale the subscriber based on pending events/messages.

In this scenario, KEDA can scale both the application and its Dapr sidecar based on the workload.

19. KEDA Versus Event-Driven Container Apps Jobs

Azure Container Apps supports both:

Container Apps

A container app normally maintains a number of replicas that continuously process work.

			
Queue
  │
  ▼
Container App
  ├── Replica 1
  ├── Replica 2
  └── Replica 3

		

Event-driven Container Apps Jobs

An event can instead trigger individual job executions.

			
Queue
  │
  ├── Event 1 ──► Job execution 1
  ├── Event 2 ──► Job execution 2
  └── Event 3 ──► Job execution 3

		

Both use KEDA-based scaling concepts, but the result is different.

For an application, the scaling rule determines the number of replicas.

For an event-driven job, the scaling rule determines the number of job executions to start.

Exam tip

If the question says:

“Each event should result in a separate container execution.”

Consider an event-driven Container Apps Job rather than a continuously running container app.

20. KEDA Configuration Concepts to Know

For AI-200, be comfortable recognizing these concepts:

Concept	Purpose
Scaler	Connects KEDA to an event source or metric
Scale rule	Defines how Container Apps uses a scaler
Metadata	Provides scaler-specific configuration
Authentication	Allows KEDA to access the event source
minReplicas	Lowest number of replicas
maxReplicas	Highest number of replicas
Polling interval	How frequently KEDA checks an event source
Cooldown period	Delay associated with scaling the final replica to zero
Scale-to-zero	Allows inactive applications to have zero replicas
Replica	An active instance of the container app revision

21. Example Architecture

Consider an AI document-classification system.

                         ┌──────────────────┐
                         │   Web/API App    │
                         └────────┬─────────┘
                                  │
                                  │ Submit document
                                  ▼
                         ┌──────────────────┐
                         │ Azure Service    │
                         │ Bus Queue        │
                         └────────┬─────────┘
                                  │
                           Pending messages
                                  │
                                  ▼
                         ┌──────────────────┐
                         │      KEDA        │
                         │     Scaler       │
                         └────────┬─────────┘
                                  │
                           Scaling decision
                                  │
                                  ▼
                    ┌─────────────────────────┐
                    │    Azure Container App  │
                    │                         │
                    │ ┌────┐ ┌────┐ ┌────┐   │
                    │ │ R1 │ │ R2 │ │ R3 │...│
                    │ └────┘ └────┘ └────┘   │
                    └───────────┬─────────────┘
                                │
                                ▼
                         Azure AI Service
                                │
                                ▼
                            Data Store

The important point is that KEDA doesn’t process the messages.

KEDA’s responsibility is to determine how many replicas should be running.

The application replicas are responsible for processing the messages.

22. Common Exam Scenarios

Scenario 1: Queue backlog

A containerized AI worker processes Service Bus messages. The application should automatically add workers as the queue backlog increases.

Use KEDA event-driven scaling.

Scenario 2: Scale to zero

The application should consume no running replicas when there are no messages.

Configure:

minReplicas = 0

and use an appropriate event-driven scale rule.

Scenario 3: Limit cost

A sudden event spike must not cause more than 20 workers.

Configure:

maxReplicas = 20

Scenario 4: Avoid stored credentials

KEDA needs access to an Azure Service Bus resource, and the organization doesn’t want connection strings stored.

Use an appropriate managed identity configuration.

Scenario 5: Separate execution per event

Each event should start an independent container execution.

Consider an event-driven Container Apps Job rather than a continuously running container app.

23. Common Mistakes to Avoid

Mistake 1: Installing KEDA manually

For Azure Container Apps, you don’t need to deploy your own KEDA installation.

Remember: Container Apps provides the KEDA integration.

Mistake 2: Assuming KEDA only works with Kubernetes clusters

KEDA originated in the Kubernetes ecosystem, but Azure Container Apps exposes KEDA functionality without requiring you to manage Kubernetes infrastructure.

Mistake 3: Confusing KEDA with CPU autoscaling

KEDA is particularly valuable when scaling should be driven by external events or metrics, such as queue length or event backlog.

Mistake 4: Forgetting `maxReplicas`

Without an appropriate maximum, a large workload can potentially result in substantial scale-out.

Always consider:

			
minReplicas
maxReplicas

Mistake 5: Assuming scaling is instantaneous

KEDA polls event sources. The default polling interval for custom Container Apps scaling rules is 30 seconds, so there can be a delay between a change in workload and the scaling decision.

Mistake 6: Confusing cooldown with polling

These are different:

Polling interval

How frequently KEDA checks the event source.

Cooldown period

How long KEDA waits before scaling the final replica to zero after the workload becomes inactive.

24. AI-200 Exam Takeaways

For the exam, make sure you can answer these questions:

What is KEDA?

A Kubernetes-based event-driven autoscaling mechanism used by Azure Container Apps to scale workloads based on external events and metrics.

Why use KEDA?

When application demand is better represented by an external event source—such as a queue backlog—than by CPU or memory utilization.

Do you install KEDA in Container Apps?

No. Azure Container Apps provides the KEDA integration.

What controls the minimum number of replicas?

minReplicas

What controls the maximum?

maxReplicas

What determines the type of event source?

The KEDA scaler type, such as:

azure-servicebus

What does scaler metadata provide?

The scaler-specific information needed to monitor the event source and determine scaling.

Can Container Apps scale to zero?

Yes, when configured appropriately, such as with minReplicas: 0.

What is the default polling interval?

30 seconds for custom KEDA scale rules.

What is the default cooldown period?

300 seconds for custom scaling, with the cooldown specifically applying to scaling from the final replica to zero.

What happens when multiple scale rules exist?

The application begins scaling when the condition for the first applicable rule is met.

Practice Exam Questions

Question 1

An AI application running in Azure Container Apps processes messages from an Azure Service Bus queue. The application should automatically increase the number of replicas when the number of pending messages increases.

Which technology should you use?

A. Kubernetes Event-driven Autoscaling (KEDA)
B. Azure Traffic Manager
C. Azure Front Door
D. Azure DNS

Answer: A

Explanation

KEDA is designed for event-driven autoscaling. In Azure Container Apps, KEDA can monitor supported event sources such as Azure Service Bus and adjust the number of application replicas according to the workload.

The other services are primarily concerned with traffic routing or DNS rather than workload-driven container scaling.

Question 2

You configure an Azure Container App with the following settings:

			
minReplicas: 0
maxReplicas: 10

The application uses a KEDA-based scale rule and currently has no events to process.

What is the expected minimum number of running replicas?

A. 0
B. 5
C. 1
D. 10

Answer: A

Explanation

minReplicas specifies the minimum number of replicas. Setting it to 0 permits the application to scale to zero when the workload is inactive.

This is one of the major benefits of event-driven scaling for intermittently used workloads.

Question 3

An AI worker consumes messages from an Azure Service Bus queue. The KEDA scale rule uses a target of 20 messages per replica. There are currently 100 messages waiting.

Ignoring scaling limits and other scaling behavior, approximately how many replicas does the target calculation request?

A. 2
B. 5
C. 20
D. 100

Answer: B

Explanation

The target calculation is conceptually:

			
desiredReplicas = ceil(currentMetricValue / targetMetricValue)
desiredReplicas = ceil(100 / 20)
desiredReplicas = 5

Therefore, the target is approximately 5 replicas.

Question 4

An organization wants to ensure that an event-driven Container App never scales beyond 25 replicas, even when a large backlog accumulates.

Which setting should you configure?

A. pollingInterval
B. cooldownPeriod
C. minReplicas
D. maxReplicas

Answer: D

Explanation

maxReplicas establishes the maximum number of replicas that the container app can use for the configured scaling configuration.

For this requirement, configure:

maxReplicas: 25

pollingInterval controls how frequently the event source is checked, while cooldownPeriod relates to scale-down behavior. minReplicas controls the lower bound.

Question 5

A developer wants KEDA in an Azure Container App to determine scaling based on the number of pending messages in Azure Service Bus.

Which component identifies the event source and its associated scaling behavior?

A. Azure Monitor workbook
B. Container Apps ingress configuration
C. KEDA scaler
D. Azure Load Balancer

Answer: C

Explanation

A KEDA scaler connects the autoscaling mechanism to an event source or external metric. The scaler type and associated metadata define how KEDA obtains the workload information.

Ingress and load-balancing configurations don’t provide this event-driven autoscaling capability.

Question 6

An application uses a KEDA custom scale rule in Azure Container Apps. The administrator wants to understand how frequently KEDA checks the external event source by default.

Which interval should the administrator expect?

A. 5 seconds
B. 30 seconds
C. 5 minutes
D. 15 minutes

Answer: B

Explanation

The default polling interval for custom KEDA scaling rules in Azure Container Apps is 30 seconds.

This means event-driven scaling isn’t necessarily evaluated continuously or instantaneously.

Question 7

An AI application uses an Azure Service Bus queue. The organization wants KEDA to access the Azure resource without storing a long-lived Service Bus credential in the application configuration.

Which approach is most appropriate?

A. Disable authentication for the scale rule
B. Store the credential in application source code
C. Use a managed identity where supported
D. Increase the maximum replica count

Answer: C

Explanation

Azure Container Apps supports managed identity authentication for supported Azure resource scale rules.

Managed identities allow Azure resources to authenticate without requiring application developers to embed long-lived credentials in source code or configuration.

Question 8

An event-driven Container App has finished processing its queue. The application currently has one replica, and the queue remains empty.

The application is configured with the default 300-second cooldown period.

What is the purpose of the cooldown period?

A. Determine how frequently the queue is polled
B. Determine the maximum number of replicas
C. Determine the target number of messages per replica
D. Delay scaling the final replica to zero after the workload becomes inactive

Answer: D

Explanation

The cooldown period is associated with scaling from the final active replica to zero.

For Container Apps custom scaling rules, the default cooldown period is 300 seconds.

It should not be confused with the polling interval, which determines how frequently KEDA checks the event source.

Question 9

An Azure Container App has two scaling rules:

An HTTP scaling rule
An Azure Service Bus KEDA scaling rule

The Service Bus queue suddenly contains a large backlog while HTTP traffic remains low.

What happens?

A. The application can scale based on the Service Bus rule
B. Only the HTTP rule is evaluated
C. The application must use CPU scaling instead
D. The two rules are averaged before scaling

Answer: A

Explanation

Azure Container Apps can have multiple scaling rules. The application begins scaling when the condition for an applicable rule is met.

Therefore, a Service Bus backlog can cause scaling even if HTTP traffic isn’t high enough to trigger the HTTP rule.

Question 10

A development team has a workload in which each incoming event should trigger a separate container execution. The workload doesn’t need a continuously running pool of worker replicas.

Which Azure Container Apps capability is the best fit?

A. HTTP ingress scaling
B. Event-driven Container Apps Jobs
C. Azure Traffic Manager
D. TCP ingress scaling

Answer: B

Explanation

Event-driven Container Apps Jobs are designed for workloads where events trigger individual job executions.

This differs from a normal Container App, where KEDA determines how many replicas of the application should be running to process the workload.

For example:

			
Event 1 → Job execution 1
Event 2 → Job execution 2
Event 3 → Job execution 3

A continuously running container application would instead maintain a pool of replicas that process events.

Final Exam Cheat Sheet

Topic	Key Point
KEDA	Event-driven autoscaling
Azure Container Apps + KEDA	KEDA integration is managed by Container Apps
Primary use case	Scale based on external events/metrics
Examples	Service Bus, Event Hubs, Kafka, Redis
`minReplicas`	Minimum replicas
`maxReplicas`	Maximum replicas
`minReplicas = 0`	Allows scale-to-zero
Scaler	Connects KEDA to an event source
Metadata	Configures the scaler
Authentication	Secrets or managed identity where supported
Default polling interval	30 seconds
Default cooldown	300 seconds
Target calculation	`ceil(metric / target)` conceptually
Multiple rules	Scaling can begin when an applicable rule triggers
Scaling-rule changes	Create a new Container Apps revision
Container App	Scales replicas
Event-driven Container Apps Job	Scales job executions
Primary benefit	Efficient scaling based on actual workload
Major advantage	Can scale inactive workloads to zero

The key idea to remember for AI-200 is simple: KEDA allows Azure Container Apps to scale containerized workloads according to events and external workload metrics rather than relying solely on traditional resource utilization such as CPU or memory.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026

Deploy applications to Azure Container Apps, including environment configuration and revision management (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Deploy applications to Azure Container Apps, including environment configuration and revision management

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.

Introduction

Azure Container Apps is a serverless container platform designed for running modern applications and microservices without requiring developers to manage the underlying Kubernetes infrastructure. For the AI-200 exam, developers should understand not only how to deploy a containerized application, but also how to configure its Container Apps environment, manage application settings, and use revisions to safely deploy and operate different versions of an application.

This topic is particularly important because Azure Container Apps separates the concepts of the application environment, the container application, and the revision. Understanding those boundaries makes many exam questions much easier to answer.

1. What Is Azure Container Apps?

Azure Container Apps provides a managed platform for running containerized applications while abstracting much of the infrastructure management associated with Kubernetes.

It is well suited for applications such as:

REST APIs
Web applications
Microservices
Background processing services
Event-driven applications
AI inference services
Containerized application backends

Unlike Azure Kubernetes Service, developers do not need to manage Kubernetes clusters, nodes, or the Kubernetes control plane.

Azure Container Apps can provide:

Containerized application hosting
Automatic scaling
Scale-to-zero capabilities
HTTP and TCP ingress
Service-to-service communication
Revisions and traffic splitting
Secrets and configuration
Managed identities
Dapr integration
Logging and monitoring
Workload profiles

For AI applications, Container Apps can be particularly useful for hosting APIs, inference services, orchestration components, and other containerized workloads.

2. Understand the Container Apps Environment

A Container Apps environment is a secure boundary around a group of Container Apps.

Multiple Container Apps can be deployed into the same environment. Apps within the same environment can share important infrastructure characteristics, including networking and logging. Microsoft describes the environment as a secure boundary for a group of container apps.

A useful mental model is:

Azure subscription → Resource group → Container Apps environment → Container Apps → Revisions

For example:

			
Subscription
│
└── Resource Group
    │
    └── Container Apps Environment
        │
        ├── customer-api
        │   ├── Revision 1
        │   ├── Revision 2
        │   └── Revision 3
        │
        ├── recommendation-api
        │   ├── Revision 1
        │   └── Revision 2
        │
        └── document-processor
            └── Revision 1

		

The environment therefore provides infrastructure-level isolation and shared capabilities, while the individual Container App represents an application or service running inside that environment.

3. Why the Environment Matters

When creating a Container App, you either select an existing Container Apps environment or create a new one.

Environment configuration can affect:

Networking
Logging
Workload profiles
Application isolation
Communication between applications
Infrastructure configuration

For example, applications deployed into the same environment can communicate with one another using Container Apps’ internal networking capabilities.

The environment can also be associated with logging infrastructure such as a Log Analytics workspace.

Exam Tip

If a question says that several Container Apps need to share a common environment, networking boundary, or logging configuration, think about the Container Apps environment rather than creating separate environments for every application.

4. Creating a Container App

A typical deployment involves the following conceptual steps:

Create or select a resource group.
Create or select a Container Apps environment.
Specify the container image.
Configure compute resources.
Configure environment variables and secrets.
Configure ingress if the application needs to receive traffic.
Configure scaling.
Deploy the application.
Monitor the resulting revision.

For example, Azure CLI can deploy an existing container image with a command conceptually similar to:

			
az containerapp create \
  --name my-container-app \
  --resource-group my-resource-group \
  --environment my-container-environment \
  --image myregistry.azurecr.io/myapp:v1 \
  --target-port 80 \
  --ingress external

		

The important exam concept is not memorizing the exact command syntax. Instead, understand which configuration belongs to the environment and which belongs to the Container App.

5. Container App Configuration vs. Revision Configuration

One of the most important concepts for AI-200 is that not every change to a Container App creates a new revision.

Azure Container Apps distinguishes between:

Revision-scope changes

These changes define the version of the application and result in a new revision.

Examples include changes to:

Container image
Container configuration
Container resources
Environment variables associated with the container template
Scale configuration
Scale rules
Container commands and arguments
Probes
Volumes and mounts
Revision suffix

The Container Apps API documentation describes the template as the versioned application definition, and changes to the template result in a new immutable revision.

Application-scope changes

These changes affect the Container App configuration rather than creating a new version of the application.

Examples include:

Revision mode
Ingress configuration
Traffic rules
Secrets
Registry credentials
Dapr configuration
Other application-level configuration

These settings apply to the application rather than representing a new immutable revision.

Exam shortcut

When deciding whether a change creates a revision, ask:

Does this change define the versioned application template?

If yes, it is generally a revision-scope change.

If it changes how the application is configured or exposed without changing the application template, it is generally an application-scope change.

6. What Is a Revision?

A revision is an immutable snapshot of a Container App’s versioned configuration.

Think of a revision as a deployable version of the application.

For example:

			
customer-api
│
├── Revision 1 → v1 container image
├── Revision 2 → v2 container image
└── Revision 3 → v3 container image

		

Once created, a revision is immutable.

If you change the container image from:

myapp:v1

to:

myapp:v2

Azure Container Apps creates a new revision rather than modifying the existing revision.

This provides an important deployment-management capability:

A deployed revision represents a known version of the application.

Microsoft’s documentation describes revisions as immutable, versioned snapshots that can remain available for rollback, testing, or traffic management.

7. Why Revisions Are Important

Revisions provide several important capabilities.

Version management

You can identify different versions of an application.

Safe deployments

A new revision can be deployed without immediately replacing the existing version in multiple-revision scenarios.

Rollbacks

If a new version fails, traffic can be directed back to a previous revision.

A/B testing

Different revisions can receive different percentages of traffic.

Blue-green deployments

One revision can serve production traffic while another is deployed and validated before switching traffic.

Testing

A new revision can be tested before directing production traffic to it.

These capabilities make revisions particularly valuable for AI applications where changes to models, inference code, prompts, dependencies, or APIs may need controlled deployment.

8. Single Revision Mode

Azure Container Apps supports single revision mode and multiple revision mode. Single revision mode is the default.

In single revision mode:

Only one revision is active at a time.
A new revision is created when a revision-scoped change is deployed.
Azure manages the transition from the old revision to the new revision.
Traffic moves to the new revision after it is ready.
The old revision is eventually deprovisioned.

This mode is useful when the desired deployment model is essentially:

“Deploy the new version and replace the old version.”

For example:

			
Before deployment:
100% traffic
     │
     ▼
Revision 1
After deployment:
100% traffic
     │
     ▼
Revision 2

		

9. Zero-Downtime Deployment

Single revision mode is designed to avoid unnecessary downtime during deployment.

When a new revision is created, the existing revision continues serving traffic while the new revision is provisioned.

The new revision must become ready before traffic is moved.

Readiness involves factors such as:

Successful provisioning
Required replicas becoming available
Startup probes passing
Readiness probes passing

Therefore, if a new revision fails to become ready, the existing revision can continue serving traffic rather than immediately being replaced.

Exam scenario

Suppose:

Revision 1 is healthy.
Revision 2 is deployed.
Revision 2 fails its readiness checks.

The safest answer is generally that Revision 1 continues receiving traffic in single revision mode while Revision 2 fails to become ready.

10. Multiple Revision Mode

Multiple revision mode allows multiple revisions to remain active simultaneously.

This provides significantly more control over deployments.

For example:

                 ┌── Revision 1 ── 80%
Incoming traffic ┤
                 └── Revision 2 ── 20%

This is useful for:

A/B testing
Canary releases
Blue-green deployments
Gradual rollouts
Testing a new application version
Maintaining multiple application versions

Microsoft’s traffic-splitting functionality allows traffic to be distributed among active revisions using percentage weights. The total traffic allocation must equal 100%.

11. Traffic Splitting

In multiple revision mode, traffic can be divided among revisions.

For example:

			
Revision 1 → 90%
Revision 2 → 10%

This means approximately 90% of incoming traffic is routed to Revision 1 and 10% to Revision 2.

A common deployment strategy is to gradually increase the percentage assigned to the new revision:

			
Stage 1
v1 = 100%
v2 =   0%
Stage 2
v1 =  90%
v2 =  10%
Stage 3
v1 =  50%
v2 =  50%
Stage 4
v1 =   0%
v2 = 100%

		

This provides a controlled rollout.

Important exam point

Traffic weights must add up to 100%.

For example:

			
Revision A = 70%
Revision B = 30%

is valid.

But:

			
Revision A = 70%
Revision B = 20%

does not fully allocate traffic.

12. Revision Labels

Revision labels provide a way to identify a particular revision with a meaningful name.

Instead of relying entirely on an automatically generated revision name, a developer can use a label representing an environment or deployment stage.

For example:

			
staging
production

A labeled revision can be accessed through a label-specific endpoint.

Labels can be useful when:

Testing a specific revision
Maintaining a staging version
Providing direct access to a particular revision
Performing deployment workflows
Separating testing traffic from production traffic

Azure CLI provides commands for managing revision labels, including adding, removing, and swapping labels.

13. Revision Names and Suffixes

Azure Container Apps automatically generates revision names, but developers can provide a meaningful revision suffix.

For example:

customer-api-v2

could be represented conceptually by a Container App named:

customer-api

with a revision suffix such as:

v2

Meaningful revision naming can make deployment management easier.

Good naming can help identify:

Application version
Deployment stage
Release identifier
Build number
Feature release

However, revision names and suffixes have naming restrictions, so applications should follow Azure’s supported naming rules rather than assuming arbitrary strings are valid.

14. Deploying a New Revision

A new revision is created when a revision-scope property changes.

For example, changing:

image = myregistry.azurecr.io/customer-api:v1

to:

image = myregistry.azurecr.io/customer-api:v2

creates a new revision.

Conceptually:

			
Revision 1
Image: customer-api:v1
       │
       │ deploy image v2
       ▼
Revision 2
Image: customer-api:v2

		

Revision 1 remains an independent immutable version.

This is one of the most important concepts to understand for exam questions involving deployments.

15. Rollbacks

Suppose Revision 2 introduces a serious problem:

			
Revision 1 → stable
Revision 2 → defective

In a multiple-revision deployment, traffic can be redirected back to Revision 1.

For example:

			
Before rollback:
Revision 1 → 20%
Revision 2 → 80%
After rollback:
Revision 1 → 100%
Revision 2 → 0%

		

The existing revision doesn’t need to be rebuilt because the previous revision already represents the known-good application version.

This is one of the primary benefits of immutable revisions.

16. Blue-Green Deployments

Azure Container Apps revisions can be used to implement a blue-green deployment strategy.

For example:

			
BLUE
Revision 1
Production
100% traffic
GREEN
Revision 2
New version
0% traffic

		

The new revision can be tested while receiving no production traffic.

Once validation is complete:

			
BLUE  → 0%
GREEN → 100%

The new version becomes the production version.

If a problem occurs:

			
BLUE  → 100%
GREEN → 0%

This provides a fast rollback mechanism.

17. Canary Deployments

Multiple revisions can also support a canary release.

For example:

			
Stable revision → 95%
New revision    → 5%

Only a small percentage of users initially reach the new version.

If the new version performs well, the deployment can gradually increase its traffic allocation:

This is especially useful for AI applications because a new model or inference implementation can be exposed to a limited portion of traffic before being fully deployed.

18. Scaling and Revisions

Scaling configuration can also be revision-scoped.

For example, a Container App might use:

			
Minimum replicas: 1
Maximum replicas: 10

and scale based on HTTP concurrency.

Changing the application’s scale configuration can result in a new revision because scale settings are part of the versioned template.

This is important because two revisions can potentially have different scaling configurations.

For example:

			
Revision 1
min replicas = 1
max replicas = 5
Revision 2
min replicas = 2
max replicas = 20

		

In multiple revision mode, these revisions can coexist with their respective configurations.

19. Ingress Configuration

Ingress determines how network traffic reaches a Container App.

Depending on the application, ingress can be:

External
Internal

External ingress makes the application accessible from outside the environment.

Internal ingress is useful when the application should only be reachable from within the environment or associated network configuration.

Container Apps supports HTTP and TCP-oriented ingress scenarios, with HTTP/1.1, HTTP/2, and TCP transport options depending on the configuration and workload.

Exam clue

If a question asks:

“The application must be accessible from the public internet.”

Look for an external ingress configuration.

If it asks:

“The API should only be accessible by other applications inside the Container Apps environment.”

Look for internal ingress.

20. Environment Variables

Containerized applications frequently require configuration values such as:

			
ENVIRONMENT=Production
MODEL_NAME=my-model
API_ENDPOINT=https://example

These values can be provided as environment variables.

Environment variables are part of the container configuration and therefore can be associated with a revision.

For example:

			
Revision 1
API_ENDPOINT = endpoint-v1
Revision 2
API_ENDPOINT = endpoint-v2

This is important when different application versions need different configuration.

21. Secrets

Sensitive information should not be hard-coded into container images.

Examples include:

API keys
Passwords
Connection strings
Tokens
Credentials

Azure Container Apps supports secrets that can be referenced by container environment variables.

Conceptually:

			
Container
   │
   └── Environment variable
           │
           └── secretRef
                    │
                    ▼
              Container App Secret

		

The Container Apps API supports environment variables that reference Container App secrets using secretRef.

For more advanced secret-management requirements, Azure Key Vault can be used rather than embedding credentials directly in the application.

Exam Tip

If the question asks where to store a password or API key, do not choose a Dockerfile or hard-coded environment variable.

Think:

Secret management → Container Apps secrets / Azure Key Vault

22. Private Container Registries

Container Apps can deploy images from private container registries.

For example:

			
Azure Container Registry
        │
        │ image
        ▼
Azure Container Apps

		

The Container App must have appropriate authorization to pull the image.

For Azure-hosted workloads, managed identities can often be used to avoid embedding long-lived credentials.

This follows an important security principle:

Prefer identity-based authentication over hard-coded credentials.

23. Container Apps and Azure Container Registry

A common AI-200 deployment architecture is:

			
Developer
   │
   ▼
Build container image
   │
   ▼
Azure Container Registry
   │
   ▼
Azure Container Apps
   │
   ├── Revision 1
   └── Revision 2

		

Azure Container Registry stores the container image while Azure Container Apps runs the container.

A new image version can then be deployed as a new revision.

For example:

			
my-ai-api:v1
my-ai-api:v2
my-ai-api:v3

Each deployment can correspond to a new revision.

24. Environment Configuration vs. Revision Management

A useful exam distinction is:

Concept	Purpose
Container Apps environment	Shared boundary and infrastructure context
Container App	The application/service
Revision	Immutable version of the application
Revision mode	Determines how revisions are activated
Ingress	Controls how traffic reaches the application
Traffic splitting	Determines how traffic is distributed
Revision label	Provides identifiable access to a revision
Secret	Stores sensitive configuration
Environment variable	Supplies application configuration
Scale configuration	Determines how the application responds to demand

Understanding these distinctions helps prevent choosing an answer that sounds plausible but operates at the wrong level.

25. A Typical Deployment Lifecycle

A production deployment might look like this:

Step 1 — Build

Create the container image.

			
AI application source
        ↓
Docker build
        ↓
Container image

		

Step 2 — Store

Push the image to Azure Container Registry.

			
Container image
        ↓
Azure Container Registry

Step 3 — Deploy

Deploy the image to Azure Container Apps.

			
Registry
   ↓
Container App
   ↓
Revision 1

		

Step 4 — Update

Deploy a new image.

			
Registry
   ↓
Container App
   ↓
Revision 2

		

Step 5 — Validate

Check:

Provisioning state
Running state
Replica health
Application logs
Health probes
Application metrics

Step 6 — Route traffic

In multiple revision mode:

			
Revision 1 → 90%
Revision 2 → 10%

Step 7 — Complete rollout

If the new revision is healthy:

			
Revision 1 → 0%
Revision 2 → 100%

Step 8 — Roll back if necessary

If problems appear:

			
Revision 1 → 100%
Revision 2 → 0%

This workflow illustrates why revisions are such an important Azure Container Apps capability.

26. Common Exam Traps

Trap 1: Assuming every configuration change creates a revision

Not every change creates a new revision.

Remember the distinction between revision-scope and application-scope configuration.

Trap 2: Assuming revisions are mutable

Revisions are immutable.

To change the versioned application configuration, deploy a new revision.

Trap 3: Confusing single and multiple revision modes

Single mode is designed around one active revision.

Multiple mode allows several revisions to be active simultaneously.

Trap 4: Using traffic splitting in single mode

Traffic splitting requires multiple active revisions.

If the question specifically requires distributing traffic between two versions, look for multiple revision mode.

Trap 5: Assuming a failed new revision automatically replaces the healthy one

Azure Container Apps provides mechanisms that help maintain availability during deployment. In single revision mode, the existing revision can continue serving traffic while the new revision is being prepared.

Trap 6: Confusing a Container Apps environment with a Container App

The environment is the broader hosting boundary.

The Container App is the actual application.

Multiple Container Apps can exist within an environment.

Trap 7: Hard-coding secrets into a container

Passwords and API keys should not be placed directly into application code or container images.

Use appropriate secret-management capabilities.

Trap 8: Forgetting that scale configuration can be revision-specific

Scale configuration belongs to the versioned application template and can therefore create a new revision when changed.

27. AI-200 Exam Summary

For the AI-200 exam, remember these core points:

Azure Container Apps provides managed hosting for containerized applications.
A Container Apps environment provides a secure boundary for a group of Container Apps.
Multiple Container Apps can share the same environment.
A revision represents an immutable version of a Container App.
Changes to revision-scoped properties create new revisions.
Application-scoped changes don’t create new revisions.
Single revision mode is the default.
Multiple revision mode allows multiple active revisions.
Traffic can be split between active revisions in multiple mode.
Traffic weights must total 100%.
Revisions support blue-green deployments.
Revisions support canary and A/B testing scenarios.
Previous revisions can provide a convenient rollback target.
Revision labels can provide meaningful access to particular revisions.
Environment variables provide application configuration.
Secrets should be used for sensitive values.
Container Apps can pull images from container registries such as Azure Container Registry.
Managed identities can reduce the need for embedded credentials.
Ingress determines how applications receive network traffic.
Health probes and application readiness are important during deployment.
Scaling configuration can be revision-specific.
Understanding the difference between environment, application, revision, and traffic configuration is essential for scenario-based questions.

Practice Exam Questions

Question 1

You deploy a container app named orders-api using revision 1. You then change the container image from orders:v1 to orders:v2.

What happens when the change is deployed?

A. Revision 1 is modified in place.

B. A new revision is created containing the new container image.

C. The Container Apps environment is recreated.

D. The application is automatically moved to another region.

Answer: B

Explanation

The container image is part of the versioned container template. Changing the image is therefore a revision-scope change, which causes a new immutable revision to be created. Revision 1 remains unchanged. Azure’s Container Apps API identifies the container template as versioned and states that changes to it create a new revision.

Question 2

An organization has three Container Apps that need to share a common networking boundary and logging infrastructure.

What should you create?

A. A separate revision for each application.

B. A single Container Apps environment containing the three applications.

C. A single container image containing all three applications.

D. A separate Azure Kubernetes Service cluster for each application.

Answer: B

Explanation

A Container Apps environment provides a secure boundary around a group of Container Apps. Applications within the same environment can share environment-level capabilities such as networking and logging.

Question 3

You need to gradually introduce a new version of an API. Initially, 95% of requests should go to the existing revision and 5% should go to the new revision.

Which configuration should you use?

A. Single revision mode with an environment variable.

B. A new Container Apps environment.

C. Multiple revision mode with traffic splitting.

D. A second container inside the same revision.

Answer: C

Explanation

Multiple revision mode allows multiple revisions to remain active simultaneously and supports percentage-based traffic splitting. This makes it appropriate for gradual or canary deployments.

Question 4

A Container App is currently configured in single revision mode. A developer deploys a new revision, but the new revision fails its readiness checks.

What is the expected behavior?

A. The existing healthy revision can continue serving traffic while the new revision fails to become ready.

B. All revisions are immediately deactivated.

C. The environment is automatically deleted.

D. Traffic is automatically divided equally between the failed and healthy revisions.

Answer: A

Explanation

In single revision mode, Azure Container Apps maintains the existing revision while the new revision is being provisioned. The new revision must become ready before traffic is moved to it. This helps support zero-downtime deployments.

Question 5

You need to deploy a new revision for testing while keeping the current production revision at 100% traffic. The test revision should remain available so developers can test it directly.

Which approach is most appropriate?

A. Use single revision mode and delete the production revision.

B. Create a second Container Apps environment and duplicate the application.

C. Modify the existing production revision in place.

D. Use multiple revision mode and keep the test revision active with appropriate traffic allocation or a revision label.

Answer: D

Explanation

Multiple revision mode allows several revisions to remain active. A revision can also be associated with a label to provide direct access to a particular revision. This is useful for staging and testing scenarios without immediately shifting production traffic.

Question 6

A developer changes an application’s revision mode from Single to Multiple.

Does changing the revision mode itself create a new revision?

A. Yes. Every configuration change creates a revision.

B. Yes, but only if traffic splitting is also configured.

C. No. Revision mode is an application-scope configuration.

D. No, because revision mode is stored in the container image.

Answer: C

Explanation

Revision mode is an application-scope configuration setting. Changing the revision mode does not itself create a new revision. Azure’s current API documentation identifies activeRevisionsMode as part of the non-versioned Container App configuration.

Question 7

An application has two active revisions configured with traffic weights of 70% and 20%.

What is wrong with this configuration?

A. Traffic splitting can only be 50/50.

B. Traffic weights must total 100%.

C. Multiple revision mode only supports two revisions.

D. Traffic splitting requires three revisions.

Answer: B

Explanation

Traffic weights define the percentage of incoming traffic routed to each revision. The combined weights must equal 100%. A 70% + 20% configuration accounts for only 90% of traffic.

Question 8

An AI inference API stores an Azure OpenAI API key in its container image.

What is the best improvement?

A. Move the key into a Dockerfile argument.

B. Put the key into the container image as an encrypted text file.

C. Store the key in a Container Apps secret or an appropriate external secret-management service such as Azure Key Vault.

D. Put the key directly into the application’s source code.

Answer: C

Explanation

Secrets such as API keys and passwords should not be embedded in source code or container images. Container Apps supports secrets that can be referenced by environment variables, while Azure Key Vault provides centralized secret management for more advanced scenarios. The Container Apps API supports secretRef for connecting environment variables to Container App secrets.

Question 9

You are implementing a blue-green deployment. Revision 1 is currently serving production traffic. Revision 2 contains a new version that has been fully tested.

What should you do to switch production to Revision 2 while retaining the ability to quickly roll back?

A. Delete Revision 1 immediately.

B. Update Revision 1 so it contains Revision 2’s code.

C. Create a new Container Apps environment and redirect DNS.

D. Shift production traffic from Revision 1 to Revision 2 while keeping Revision 1 available.

Answer: D

Explanation

Revisions are immutable versions of an application. A blue-green deployment can maintain the existing revision while the new revision is validated. Production traffic can then be shifted to the new revision. Keeping the previous revision available provides a straightforward rollback target if problems occur.

Question 10

You have an application running in multiple revision mode:

			
Revision A → 80%
Revision B → 20%

You change the container image used by Revision B.

What should you expect?

A. Revision B is modified in place while retaining its existing revision identity.

B. The Container Apps environment is recreated.

C. A new revision is created containing the changed container image.

D. Revision A is automatically deleted.

Answer: C

Explanation

The container image is part of the revision’s versioned template. Changing it creates a new revision rather than modifying the existing immutable revision. The new revision can then be activated and assigned traffic according to the application’s revision configuration.

Final Exam Takeaway

The easiest way to reason about Azure Container Apps deployment questions is to think in terms of layers:

			
CONTAINER APPS ENVIRONMENT
        │
        │  Shared hosting/networking boundary
        ▼
CONTAINER APP
        │
        │  Application configuration
        ▼
REVISION
        │
        │  Immutable version
        ▼
CONTAINER IMAGE + TEMPLATE + SCALE CONFIGURATION

		

Then ask:

Does the question involve the hosting boundary?
→ Think Container Apps environment.

Does it involve the application itself?
→ Think Container App configuration.

Does it change the versioned application template?
→ Think new revision.

Does it require multiple versions to run simultaneously?
→ Think multiple revision mode.

Does it require controlled percentages of traffic?
→ Think traffic splitting.

Does it require a gradual rollout?
→ Think canary deployment.

Does it require switching between old and new versions?
→ Think blue-green deployment.

Does it require returning to a known-good version?
→ Think previous revision and rollback.

Mastering those distinctions will cover a substantial portion of the scenario-based questions you are likely to encounter around deploying applications to Azure Container Apps for AI-200.

Go to the AI-200 Exam Prep Hub main page

azure, Cloud computing, Microsoft Certification August 15, 2026

Deploy containers to Azure App Service, including configuring App Service to supply environment variables and secrets (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Deploy containers to Azure App Service, including configuring App Service to supply environment variables and secrets

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 App Service is a fully managed platform-as-a-service (PaaS) offering that allows developers to host web applications, APIs, and containerized applications without managing the underlying virtual machines or operating system.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how to deploy a container image to App Service and, importantly, how to configure the application so that the container receives the configuration, environment variables, and secrets it needs at runtime.

This is particularly important for AI applications because containerized AI workloads commonly need configuration values such as:

Azure AI service endpoints
Model deployment names
Database connection information
Storage account names
Service Bus configuration
Application Insights configuration
Feature flags
API keys or other secrets

A well-designed application should not bake these values into the container image. Instead, configuration should be supplied by the hosting environment, with sensitive values preferably retrieved from a secure secret store such as Azure Key Vault.

1. Understand Azure App Service for Containers

Azure App Service can run applications packaged as custom container images. This allows developers to use their own runtime, dependencies, libraries, and operating-system configuration instead of relying exclusively on App Service’s built-in application stacks.

A typical architecture looks like this:

Developer → Container Image → Container Registry → Azure App Service → Running Container

For example:

A developer creates a Dockerfile.
The Dockerfile is used to build an image.
The image is pushed to Azure Container Registry.
App Service is configured to use that image.
App Service pulls the image.
App Service starts the container.
App Service supplies configuration values as environment variables.
The application reads those values at runtime.

App Service pulls the configured container image when the application starts. If an updated image is pushed to the registry, restarting the application causes App Service to pull the updated image.

This separation between the application image and the application configuration is an important concept for the exam.

2. Why Use Containers with App Service?

A custom container is useful when the application’s requirements don’t fit cleanly into one of App Service’s predefined runtime stacks.

For example, an AI application might require:

A particular Python version
Specific native libraries
Custom machine-learning packages
A specialized web server
OS-level dependencies
A combination of packages that isn’t available in a standard App Service stack

Instead of configuring all those dependencies on the App Service platform, you can package them into a container.

Key benefit

The container provides a consistent application environment.

The same image can potentially be used in:

Development
Testing
Staging
Production
Other container-hosting environments

This supports the important principle:

Build the application once and configure it differently for each environment.

The container should contain the application and its dependencies—not environment-specific secrets.

3. The Container Image and App Service Are Separate Concerns

One of the most important concepts to understand is the difference between the container image and the App Service configuration.

Container image

The image contains things such as:

Application code
Runtime
Dependencies
Libraries
System packages
Startup configuration

App Service configuration

App Service supplies environment-specific information such as:

Database endpoints
API endpoints
Feature flags
Environment names
Secret references
Connection information

This allows the same image to run in multiple environments.

For example:

			
Container Image
    |
    +-- Application code
    +-- Python runtime
    +-- Required libraries
    +-- AI SDKs
    |
    v
App Service
    |
    +-- ENVIRONMENT=Production
    +-- AI_ENDPOINT=...
    +-- MODEL_NAME=...
    +-- DATABASE_CONNECTION=...
    +-- API_KEY=<Key Vault reference>

		

The application doesn’t need a different Docker image simply because it is moving from development to production.

4. Deploying a Container to App Service

There are several ways to deploy a containerized application to App Service.

A common approach is:

			
Dockerfile
    ↓
docker build
    ↓
Container Image
    ↓
Azure Container Registry
    ↓
Azure App Service

		

For example, a container image might be named:

myregistry.azurecr.io/my-ai-api:v1

The registry name identifies the container registry.

The repository identifies the application:

my-ai-api

And the tag identifies a particular version:

v1

Therefore:

myregistry.azurecr.io/my-ai-api:v1

identifies a specific container image.

5. Configure the Container Image

When creating or configuring an App Service application, you specify the container image that App Service should run.

For an image hosted in Azure Container Registry, App Service needs access to the registry.

For a private registry, authentication must be configured.

Depending on the scenario, App Service can use authentication mechanisms such as managed identity rather than embedding registry credentials. Current App Service configuration also supports managed-identity-based access to Azure Container Registry, which is generally preferable to managing long-lived registry passwords.

Exam concept

When you see a question asking for the most secure way to allow App Service to pull a private image from Azure Container Registry, consider:

Managed identity and appropriate Azure role assignments

rather than storing a registry password in application configuration.

6. The Container’s Listening Port

A containerized application must listen on the appropriate port so App Service can route traffic to it.

For custom containers, the port configuration is particularly important.

For example, suppose the application listens on:

The application inside the container needs to listen on that port, and App Service needs to know which port to use.

A common App Service configuration is:

WEBSITES_PORT=8080

The WEBSITES_PORT application setting tells App Service which port the custom container is listening on. Microsoft specifically identifies WEBSITES_PORT as required for custom-container port configuration.

Example

Suppose the Dockerfile contains:

EXPOSE 8080

The application should also actually listen on port 8080.

Then App Service can be configured with:

WEBSITES_PORT = 8080

Important distinction

EXPOSE in a Dockerfile documents the port the container expects to use. It does not by itself guarantee that the application is actually listening on that port.

A common troubleshooting scenario is:

The container starts successfully, but the application isn’t reachable.

One of the first things to verify is whether the application is listening on the expected port and whether WEBSITES_PORT is configured correctly.

7. Environment Variables in App Service

App Service application settings are exposed to applications as environment variables.

This is one of the most important concepts for this exam topic.

For example, you could configure:

			
ENVIRONMENT = Production
MODEL_NAME = gpt-4o-mini
AI_ENDPOINT = https://example.openai.azure.com/

Your application can then read these values from its environment.

For Linux applications and custom containers, App Service passes application settings into the container as environment variables. Changes to App Service settings cause the application to restart.

This allows the application code to remain environment-independent.

8. Why Environment Variables Are Better Than Hard-Coding Configuration

Consider this application code:

AI_ENDPOINT = "https://production-ai.example.com"

This is problematic because the endpoint is embedded in the application.

A better approach is:

			
import os
AI_ENDPOINT = os.environ["AI_ENDPOINT"]

Then App Service supplies:

AI_ENDPOINT=https://production-ai.example.com

The same container can then be deployed elsewhere with:

AI_ENDPOINT=https://development-ai.example.com

without rebuilding the image.

This supports:

Environment portability
Easier deployments
Configuration management
Separation of code and configuration
Safer secret handling

9. Configure Application Settings

App Service application settings can be configured through the Azure portal, Azure CLI, PowerShell, ARM/Bicep, or other deployment mechanisms.

In the Azure portal, application settings are managed under the app’s environment/configuration settings.

For example, you might define:

Setting	Example value	Sensitive?
`APP_ENVIRONMENT`	`Production`	No
`AI_ENDPOINT`	`https://my-ai.openai.azure.com/`	Usually no
`MODEL_NAME`	`chat-model`	No
`LOG_LEVEL`	`Information`	No
`DATABASE_CONNECTION`	Connection information	Potentially
`API_KEY`	Secret value	Yes

App Service stores app settings encrypted at rest. However, for secrets that require centralized secret management, Microsoft recommends using Azure Key Vault references rather than directly storing the secret value in the App Service setting.

10. Secrets Should Not Be Baked into Container Images

This is a major security principle.

Avoid putting something like this in a Dockerfile:

ENV API_KEY="abc123secret"

Also avoid:

API_KEY = "abc123secret"

Why?

Because the secret can potentially become part of the image or source code and therefore propagate into:

Container registries
Image layers
Source repositories
Build systems
Developer machines
Backups
Logs

Instead:

			
Container Image
      +
App Service Configuration
      +
Azure Key Vault

		

should provide the necessary runtime configuration.

11. Azure Key Vault Integration

Azure Key Vault provides centralized management for secrets, keys, and certificates.

For App Service, Key Vault can be integrated using Key Vault references.

Instead of putting the actual secret into an App Service setting, the setting contains a reference to the secret.

Conceptually:

			
API_KEY
    ↓
@Microsoft.KeyVault(...)
    ↓
Azure Key Vault
    ↓
Secret value
    ↓
Application

		

The application can consume the resolved value as an ordinary environment variable.

One of the major benefits is that application code doesn’t need to contain Key Vault-specific retrieval logic just to consume a referenced application setting.

12. Key Vault References

A Key Vault reference has a format similar to:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)

Alternatively, a reference can use the vault and secret names:

@Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret)

A specific secret version can also be specified.

For example:

			
AI_API_KEY =
@Microsoft.KeyVault(VaultName=myvault;SecretName=AI-API-Key)

The application can continue to access the setting using the environment variable:

AI_API_KEY

The application doesn’t have to know that the value originated from Key Vault.

13. Managed Identity and Key Vault

For Key Vault references to work securely, App Service needs an identity that can access the Key Vault.

A recommended architecture is:

			
Azure App Service
       |
       | Managed Identity
       |
       v
Azure Key Vault
       |
       v
Secret

		

The application does not need to store a Key Vault username/password or service principal secret.

App Service Key Vault references use the app’s system-assigned managed identity by default, although a user-assigned managed identity can also be configured. The identity must have permission to read secrets from the vault. With Azure RBAC, the Key Vault Secrets User role is an appropriate role for reading secrets.

14. System-Assigned vs. User-Assigned Managed Identity

You should understand the difference for exam questions.

System-assigned managed identity

The identity is tied to the Azure resource.

For example:

			
App Service
    |
    +-- System-assigned identity

If the App Service is deleted, the identity is also deleted.

User-assigned managed identity

The identity is a separate Azure resource.

			
User-assigned identity
       |
       +---- App Service A
       |
       +---- App Service B

		

It can therefore be reused by multiple resources.

Exam consideration

If a scenario specifically requires an identity to exist before the application is created or requires reuse across several resources, a user-assigned managed identity may be more appropriate.

15. Key Vault Secret Rotation

Key Vault references can simplify secret rotation.

When a Key Vault reference doesn’t specify a particular secret version, App Service can use the latest version of the secret.

App Service caches Key Vault reference values and periodically refreshes them. Microsoft documents a refresh interval of up to 24 hours; configuration changes that restart the app can cause the references to be fetched immediately.

This is an important distinction:

Changing the secret in Key Vault does not necessarily mean that the application immediately receives the new value.

If an application must immediately consume a new value, you need to account for the Key Vault reference refresh behavior.

16. What Happens When a Key Vault Reference Fails?

Suppose App Service has:

			
AI_API_KEY =
@Microsoft.KeyVault(VaultName=myvault;SecretName=AI-Key)

but the managed identity doesn’t have permission to retrieve the secret.

The reference might fail to resolve.

Potential causes include:

Incorrect Key Vault name
Incorrect secret name
Secret deleted
Incorrect reference syntax
Managed identity not enabled
Missing Key Vault permissions
Network restrictions preventing access to Key Vault

App Service provides Key Vault reference resolution information that can help diagnose these problems.

Exam clue

If a question says:

The application receives the literal @Microsoft.KeyVault(...) value instead of the expected secret.

Think:

The Key Vault reference failed to resolve.

Then investigate identity, permissions, reference syntax, secret existence, and networking.

17. App Settings vs. Key Vault

A useful exam distinction is:

Requirement	Recommended approach
Non-sensitive configuration	App Service application setting
Environment-specific value	App Service application setting
Secret value	Azure Key Vault
Secret consumed as an environment variable	Key Vault reference in an App Service setting
Shared centralized configuration	Azure App Configuration
Application code	Do not hard-code secrets

App Service application settings are appropriate for ordinary configuration.

Key Vault should be preferred when the value is a secret requiring centralized secret management, access control, auditing, and rotation.

18. App Configuration vs. Key Vault

AI-200 also covers Azure App Configuration, so understand how it differs from Key Vault.

Azure App Configuration

Designed primarily for centralized application configuration.

Examples:

			
Feature flags
Application settings
Environment configuration
Dynamic configuration

Azure Key Vault

Designed for sensitive information such as:

			
Passwords
API keys
Connection secrets
Certificates
Cryptographic keys

		

A common architecture uses both:

                    +---------------------+
                    | Azure App Config     |
                    |                     |
                    | Feature flags       |
                    | Application config  |
                    +----------+----------+
                               |
                               |
Application <------------------+
     |
     |
     +------------------------+
                              |
                              v
                    +---------------------+
                    | Azure Key Vault     |
                    |                     |
                    | API keys            |
                    | Passwords           |
                    | Secrets             |
                    +---------------------+

Do not confuse centralized configuration with secret management.

19. Container Startup Commands

A container has a default startup command defined by its image.

However, App Service can override the startup behavior for a custom container.

This can be useful when:

The container’s default command isn’t appropriate.
The application requires a specific startup command.
Different hosting environments require different startup behavior.

For example:

python app.py

or:

gunicorn --bind 0.0.0.0:8080 app:app

App Service supports specifying a startup command for custom containers.

Exam clue

If a container image works locally but App Service starts it incorrectly, investigate:

Startup command
Listening port
Environment variables
Container logs
Image configuration

20. Environment Variables and Container Startup

Environment variables are available to the application when the container starts.

For example:

			
APP_ENVIRONMENT=Production
PORT=8080
MODEL_NAME=my-model

Your application might use:

			
import os
environment = os.getenv("APP_ENVIRONMENT")
model = os.getenv("MODEL_NAME")

The values can be changed in App Service without changing the container image.

This is especially valuable when promoting the same image through:

			
Development
     ↓
Testing
     ↓
Staging
     ↓
Production

		

Each environment can supply different configuration.

21. App Settings Cause Application Restarts

A frequently tested detail is that changing App Service application settings causes the application to restart.

This matters because configuration changes aren’t necessarily applied to an already-running process without interruption.

Microsoft documents that adding, removing, or modifying app settings causes an App Service app restart.

Therefore, if a scenario says:

An administrator changes an application setting and the application immediately restarts.

That is expected behavior.

22. Container Image Updates

Suppose App Service is configured to run:

myacr.azurecr.io/my-ai-api:latest

A developer builds a new version and pushes it using the same tag.

The registry now contains a newer image associated with latest.

However, simply pushing the new image doesn’t necessarily mean that an already-running container immediately changes.

Restarting the App Service causes it to pull the image again.

This is one reason immutable version tags are often preferable for controlled deployments.

For example:

			
my-ai-api:v1.0.0
my-ai-api:v1.1.0
my-ai-api:v2.0.0

rather than relying exclusively on:

my-ai-api:latest

23. Using `latest` vs. Versioned Tags

`latest`

Advantages:

Simple
Convenient for development

Disadvantages:

Doesn’t clearly identify what is deployed
Makes rollback more difficult
Can make troubleshooting harder
Can introduce unexpected image changes

Versioned tags

For example:

my-ai-api:1.4.2

Advantages:

Clear version identification
Easier rollback
Better deployment traceability
Easier troubleshooting

For production workloads, versioned image tags are generally a better operational practice.

24. Container Logs and Troubleshooting

When a container doesn’t start correctly, examine the container logs.

Common problems include:

Wrong port

The application listens on:

but App Service expects:

Application crashes

For example:

ModuleNotFoundError

or:

Connection refused

Incorrect environment variable

The application expects:

DATABASE_URL

but App Service defines:

DB_URL

Secret resolution failure

The Key Vault reference isn’t resolving.

Startup command failure

The command specified by App Service doesn’t exist or fails.

25. Container Startup Timeout

Custom containers sometimes take longer to initialize than expected.

App Service provides the WEBSITES_CONTAINER_START_TIME_LIMIT setting to control how long the platform waits for a container to start.

The documented default is 230 seconds, with a maximum of 1,800 seconds.

This can matter for AI applications that have relatively large startup workloads.

However, increasing the startup timeout should not be the first response to every startup problem.

First determine why startup is slow.

For example:

Is the container downloading dependencies at startup?
Is the application loading a large model?
Is it waiting for an external service?
Is the application listening on the wrong port?
Is the startup command incorrect?

26. HTTPS and Custom Containers

A custom container doesn’t necessarily need to implement HTTPS itself when hosted through App Service.

App Service can handle HTTPS termination at the platform’s front ends.

Therefore, an application can commonly listen for HTTP inside the container while clients connect to the application through HTTPS.

Conceptually:

			
Client
  |
 HTTPS
  |
  v
App Service
  |
 HTTP
  |
  v
Container

		

This is different from saying that application traffic is universally unprotected in every internal configuration; networking and security architecture still matter.

27. Continuous Deployment for Containers

App Service can integrate with container registries to support automated deployments.

A common flow is:

			
Developer
   |
   v
Source Repository
   |
   v
Build
   |
   v
Container Image
   |
   v
Azure Container Registry
   |
   v
App Service

		

A registry push can be used to trigger a deployment/restart workflow.

App Service supports continuous deployment scenarios involving container registries, including Azure Container Registry.

For production systems, CI/CD is generally preferable to manually rebuilding and deploying containers.

28. A Recommended AI Application Architecture

A reasonable architecture for an AI application hosted in a container on App Service might look like this:

                         Azure Container Registry
                                  |
                                  | Container Image
                                  v
                         +-------------------+
                         |   Azure App       |
                         |     Service       |
                         +---------+---------+
                                   |
                    +--------------+--------------+
                    |                             |
             Environment Variables          Managed Identity
                    |                             |
                    |                             v
                    |                      Azure Key Vault
                    |                             |
                    |                           Secrets
                    |
                    +--------------------+
                                         |
                                         v
                                  AI Application
                                         |
                  +----------------------+----------------+
                  |                      |                 |
                  v                      v                 v
             Azure AI             Azure Database      Azure Storage

The container image contains the application.

App Service provides environment-specific configuration.

Managed identity provides secure access to Azure resources.

Key Vault stores secrets.

This is a strong pattern to recognize in AI-200 scenario questions.

29. Security Best Practices

For the exam, remember these principles.

Don’t hard-code secrets

Avoid:

API_KEY=abc123

inside source code or Dockerfiles.

Don’t put secrets in image layers

Building a secret into an image doesn’t make it secure simply because the image is stored in a private registry.

Use managed identities

When Azure services support Microsoft Entra authentication and managed identities, prefer them over long-lived credentials.

Use Key Vault for secrets

Store sensitive values centrally.

Use least privilege

Grant the App Service identity only the permissions it requires.

Separate environments

Development, testing, and production should have appropriately separated configuration and secrets.

Use versioned images

Prefer:

myapp:1.2.3

over relying exclusively on:

myapp:latest

30. Important AI-200 Exam Concepts to Remember

The following relationships are particularly important:

Concept	Remember
Custom container	Runs your own container image in App Service
Azure Container Registry	Common private registry for App Service container images
App settings	Become environment variables
`WEBSITES_PORT`	Identifies the port used by a custom container
Startup command	Controls/overrides how the container application starts
Key Vault	Secure centralized secret management
Key Vault reference	Allows an App Service setting to reference a Key Vault secret
Managed identity	Avoids storing credentials for Azure resource access
System-assigned identity	Lifecycle tied to the Azure resource
User-assigned identity	Separate reusable identity resource
App setting changes	Cause an application restart
Image update	Restart causes App Service to pull the updated image
`latest`	Convenient but less predictable
Versioned tags	Better traceability and rollback
Container logs	Important for startup/runtime troubleshooting
`WEBSITES_CONTAINER_START_TIME_LIMIT`	Controls custom-container startup wait time

Practice Exam Questions

Question 1

You have a Python-based AI API packaged as a Linux container. The application listens on port 8080 inside the container.

You deploy the container to Azure App Service, but requests to the application fail because App Service cannot connect to the application.

Which App Service setting should you verify first?

A. WEBSITE_RESOURCE_GROUP

B. WEBSITE_SITE_NAME

C. WEBSITES_PORT

D. WEBSITE_SKU

Answer: C

Explanation

For custom containers, App Service needs to know which port the container is listening on. If the application listens on port 8080, configuring:

WEBSITES_PORT=8080

helps App Service route traffic to the correct container port.

The other settings describe the App Service environment but do not determine the container’s application port.

Question 2

An AI application is deployed as a container to Azure App Service. The application requires an API key that changes periodically.

The development team wants to avoid storing the API key in source code, the Dockerfile, or the container image.

Which solution provides the best approach?

A. Store the API key in the Dockerfile as an ENV value.

B. Store the API key in Azure Key Vault and reference it from an App Service application setting.

C. Store the API key in the container image and use a private Azure Container Registry.

D. Store the API key in the application’s source code and protect the repository with RBAC.

Answer: B

Explanation

Azure Key Vault is designed for centralized secret management. App Service can use a Key Vault reference as an application setting, allowing the application to consume the secret as an environment variable without embedding the secret in the image or source code.

A private container registry protects access to the image but does not make secrets embedded inside the image a good security practice.

Question 3

An Azure App Service application uses a Key Vault reference to retrieve an API key. The application is receiving the literal Key Vault reference string rather than the expected secret value.

Which issue should you investigate?

A. Whether the Dockerfile contains an EXPOSE instruction

B. Whether WEBSITES_PORT matches the application port

C. Whether the App Service managed identity has permission to read the Key Vault secret

D. Whether the image uses the latest tag

Answer: C

Explanation

A Key Vault reference must be resolved by App Service. The application’s managed identity needs permission to retrieve the referenced secret.

A missing or incorrectly configured identity, missing Key Vault permissions, an invalid secret name, or other Key Vault configuration problems can prevent resolution.

The port and image tag are unrelated to Key Vault reference resolution.

Question 4

A development team wants to deploy the same container image to development, test, and production environments. The AI endpoint differs between environments.

What is the best approach?

A. Build a separate Docker image for each environment.

B. Store all three endpoints in the Dockerfile and select one at runtime.

C. Create separate source-code branches containing different endpoint values.

D. Store the endpoint as an App Service application setting in each environment.

Answer: D

Explanation

Environment-specific configuration should be separated from the application image.

Each App Service environment can provide its own application setting:

AI_ENDPOINT=https://development...

or:

AI_ENDPOINT=https://production...

The same container image can therefore be deployed across environments.

Question 5

A developer pushes a new version of an image to Azure Container Registry using the same latest tag that an App Service application is already configured to use.

When should the developer expect App Service to retrieve the updated image?

A. When the running container is restarted

B. Immediately when the image is pushed

C. Only when the App Service plan is resized

D. Only after the image tag is deleted

Answer: A

Explanation

App Service pulls the configured container image when the application starts. If an updated image is pushed using the same tag, restarting the App Service causes the updated image to be pulled.

This is one reason explicit version tags are often preferable for controlled production deployments.

Question 6

An organization wants an App Service application to retrieve secrets from Azure Key Vault without storing a Key Vault password or service principal secret in the application.

Which feature should be used?

A. Docker ENV instructions

B. Managed identity

C. App Service startup command

D. Container port mapping

Answer: B

Explanation

Managed identity allows Azure resources such as App Service to authenticate to supported Azure services without requiring developers to store credentials in application configuration.

For Key Vault references, App Service can use its system-assigned managed identity by default or a configured user-assigned identity.

Question 7

An AI container deployed to App Service takes approximately five minutes to initialize because it performs a large initialization operation before listening for HTTP traffic.

The platform terminates the container before initialization completes.

Which setting can be used to increase the amount of time App Service waits for the container to start?

A. WEBSITES_PORT

B. WEBSITE_SITE_NAME

C. WEBSITES_CONTAINER_START_TIME_LIMIT

D. WEBSITE_WARMUP_PATH

Answer: C

Explanation

WEBSITES_CONTAINER_START_TIME_LIMIT controls how long App Service waits for a custom container to start.

The documented default is 230 seconds and the maximum is 1,800 seconds.

However, increasing the timeout should be done only after determining that the startup delay is legitimate rather than caused by a configuration or application problem.

Question 8

An application administrator changes the value of an App Service application setting.

What should the administrator expect?

A. The setting changes only the next time a new container image is deployed.

B. The setting changes the Dockerfile stored in Azure Container Registry.

C. App Service restarts the application so that the new setting can be supplied to the application environment.

D. The setting automatically modifies the source code in the application repository.

Answer: C

Explanation

App Service application settings are supplied to the application as environment variables. Changes to application settings cause the application to restart, allowing the new configuration to be supplied to the running application.

The setting does not modify the container image, Dockerfile, or source repository.

Question 9

You are designing a production AI application running in a custom container on Azure App Service. The application requires an API key.

Which design provides the strongest separation between application code and the secret?

A. Store the secret in Azure Key Vault and expose it to the application through an App Service Key Vault reference.

B. Store the secret in the Dockerfile using an ENV instruction.

C. Store the secret in a text file inside the container image.

D. Store the secret in the application’s source code and restrict repository access.

Answer: A

Explanation

A Key Vault reference allows the secret to remain in Azure Key Vault while the application consumes it through an App Service configuration setting.

This provides better separation between:

Application code
Container image
Deployment configuration
Secrets

The App Service managed identity can be granted the minimum required permissions to retrieve the secret.

Question 10

An organization has multiple App Service applications that need to use the same identity when accessing Azure Key Vault. The identity must also be able to exist independently of the lifecycle of any individual App Service application.

Which type of managed identity should be used?

A. System-assigned managed identity

B. App Service publishing credentials

C. User-assigned managed identity

D. Container registry administrator credentials

Answer: C

Explanation

A user-assigned managed identity is a standalone Azure resource that can be assigned to multiple Azure resources.

This makes it appropriate when:

Multiple applications need the same identity.
The identity needs an independent lifecycle.
The identity must exist before an application is created.
The organization wants to reuse the identity across resources.

A system-assigned identity is tied to the lifecycle of its associated Azure resource.

Final Exam Takeaways

For AI-200, the most important mental model is:

The container image contains the application; App Service supplies the environment-specific configuration; Key Vault protects sensitive values; managed identity provides secure access to Azure resources.

When you encounter an exam scenario, think through the problem in this order:

Where is the container image?
- Azure Container Registry?
- Another private registry?
- Public registry?
Can App Service pull the image?
- Is authentication configured?
- Would managed identity be appropriate?
What port does the application actually listen on?
- Does it match the App Service configuration?
- Is WEBSITES_PORT configured appropriately?
How does the application receive configuration?
- App Service application settings
- Environment variables
Does the configuration contain a secret?
- Use Azure Key Vault rather than embedding the secret in the image or source code.
How does App Service access Key Vault?
- Managed identity
- Appropriate Key Vault permissions
Is the container starting correctly?
- Startup command
- Container logs
- Port
- Environment variables
- Startup timeout
How is the image version managed?
- Prefer identifiable/versioned image tags for production deployments.
- Understand what happens when an image behind a tag is replaced.

These distinctions—particularly App Service settings vs. container image contents, environment variables vs. secrets, Key Vault references vs. hard-coded credentials, and system-assigned vs. user-assigned managed identities—are exactly the kinds of distinctions that can turn a plausible answer into the correct AI-200 answer.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026

Build and Run Images by Using Azure Container Registry Tasks (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Build and Run Images by Using Azure Container Registry Tasks

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 Container Registry Tasks (ACR Tasks) provides cloud-based capabilities for building, testing, and managing container images in Azure Container Registry (ACR).

ACR Tasks is particularly useful when developers want to move container image builds into the cloud rather than relying on a locally installed Docker engine. It can support simple on-demand builds, automated builds triggered by source-code or base-image changes, and more sophisticated multi-step workflows involving multiple containers.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand not only how to execute an ACR Task, but also when to use each type of task, how build contexts work, how images are tagged, how multi-step tasks are defined, how tasks are triggered, and how tasks can securely access other resources.

Microsoft’s AI-200 training specifically identifies building and managing container images in the cloud with ACR Tasks and using the Azure CLI to run ACR quick tasks as learning objectives.

1. What Are Azure Container Registry Tasks?

ACR Tasks is a collection of capabilities within Azure Container Registry that allows you to perform container image operations in Azure.

At a high level:

			
Source Code / Dockerfile
          |
          v
     ACR Task
          |
    +-----+-----+
    |           |
    v           v
   Build       Test
    |           |
    +-----+-----+
          |
          v
    Container Image
          |
          v
          ACR

		

ACR Tasks can:

Build container images in Azure
Push images to ACR
Run containers as part of a task
Test container images
Build multiple images
Execute steps sequentially or in parallel
Automatically trigger builds from source-code changes
Automatically rebuild images when base images change
Run tasks on a schedule
Integrate into CI/CD workflows

ACR Tasks supports Linux, Windows, and ARM image platforms, depending on the configuration and supported scenarios.

2. Why Use ACR Tasks?

A traditional container development workflow might look like this:

			
Developer Computer
       |
       +-- Docker build
       |
       +-- Docker test
       |
       +-- Docker push
       |
       v
Azure Container Registry

		

This requires the developer’s machine to have the appropriate container tooling.

With an ACR Task:

			
Developer
    |
    | Azure CLI
    v
Azure Container Registry
    |
    +-- Build
    +-- Test
    +-- Push

		

The build is performed in Azure.

This has several advantages:

No local Docker Engine is required for an ACR quick task.
Builds can be standardized.
Builds can be automated.
Container images can be built close to the registry.
Build workflows can be triggered by source-code changes.
Base-image updates can automatically initiate rebuilds.
More complex build/test workflows can be defined using YAML.

Microsoft describes quick tasks as an integrated development experience that offloads container image builds to Azure and can perform the equivalent of docker build and docker push in the cloud.

3. Three Important ACR Task Scenarios

For AI-200, understand these three categories:

Task type	Primary purpose
Quick task	On-demand build and push
Automatically triggered task	Automatically execute when an event occurs
Multi-step task	Build, test, run, and push multiple images/workflows

These aren’t mutually exclusive concepts.

For example, a multi-step task can also be automatically triggered by a Git commit.

4. Quick Tasks

A quick task is an on-demand container image build performed in Azure.

It is particularly useful during development.

The Azure CLI command is:

az acr build

For example:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The final . represents the build context.

Conceptually, this performs:

			
Dockerfile + build context
          |
          v
      ACR Task
          |
          v
     Build image
          |
          v
      Push image
          |
          v
          ACR

		

The important point is that the build takes place in Azure rather than requiring a local Docker engine.

ACR Tasks’ quick-build capability is essentially a cloud-based equivalent of performing a Docker build and push operation.

5. Understanding the Build Context

One of the most important concepts when using az acr build is the build context.

Consider:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The . specifies the current directory as the build context.

The build context contains files that are available to the Docker build process.

For example:

			
orders-api/
│
├── Dockerfile
├── requirements.txt
├── app.py
└── src/

		

Running:

az acr build ... .

makes that directory the build context.

The context can also come from other supported locations, including source repositories.

6. Dockerfile and ACR Tasks

ACR Tasks uses familiar Docker build syntax.

For example:

			
FROM python:3.12
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

		

You can then build the image with:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The Dockerfile defines how the container image is constructed.

ACR Tasks handles the build environment and performs the build in Azure.

7. Specifying a Dockerfile

If the Dockerfile has a different name or location, specify it using --file.

For example:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    --file Dockerfile.production \
    .

		

You can also specify a Dockerfile located elsewhere relative to the build context.

The important exam concept is:

The build context and Dockerfile are related but are not necessarily the same thing.

The Dockerfile describes the build instructions.

The build context identifies the files available to the build.

8. ACR Tasks Versus Local Docker Builds

Consider this traditional command:

docker build -t orders-api:v1 .

With ACR Tasks, you can use:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The conceptual difference is:

Local Docker	ACR Tasks
Build occurs locally	Build occurs in Azure
Requires Docker Engine	No local Docker Engine required for quick tasks
Image initially exists locally	Image can be pushed directly to ACR
Developer manages build environment	Azure provides the task execution environment

This distinction is a likely source of scenario-based exam questions.

9. Building Without a Local Docker Engine

Suppose a developer has:

Azure CLI
Access to an Azure Container Registry
A Dockerfile
Application source code

but doesn’t have Docker installed.

The developer can still build the image using:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

This is one of the strongest scenarios for recognizing ACR Tasks on the exam.

10. Running an Image with ACR Tasks

ACR Tasks can also run containers as part of a task.

The cmd step is used for this purpose in multi-step tasks.

For example:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID

The cmd step runs a container using the specified image.

This makes it possible to use ACR Tasks for testing.

For example:

			
Build image
    |
    v
Run image
    |
    v
Execute tests
    |
    v
Push image

		

The cmd step supports parameters similar to familiar container-run operations, including environment variables and detached execution.

11. Multi-Step Tasks

A multi-step task allows you to create a more sophisticated container workflow.

Instead of simply:

Build → Push

you can implement:

			
Build
  |
  v
Run
  |
  v
Test
  |
  v
Push

		

You can also build multiple images:

             +--> Build API ----+
             |                  |
Source ------+                  +--> Test --> Push
             |                  |
             +--> Build Worker -+

Multi-step tasks are defined in a YAML file.

Microsoft identifies three primary ACR Tasks step types:

build
push
cmd

12. The `build` Step

The build step builds a container image.

Example:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .

Conceptually, this is similar to:

docker build

but the build is performed within the ACR Tasks environment.

The image name should identify the image that the task builds.

13. The `push` Step

The push step pushes an image to a container registry.

Example:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

		

The build step creates the image.

The push step publishes it to the registry.

An important exam distinction is that in a multi-step az acr run task, you should not assume that a built image is automatically pushed simply because it was built. The task definition can explicitly use a push step to publish it.

14. The `cmd` Step

The cmd step executes a container.

For example:

			
version: v1.1.0
steps:
  - cmd: bash:3.0 echo "Hello from ACR Tasks"

It can also execute an image produced by an earlier build:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID

This is especially useful for testing.

The cmd step can use environment variables and other execution options.

15. Build, Test, and Push

A common ACR Tasks pattern is:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID
  - push:
      - $Registry/orders-api:$ID

		

Conceptually:

             BUILD
               |
               v
          Container Image
               |
               v
              TEST
               |
         Tests successful
               |
               v
              PUSH
               |
               v
              ACR

This pattern can prevent an image from being pushed until validation has occurred.

16. Step Dependencies

ACR Tasks allows steps to have dependencies.

The when property can specify which previous steps must complete before a step executes.

For example:

			
version: v1.1.0
steps:
  - id: build
    build: -t $Registry/orders-api:$ID .
  - id: test
    cmd: $Registry/orders-api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/orders-api:$ID
    when: ["test"]

		

The sequence is:

			
build
  |
  v
test
  |
  v
push

		

This allows the task to express workflow dependencies explicitly.

17. Parallel Execution

ACR Tasks can also execute independent steps concurrently.

For example:

			
version: v1.1.0
steps:
  - id: build-api
    build: -t $Registry/api:$ID .
    when: ["-"]
  - id: build-worker
    build: -t $Registry/worker:$ID ./worker
    when: ["-"]

		

The special:

when: ["-"]

indicates that the step has no dependency on another step and can begin immediately.

Therefore:

        +--> Build API ---+
        |                 |
START --+                 +--> Continue
        |                 |
        +--> Build Worker-+

This can reduce total task execution time when operations are independent.

Microsoft’s ACR Tasks YAML reference specifically documents when: ["-"] for steps that have no dependency and can execute concurrently.

18. Build Dependencies Versus Sequential Steps

If when isn’t specified, a step is dependent on the previous step in the task definition.

For example:

			
steps:
  - id: build
    build: -t $Registry/api:$ID .
  - id: test
    cmd: $Registry/api:$ID
  - id: push
    push:
      - $Registry/api:$ID

		

This naturally produces:

build → test → push

If explicit dependencies are needed, use when.

19. Running an ACR Task

The Azure CLI command commonly used to execute a task definition is:

az acr run

For example:

			
az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    .

You can also use a Git repository as the context.

For example:

			
az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    https://github.com/example/project.git

The task receives the specified source context and executes the defined workflow.

20. `az acr build` Versus `az acr run`

This is an important distinction for AI-200.

`az acr build`

Designed primarily for a quick cloud-based image build.

Example:

			
az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

Think:

Build an image quickly in Azure.

`az acr run`

Executes an ACR Tasks workflow.

Example:

			
az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    .

Think:

Run a defined task workflow.

A multi-step task uses az acr run.

21. ACR Tasks Run Variables

ACR Tasks provides built-in run variables.

These variables can be used to create standardized image names and tags.

One particularly useful variable is:

Run.ID

which can be represented in task YAML using the $ID alias.

For example:

			
steps:
  - build: -t $Registry/orders-api:$ID .

This gives each task run a unique identifier that can be incorporated into the image tag.

ACR Tasks also provides variables associated with:

Registry
Registry name
Run ID
Date
Operating system
Architecture
Git commit
Git branch
Task name

22. Why Use Unique Build Tags?

Suppose every build uses:

orders-api:latest

You lose an easy way to distinguish individual builds.

Instead, you could use:

			
orders-api:build-123
orders-api:build-124
orders-api:build-125

ACR Tasks’ run ID can help automate this.

For example:

			
steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

This produces unique image references for individual runs.

This is especially useful for CI/CD scenarios.

23. Automatically Triggered Tasks

ACR Tasks can automatically execute based on events.

Important trigger scenarios include:

Source-code updates

A task can run when code is committed to a supported Git repository.

For example:

			
Developer commits code
        |
        v
Git repository
        |
        v
ACR Task trigger
        |
        v
Build image
        |
        v
Push image

		

Base-image updates

A task can be triggered when a base image changes.

For example:

FROM python:3.12

If the base image is updated, an ACR Task can rebuild the application image.

This is useful for automatically incorporating updated OS or framework components.

Scheduled execution

ACR Tasks can also support scheduled execution.

For example:

			
Every night
     |
     v
ACR Task
     |
     v
Build/test image

		

Microsoft documents source-code, base-image, and timer-based triggers as ACR Tasks automation scenarios.

24. Base Image Update Triggers

Base image triggers are especially relevant to security and maintenance.

Suppose:

FROM ubuntu:24.04

A security update causes a newer version of the base image to become available.

Without automation:

			
Base image updated
       |
       X
Application image remains unchanged

With an ACR Task:

			
Base image updated
       |
       v
ACR Task trigger
       |
       v
Rebuild application image
       |
       v
Push updated image

		

This allows organizations to automatically rebuild images when their dependencies change.

Microsoft describes this scenario as a way to automate OS and framework patching for container images.

25. Source-Code Triggers

ACR Tasks can integrate with source repositories.

For example:

			
Git commit
    |
    v
ACR Task
    |
    +-- Build
    +-- Test
    +-- Push

		

This provides a simple cloud-based container CI workflow.

A task can be configured to respond to commits and, depending on the configuration, pull-request activity in supported Git repositories.

26. Multi-Container Workflows

ACR Tasks becomes particularly valuable when an application contains multiple containers.

Suppose you have:

			
Web API
Worker
Test suite

You could define:

			
Build API
    |
Build Worker
    |
Run tests
    |
Push API
    |
Push Worker

		

Or independent builds could execute concurrently:

            +--> Build API -----+
            |                   |
START ------+                   +--> Test --> Push
            |                   |
            +--> Build Worker --+

Multi-step tasks are designed specifically for these types of workflows.

27. ACR Tasks and CI/CD

ACR Tasks can be incorporated into a broader CI/CD architecture.

For example:

			
Developer
    |
    v
Git Repository
    |
    v
ACR Task
    |
    +--> Build
    |
    +--> Test
    |
    +--> Push
    |
    v
Azure Container Registry
    |
    v
Container Apps / AKS / App Service

		

ACR Tasks is therefore not merely a command for building images. It can serve as a container lifecycle building block within an automated development process.

28. Accessing Other Registries

An ACR Task may need to access images or artifacts outside the registry where the task runs.

For example:

			
ACR Task
   |
   | Pull base image
   v
External Registry

		

or:

			
ACR Task
   |
   | Push image
   v
Another Registry

		

ACR Tasks supports authentication mechanisms for accessing protected resources.

Managed identities are particularly useful when an ACR Task needs to access other Azure resources without embedding credentials in the task definition.

Microsoft documents both system-assigned and user-assigned managed identities for ACR Tasks.

29. Managed Identities for ACR Tasks

An ACR Task can have a managed identity.

Two types are available:

System-assigned managed identity

The identity is associated with the specific ACR Task resource.

Its lifecycle is tied to that resource.

User-assigned managed identity

The identity is an independent Azure resource that can be assigned to multiple resources.

This can be useful when the same identity needs to be reused.

The key exam concept is:

Managed identities allow ACR Tasks to access protected Azure resources without embedding credentials in the task definition.

30. ACR Tasks and Azure Key Vault

ACR Tasks can also integrate with Azure Key Vault for scenarios where a task needs access to secrets.

A secure architecture might look like:

                 Azure Key Vault
                       |
                       | Secret
                       v
ACR Task ------ Managed Identity
                       |
                       v
                  Build/Test

This is preferable to hard-coding credentials into Dockerfiles, scripts, or task definitions.

31. Security Considerations

When designing ACR Task workflows:

Avoid putting secrets directly on command lines

Command-line arguments can potentially be captured by diagnostic or logging systems.

Avoid embedding credentials in Dockerfiles

A Dockerfile should not contain permanent passwords, tokens, or keys.

Prefer managed identities

When the target resource supports identity-based authentication, managed identities reduce credential-management overhead.

Use least privilege

Give the task only the permissions it needs.

Be careful with external registry credentials

If a task must access another private registry, configure authentication appropriately rather than placing credentials in source code.

Microsoft specifically warns that information supplied through command lines or URIs can appear in ACR diagnostic tracing, including sensitive values.

32. Task YAML Structure

A basic multi-step task looks like:

			
version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

		

A more sophisticated task could look like:

			
version: v1.1.0
steps:
  - id: build-api
    build: -t $Registry/orders-api:$ID .
  - id: test-api
    cmd: $Registry/orders-api:$ID
    when: ["build-api"]
  - id: push-api
    push:
      - $Registry/orders-api:$ID
    when: ["test-api"]

		

The key elements are:

Element	Purpose
`version`	YAML task format version
`steps`	Defines task operations
`build`	Builds an image
`push`	Pushes an image
`cmd`	Runs a container
`id`	Gives a step an identifier
`when`	Defines dependencies
`$Registry`	Registry run-variable alias
`$ID`	Run ID alias

ACR Tasks currently supports YAML as the task-definition format.

33. A Complete Build-Test-Push Example

Consider an API application with:

			
Dockerfile
src/
tests/

A multi-step task could conceptually perform:

			
version: v1.1.0
steps:
  - id: build
    build: -t $Registry/orders-api:$ID .
  - id: test
    cmd: $Registry/orders-api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/orders-api:$ID
    when: ["test"]

		

The workflow becomes:

                  +----------------+
                  |     Source     |
                  +-------+--------+
                          |
                          v
                       BUILD
                          |
                          v
                    Container Image
                          |
                          v
                        TEST
                          |
                    Tests pass
                          |
                          v
                        PUSH
                          |
                          v
                         ACR

This is an excellent pattern to recognize in scenario-based questions.

34. `az acr build` Versus Multi-Step Tasks

A useful exam comparison is:

Requirement	Appropriate approach
Build one image now	`az acr build`
Build image without local Docker	`az acr build`
Build and push a simple image	Quick task
Build and test an image	Multi-step task
Build several images	Multi-step task
Run a container during a workflow	`cmd` step
Push an image from a multi-step task	`push` step
Trigger from Git commit	Automatically triggered ACR Task
Rebuild when base image changes	Base-image trigger
Run periodically	Scheduled task

35. Common Exam Traps

Trap 1: Choosing Azure Container Instances

ACR Tasks is about building and managing container image workflows.

Azure Container Instances is primarily about running containers.

If the question says:

“Build a container image in Azure without installing Docker locally.”

Think:

ACR Tasks

not Azure Container Instances.

Trap 2: Confusing ACR with ACR Tasks

ACR is the registry.

ACR Tasks provides cloud-based build and automation capabilities.

Think:

			
ACR
 ↓
Store images
ACR Tasks
 ↓
Build/test/automate images

		

Trap 3: Assuming `az acr run` and `az acr build` are identical

They are not.

az acr build is designed for the quick cloud build scenario.

az acr run executes a task definition or command in the ACR Tasks environment.

Trap 4: Assuming every build automatically pushes an image

For a quick az acr build, the resulting image is pushed to the registry by default.

For an az acr run multi-step task, you should explicitly define a push step when you want to push the built image.

This distinction is explicitly documented in the ACR Tasks YAML reference.

Trap 5: Using `cmd` when you need to build an image

cmd runs a container.

build builds a container image.

Remember:

			
build → create image
cmd   → run container
push  → publish image

Trap 6: Ignoring the build context

The build context determines what files are available to the Docker build.

A Dockerfile alone isn’t necessarily sufficient if it references files from the context.

Trap 7: Putting secrets in the Dockerfile

Never assume that a secret belongs in:

ENV PASSWORD=...

or:

RUN some-command --password ...

Use appropriate Azure identity and secret-management mechanisms instead.

36. AI-200 Exam-Focused Review

Make sure you understand the following:

ACR Tasks

Cloud-based container build and automation capabilities.

Quick task

On-demand image build, commonly using:

az acr build

`az acr run`

Executes an ACR task workflow or command.

Build context

The files supplied to the container build.

`build`

Builds a container image.

`push`

Pushes an image to a registry.

`cmd`

Runs a container as part of a task.

`when`

Defines dependencies between task steps.

`$Registry`

Identifies the registry associated with the task run.

`$ID`

Identifies the current task run and can be used to generate unique tags.

Multi-step task

Supports complex workflows involving building, testing, running, and pushing containers.

Source trigger

Automatically runs a task when supported source-code changes occur.

Base-image trigger

Automatically rebuilds images when a base image changes.

Scheduled trigger

Runs tasks according to a schedule.

Managed identity

Allows a task to access protected Azure resources without embedding credentials.

37. The Mental Model to Remember

For AI-200, think of ACR Tasks as a cloud-based container build and automation engine attached to Azure Container Registry.

                    SOURCE
                       |
             +---------+---------+
             |                   |
          Dockerfile          Git Repo
             |                   |
             +---------+---------+
                       |
                       v
                  ACR TASK
                       |
          +------------+------------+
          |            |            |
        BUILD         CMD         PUSH
          |            |            |
          |          TEST           |
          |            |            |
          +------------+------------+
                       |
                       v
                  ACR IMAGE
                       |
                       v
             Container Service
        +----------+----------+
        |          |          |
       AKS    Container Apps  App Service

The most important distinction is:

ACR stores the image; ACR Tasks builds, tests, and automates the image lifecycle.

Practice Exam Questions

Question 1

A developer has a Dockerfile and application source code but does not have Docker installed locally. The developer needs to build the image in Azure and store it in an Azure Container Registry.

Which command should the developer use?

A. az container create

B. az acr repository create

C. az acr build

D. az aks create

Answer: C

Explanation: az acr build performs a cloud-based container image build using Azure Container Registry Tasks. The build occurs in Azure, so a local Docker Engine isn’t required for this scenario. The command can build and push the resulting image to ACR.

Question 2

A development team wants to create an automated workflow with the following steps:

Build an API container image.
Run the image.
Execute functional tests.
Push the image only if the tests succeed.

Which ACR Tasks capability should be used?

A. A multi-step task

B. ACR geo-replication

C. An ACR repository

D. An Azure Container Apps revision

Answer: A

Explanation: Multi-step ACR Tasks are designed for workflows that combine multiple container operations. The build, cmd, and push step types can be combined, and dependencies can be defined using the when property. This allows testing to occur before the image is pushed.

Question 3

An ACR Task contains the following YAML:

			
steps:
  - id: build
    build: -t $Registry/api:$ID .
  - id: test
    cmd: $Registry/api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/api:$ID
    when: ["test"]

		

What is the purpose of when: ["test"] on the final step?

A. It causes the push to run before testing

B. It causes the push to run concurrently with testing

C. It causes the push step to be skipped

D. It makes the push step dependent on successful completion of the test step

Answer: D

Explanation: The when property establishes dependencies between task steps. Here, the push step depends on the step identified as test, so it won’t execute until the test step completes successfully.

Question 4

An organization wants an ACR Task to automatically rebuild application images whenever a new version of a base image becomes available.

Which trigger should be configured?

A. A repository namespace trigger

B. A base-image update trigger

C. A container restart trigger

D. An Azure Monitor alert trigger

Answer: B

Explanation: ACR Tasks supports base-image update triggers. When the configured base image changes, the task can automatically rebuild the application image. This is particularly useful for incorporating updated operating-system and framework components.

Question 5

An ACR Task needs to execute two independent image builds at the same time. Which YAML configuration allows the steps to start without depending on another task step?

A. when: ["-"]

B. when: ["parallel"]

C. when: ["async"]

D. when: ["none"]

Answer: A

Explanation: In ACR Tasks, when: ["-"] indicates that the step has no dependency on another step and can begin immediately. This can allow independent steps to execute concurrently.

Question 6

A developer wants to create a unique container image tag for every ACR Task execution. Which ACR Tasks variable is specifically designed to identify the current task run?

A. $Branch

B. $Registry

C. $ID

D. $Architecture

Answer: C

Explanation: $ID is an ACR Tasks alias for the current run ID. It can be used to create unique image tags, such as:

-t $Registry/api:$ID

This is useful for distinguishing images produced by different task executions.

Question 7

A multi-step ACR Task has the following steps:

			
steps:
  - build: -t $Registry/api:$ID .
  - push:
      - $Registry/api:$ID

What is the primary purpose of the push step?

A. Run the container

B. Upload the built image to a container registry

C. Compile the Dockerfile

D. Create an Azure Container Apps revision

Answer: B

Explanation: The push step publishes a built or retagged container image to a container registry. The build step creates the image; push publishes it.

Question 8

An organization wants an ACR Task to execute whenever developers commit code to a supported Git repository. Which capability should be configured?

A. A source-code trigger

B. An ACR retention policy

C. An ACR private endpoint

D. A container health probe

Answer: A

Explanation: ACR Tasks supports source-code triggers that can automatically execute builds or multi-step tasks when changes occur in supported Git repositories. This provides a simple mechanism for integrating container builds into a CI workflow.

Question 9

An ACR Task must access a protected Azure resource. The organization doesn’t want credentials embedded in the task definition.

Which approach provides the most appropriate Azure-native solution?

A. Store the credential in the Dockerfile

B. Put the password in the task’s command line

C. Use a managed identity for the ACR Task

D. Make the Azure resource publicly accessible

Answer: C

Explanation: ACR Tasks can use system-assigned or user-assigned managed identities to access protected resources without embedding credentials in task definitions. The identity must be granted the required permissions on the target resource.

Question 10

A developer executes:

			
az acr build \
    --registry myregistry \
    --image orders-api:v2 \
    .

What does the final . represent?

A. The ACR registry name

B. The image tag

C. The Docker image digest

D. The build context

Answer: D

Explanation: The final . specifies the current directory as the build context. Files in the build context are made available to the Docker build process. The Dockerfile and files referenced during the build generally need to be available through the selected context.

Key Takeaways

For the AI-200 exam, remember these relationships:

Concept	Remember
ACR	Stores and manages container images
ACR Tasks	Builds, runs, tests, and automates container workflows
`az acr build`	Performs an on-demand cloud image build
`az acr run`	Runs an ACR Tasks workflow/command
Build context	Files supplied to the image build
`build`	Creates a container image
`cmd`	Runs a container
`push`	Publishes an image to a registry
`when`	Controls task-step dependencies
`when: ["-"]`	Allows an independent step to start immediately
`$ID`	Current task run identifier
`$Registry`	Registry associated with the task
Multi-step task	Build/test/run/push workflows
Source trigger	Run when source code changes
Base-image trigger	Rebuild when a base image changes
Scheduled trigger	Run according to a schedule
Managed identity	Secure access without embedding credentials

The single most useful mental model for this objective is:

                  ACR TASKS
                      |
       +--------------+--------------+
       |              |              |
     BUILD           CMD            PUSH
       |              |              |
   Create image    Run/test       Publish image
       |              |              |
       +--------------+--------------+
                      |
                      v
                     ACR

And when the exam gives you a scenario, ask:

Do I need to build an image in Azure? → az acr build / ACR Tasks
Do I need multiple build/test/run operations? → Multi-step ACR Task
Do I need to execute a container? → cmd
Do I need to publish an image? → push
Do steps have dependencies? → when
Do independent steps need to run concurrently? → when: ["-"]
Should builds happen automatically after source changes? → Source trigger
Should images rebuild when a base image changes? → Base-image trigger
Does the task need secure access to another Azure resource? → Managed identity
Do I need unique image versions for task runs? → Use $ID in the image tag

These distinctions are especially important because AI-200 scenario questions are likely to test which ACR Tasks capability best fits a particular development or deployment requirement, rather than simply asking you to recall an individual command.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026August 15, 2026

Build, Store, Version, and Manage Container Images by Using Azure Container Registry (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Build, store, version, and manage container images by using Azure Container Registry

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 Container Registry (ACR) is a managed, private registry service in Azure for storing and managing container images and other OCI-compatible artifacts. It provides a central location from which containerized applications can obtain the images they need to run on services such as Azure App Service, Azure Container Apps, Azure Kubernetes Service (AKS), and Azure Container Instances.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand more than simply how to push an image into ACR. You should be comfortable with the hierarchy of registries, repositories, images, tags, manifests, and layers; image versioning strategies; building images using ACR Tasks; managing and deleting images; and selecting appropriate authentication and registry capabilities.

The current Microsoft Learn study guide specifically identifies this objective as part of Implement container application hosting. It also separately identifies ACR Tasks as an exam objective, so understanding how ACR stores images and how ACR Tasks builds them is particularly important.

1. What Is Azure Container Registry?

Azure Container Registry is a private container registry service hosted in Azure.

A container registry solves a fundamental problem in containerized application development:

Where do applications securely obtain the container images they need to run?

Instead of relying exclusively on a public registry, an organization can maintain its own private registry in Azure.

A typical workflow looks like this:

			
Developer
    |
    | Build container image
    v
Docker / ACR Tasks
    |
    | Push
    v
Azure Container Registry
    |
    +------------------+
    |                  |
    v                  v
Azure App Service     AKS
    |                  |
    v                  v
Container Apps       Container workloads

		

ACR provides capabilities for:

Storing container images
Storing OCI artifacts
Organizing images into repositories
Tagging and versioning images
Pushing and pulling images
Building images using ACR Tasks
Managing image metadata
Controlling access
Replicating images across regions
Integrating with Azure container services

Microsoft describes ACR as a private, managed registry that supports building, storing, and managing images for container deployments.

2. Understand the ACR Hierarchy

One of the most important concepts for AI-200 is understanding how ACR organizes container content.

The hierarchy can be thought of as:

			
Azure Container Registry
        |
        +-- Repository
        |      |
        |      +-- Image : Tag
        |      +-- Image : Tag
        |      +-- Image : Tag
        |
        +-- Repository
               |
               +-- Image : Tag
               +-- Image : Tag

		

The important concepts are:

Registry
Repository
Artifact/Image
Tag
Manifest
Layer
Digest

Understanding the distinctions between these concepts is a common source of exam questions.

2.1 Registry

The registry is the overall ACR resource.

For example:

contosoregistry.azurecr.io

The registry provides the endpoint through which clients push and pull container images.

A registry can contain many repositories.

2.2 Repository

A repository is a collection of related container images or artifacts.

For example:

contosoregistry.azurecr.io/customer-api

The repository could contain:

			
customer-api:v1
customer-api:v2
customer-api:v3

Repositories can also use namespaces:

contosoregistry.azurecr.io/marketing/campaign-api:v2

Namespaces help organize repositories logically, although they aren’t independent Azure resources or hierarchical security boundaries simply because they contain / characters.

Microsoft notes that repository names can include namespaces and are managed independently by the registry.

3. Container Image Tags

A tag provides a human-readable identifier for a particular version or variant of an image.

For example:

			
customer-api:v1
customer-api:v2
customer-api:2026-08-07
customer-api:production

The complete image reference might be:

contosoregistry.azurecr.io/customer-api:v2

The structure is:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/customer-api:v2

where:

Component	Value
Registry	`contosoregistry.azurecr.io`
Repository	`customer-api`
Tag	`v2`

Microsoft recommends using appropriate tagging strategies for deployment scenarios and notes that latest is used by default when no tag is specified in Docker commands.

4. Tagging and Versioning Strategies

Image versioning is extremely important for reliable deployments.

Consider:

customer-api:latest

This tag is convenient, but it does not necessarily identify an immutable version.

Suppose today’s latest points to:

Image A

and tomorrow the same tag is updated:

latest → Image B

A deployment configured to use latest may therefore receive a different image without its configuration changing.

For production deployments, a better approach is generally to use unique version identifiers.

Examples:

			
customer-api:v1.0.0
customer-api:v1.1.0
customer-api:v1.2.0

or:

			
customer-api:20260807.1
customer-api:20260807.2

or a source-control commit identifier:

customer-api:a81f42c

A useful pattern is:

			
latest       → convenient development/testing reference
v1.4.2       → human-readable release
a81f42c      → unique build identifier

Exam Tip

If a question asks how to ensure that a deployment consistently uses a specific image version, be cautious about answers using:

:latest

A unique tag or, even more strongly, an image digest provides better version specificity.

5. Image Digests

Container images are also identified by a digest.

For example:

contosoregistry.azurecr.io/customer-api@sha256:abc123...

A digest identifies the content associated with a manifest.

Compare:

customer-api:v2

with:

customer-api@sha256:abc123...

A tag can be moved to point to another image.

A digest identifies a specific content-addressed version.

Microsoft specifically notes that pulling by digest guarantees the image version being retrieved even if an identically tagged image is subsequently pushed.

Exam Tip

Remember:

Tag = human-friendly version reference

Digest = content-addressed, precise image reference

6. Container Image Layers

Container images consist of one or more layers.

Dockerfiles commonly create multiple layers.

For example:

			
FROM python:3.12
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .

The resulting image is composed of layers.

One of the advantages of layers is reuse.

If two images share the same base layers, those layers don’t necessarily have to be independently stored and transferred each time.

This can reduce storage and transfer requirements.

7. Manifests

A container image is associated with a manifest.

The manifest contains information needed to identify the image and its layers.

Conceptually:

			
Image Manifest
      |
      +-- Configuration
      |
      +-- Layer 1
      +-- Layer 2
      +-- Layer 3

		

The manifest is also associated with the image’s digest.

This distinction matters when managing images in ACR.

For example, removing a tag doesn’t necessarily mean that all image data is immediately removed.

An untagged manifest and its associated layers may continue to consume storage until they are deleted and no longer referenced.

Microsoft specifically warns that repeatedly pushing modified artifacts with identical tags can create untagged artifacts that continue consuming registry storage.

8. Pushing an Image to ACR

A common workflow is:

Step 1: Build the image

docker build -t customer-api:v1 .

Step 2: Tag the image with the ACR login server

			
docker tag customer-api:v1 \
    contosoregistry.azurecr.io/customer-api:v1

Step 3: Authenticate to ACR

az acr login --name contosoregistry

Step 4: Push the image

			
docker push \
    contosoregistry.azurecr.io/customer-api:v1

The image is now stored in:

contosoregistry.azurecr.io/customer-api

with the tag:

v1

9. Pulling an Image

A client can pull the image by tag:

			
docker pull \
    contosoregistry.azurecr.io/customer-api:v1

Or by digest:

			
docker pull \
    contosoregistry.azurecr.io/customer-api@sha256:<digest>

The second approach provides stronger guarantees regarding exactly which image content is retrieved.

10. Azure Container Registry Tasks

One of the most important ACR features for AI-200 is ACR Tasks.

ACR Tasks allows container images to be built in Azure rather than requiring the developer to perform the build locally.

Microsoft describes ACR Tasks as a suite of capabilities for building, testing, and managing container images.

For example:

			
az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    --file Dockerfile .

The command:

Sends the build context to Azure.
Uses the Dockerfile.
Builds the image in Azure.
Tags the resulting image.
Pushes the resulting image into the registry.

This is particularly useful when a developer doesn’t have Docker installed locally.

Microsoft’s current quickstart explicitly demonstrates building, pushing, and running an image using ACR Tasks without requiring a local Docker installation.

11. ACR Tasks Quick Tasks

A quick task is useful for an on-demand image build.

For example:

			
az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    .

This is useful during the development inner loop.

Instead of:

			
Developer machine
    |
    +-- docker build
    +-- docker tag
    +-- docker push

		

you can use:

			
Developer
    |
    | az acr build
    v
Azure
    |
    +-- Build
    +-- Tag
    +-- Push
    v
ACR

		

12. Automated ACR Tasks

ACR Tasks can also be configured to automatically execute when certain events occur.

For example:

			
Git commit
     |
     v
ACR Task
     |
     +-- Build image
     +-- Test image
     +-- Push image

		

ACR Tasks can also respond to base image updates.

For example, suppose an application uses:

FROM python:3.12

A base-image update can trigger an ACR Task to rebuild the application image.

This is useful for keeping application images current when their base images change.

Microsoft documents ACR Tasks triggers for Git commits and base-image updates.

13. Multi-Step ACR Tasks

ACR Tasks can execute more sophisticated workflows.

For example:

			
Build application image
        |
        v
Run application
        |
        v
Run test container
        |
        v
Push image

		

Multi-step tasks are defined using YAML.

A simplified example is:

			
version: v1.1.0
steps:
  - build: -t $Registry/customer-api:$ID .
  - push:
      - $Registry/customer-api:$ID
  - cmd: $Registry/customer-api:$ID

		

ACR Tasks supports three major step types:

Step	Purpose
`build`	Build a container image
`push`	Push an image to a registry
`cmd`	Run a container as a command

Exam Tip

If a question describes a workflow that needs to build, test, and push multiple containers, think:

ACR Tasks multi-step task

14. ACR Tasks and External Registries

ACR Tasks can also interact with other registries.

For example, a task may need to:

			
ACR
 |
 +-- Pull base image from another registry
 |
 +-- Build application
 |
 +-- Push application image to ACR

		

Credentials can be configured for tasks when access to another registry is required.

For more secure scenarios, ACR Tasks can use managed identities to access protected Azure resources without embedding credentials directly in task definitions.

15. Authentication to Azure Container Registry

ACR is generally private, so clients need appropriate authentication and authorization to access it.

Common authentication approaches include:

Microsoft Entra identities
Managed identities
Service principals
Administrator credentials
Repository-scoped access mechanisms
Anonymous pull, where explicitly configured and supported

Microsoft’s documentation emphasizes that ACR operations such as push and pull require authentication unless anonymous pull is enabled.

16. Managed Identity and ACR

Managed identities are particularly important in Azure-native applications.

Suppose an AKS cluster needs to pull an image:

			
AKS
 |
 | Managed Identity
 v
Azure Container Registry
 |
 v
customer-api:v1

		

Rather than storing a registry password in application configuration, the Azure resource can use a managed identity and appropriate permissions.

For a non-ABAC-enabled registry, a common pull-only role is:

AcrPull

For push and pull:

AcrPush

For ABAC-enabled registries, Microsoft documents repository-scoped roles such as:

			
Container Registry Repository Reader
Container Registry Repository Writer

The exact role depends on the registry’s authorization model.

Exam Tip

When the question says:

“An Azure service needs to pull images from ACR without storing credentials.”

Think:

Managed identity + appropriate ACR permissions

17. ACR Pricing Tiers

Azure Container Registry currently provides three pricing tiers:

Basic
Standard
Premium

The tiers provide increasing capacity and capabilities.

Capability	Basic	Standard	Premium
Intended use	Lower-volume scenarios	Production scenarios	High-volume/advanced scenarios
Included storage	10 GiB	100 GiB	500 GiB
Geo-replication	No	No	Yes
Private endpoints	No	No	Yes
Content trust	No	No	Yes
Customer-managed keys	No	No	Yes
Dedicated Tasks agent pools	No	No	Yes
Higher throughput/concurrency	Lower	Medium	Higher

All three tiers provide core registry capabilities, while Premium adds advanced capabilities and higher limits.

Important Exam Distinction

If the requirement is:

“Replicate a registry across multiple Azure regions.”

Think:

Premium ACR

Geo-replication is a Premium feature.

18. Geo-Replication

Geo-replication allows an ACR to replicate its content across multiple Azure regions.

For example:

                 Azure Container Registry
                          |
             +------------+------------+
             |                         |
             v                         v
         East US                  West Europe
        Geo-replica               Geo-replica
             |                         |
             v                         v
          AKS US                  AKS Europe

When an image is pushed to the geo-replicated registry, its content is synchronized to the configured replicas.

The advantage is that applications can access images from regions closer to where they run.

Microsoft describes geo-replication as providing a single registry management experience while synchronizing content across selected regions.

Don’t confuse:

Availability zones and geo-replication.

Availability zones provide resilience across zones within a region.

Geo-replication distributes registry content across different Azure regions.

Current Microsoft documentation states that zone redundancy is enabled by default for ACR registries in supported regions across Basic, Standard, and Premium tiers.

19. Managing Images and Repositories

You can manage repositories and images through:

Azure portal
Azure CLI
REST APIs
SDKs
Docker/OCI tooling

For example, you can list repositories:

			
az acr repository list \
    --name contosoregistry \
    --output table

List tags:

			
az acr repository show-tags \
    --name contosoregistry \
    --repository customer-api \
    --output table

You can also inspect manifests and image metadata.

The Azure portal exposes repositories and their image tags through the registry’s Repositories interface.

20. Deleting Images

Suppose a repository contains:

			
customer-api:v1
customer-api:v2
customer-api:v3

You can remove an image tag using Azure CLI.

For example:

			
az acr repository untag \
    --name contosoregistry \
    --image customer-api:v1

However, remember an important distinction:

Untagging an image does not necessarily immediately remove the underlying image data.

The manifest may become untagged while its layers continue consuming storage.

Microsoft specifically warns about the accumulation of untagged artifacts when images are repeatedly pushed using the same tags.

21. Retention of Untagged Manifests

ACR supports a retention policy for untagged manifests.

The purpose is to automatically remove untagged manifests after a configured period.

For example:

			
Image:v1
Image:v2
Image:v3

If v2 is removed:

Image:v2 → untagged manifest

A retention policy can eventually remove the untagged manifest.

The current Microsoft documentation identifies the untagged-manifest retention policy as a Premium feature and currently documents it as a preview feature. The policy can be configured for a retention period from 0 through 365 days.

Important Warning

If an application relies on pulling an image by its digest, automatically deleting untagged manifests can make that image unavailable.

This is an important operational consideration and a potential exam scenario.

22. Image Tagging Best Practices

A strong production tagging strategy should make image identification predictable.

A useful approach is to use multiple tags for different purposes.

For example:

			
customer-api:v2.4.1
customer-api:build-1847
customer-api:a81f42c

You might also maintain:

customer-api:production

as a deployment-oriented alias.

However, don’t rely on a mutable tag such as production or latest when you require immutable deployment behavior.

A good pattern is:

			
Human-readable release
        +
Unique build identifier
        +
Optional environment alias

		

For example:

			
customer-api:v2.4.1
customer-api:build-1847
customer-api:production

The production deployment can ultimately be pinned to a specific immutable image reference/digest.

23. Common ACR Mistakes

Mistake 1: Using `latest` for production deployments

latest can change.

Better: use unique version tags and/or digests.

Mistake 2: Assuming deleting a tag deletes the image immediately

An untagged manifest may continue consuming storage.

Better: understand manifests, layers, untagging, deletion, and retention.

Mistake 3: Giving every workload push permissions

An application that only needs to run an image generally doesn’t need permission to push images.

Better: follow least privilege.

For example:

			
Application → AcrPull
Build pipeline → AcrPush

Mistake 4: Storing registry passwords in application code

This creates unnecessary credential-management risks.

Better: use managed identities or another appropriate identity mechanism.

Mistake 5: Choosing Premium solely because it sounds better

Premium should be selected because its capabilities are required.

Examples include:

Geo-replication
Private endpoints
Content trust
Higher throughput
Advanced networking
Dedicated Tasks agent pools

Mistake 6: Confusing ACR with ACR Tasks

They are related but different concepts.

ACR:

Stores and manages container images.

ACR Tasks:

Builds, tests, and automates container image workflows.

A single ACR resource can therefore be used to store images while ACR Tasks provides the automation to build those images.

24. Important AI-200 Concepts to Know

For this exam objective, make sure you can explain the following without referring to documentation:

Concept	What you should know
Azure Container Registry	Managed private container registry
Registry	Top-level ACR resource
Repository	Collection of related images/artifacts
Tag	Human-readable image/version reference
Digest	Content-addressed image reference
Manifest	Describes image/artifact and its layers
Layer	Component of a container image
`az acr login`	Authenticates a client to ACR
`docker push`	Uploads an image to ACR
`docker pull`	Downloads an image from ACR
`az acr build`	Builds an image using ACR Tasks
ACR Tasks	Cloud-based image build/test automation
Multi-step task	Build/test/push workflows using YAML
`AcrPull`	Pull permission for applicable non-ABAC registry scenarios
`AcrPush`	Push/pull permission for applicable non-ABAC registry scenarios
Managed identity	Credential-free Azure resource authentication
Basic	Entry-level ACR tier
Standard	Higher capacity production-oriented tier
Premium	Advanced capabilities such as geo-replication/private endpoints
Geo-replication	Replicate registry content across regions
Retention policy	Automatically remove eligible untagged manifests

25. AI-200 Scenario Patterns to Recognize

The exam is likely to test your ability to choose the appropriate Azure capability based on a scenario.

Scenario: Build without Docker locally

Requirement: Developers don’t have Docker installed.

Answer: ACR Tasks / az acr build.

Scenario: Automatically rebuild after a Git commit

Requirement: Every source-code commit should trigger an image build.

Answer: ACR Task with a source-code trigger.

Scenario: Rebuild after base image updates

Requirement: Automatically rebuild application images when their base image changes.

Answer: ACR Tasks base-image trigger.

Scenario: Run the same image in several Azure regions

Requirement: Applications in multiple regions should access registry content efficiently.

Answer: ACR Premium with geo-replication.

Scenario: Application only needs to pull images

Requirement: A workload should retrieve images but shouldn’t be able to modify them.

Answer: Grant an appropriate pull-only role, such as AcrPull where applicable, or the appropriate repository reader role for an ABAC-enabled registry.

Scenario: Avoid credentials in application configuration

Requirement: An Azure-hosted application needs to access ACR without storing passwords.

Answer: Managed identity + appropriate registry permissions.

Scenario: Guarantee a specific image

Requirement: A deployment must always retrieve exactly the same image content.

Answer: Use an image digest rather than relying solely on a mutable tag.

26. Quick Review

The following mental model is useful for the exam:

                    AZURE CONTAINER REGISTRY
                             |
             +---------------+---------------+
             |                               |
        Repositories                    ACR Tasks
             |                               |
      +------+------+                  Build/Test/Push
      |             |
   Image          Image
      |             |
    Tags          Tags
      |             |
   Manifest      Manifest
      |
    Layers

And remember the major distinction:

			
ACR
 ↓
Store/manage images
ACR Tasks
 ↓
Build/test/automate images

		

For production deployments:

			
Avoid:
    :latest
Prefer:
    :v2.4.1
    :build-1847
    @sha256:<digest>

		

For authentication:

			
Azure workload
      |
      | Managed Identity
      v
     ACR
      |
      | Appropriate least-privilege role
      v
    Pull image

		

For global deployments:

			
ACR Premium
     |
     +---- Region 1
     |
     +---- Region 2
     |
     +---- Region 3

		

Practice Exam Questions

Question 1

A development team has a Dockerfile and wants to build a container image directly in Azure. Developers should not need Docker installed on their local computers. The resulting image should be pushed to Azure Container Registry.

Which Azure capability should you use?

A. Azure Container Registry Tasks

B. Azure App Service deployment slots

C. Azure Container Apps revisions

D. Azure Kubernetes Service Jobs

Answer: A

Explanation: Azure Container Registry Tasks can build container images in Azure using a Dockerfile. The az acr build command provides an on-demand build capability and can push the resulting image to ACR. A local Docker installation isn’t required for this workflow.

Question 2

An application image is stored as:

contosoregistry.azurecr.io/orders:v4

What does v4 represent?

A. The registry name

B. The image tag

C. The image digest

D. The repository namespace

Answer: B

Explanation: In an image reference such as:

registry/repository:tag

the portion after the colon is the tag. Therefore, v4 is the image tag. Tags are commonly used to identify image versions.

Question 3

A production application must always retrieve exactly the same container image content. Developers are concerned that a tag could later be reassigned to a different image.

Which image reference should the application use?

A. :latest

B. :production

C. :stable

D. @sha256:<digest>

Answer: D

Explanation: Tags can be moved to different image versions. A digest is a content-addressed identifier and can be used to pull a specific image version. Microsoft specifically identifies digest-based pulls as a way to guarantee the image version being retrieved.

Question 4

An organization deploys applications to Azure regions in North America and Europe. The organization wants container images to be replicated to both regions while maintaining a single ACR management experience.

Which ACR capability should be used?

A. Repository namespaces

B. Availability zones

C. Geo-replication

D. Image tags

Answer: C

Explanation: ACR geo-replication synchronizes registry content across selected Azure regions while allowing the organization to manage the registry as a single logical registry. Geo-replication is a Premium ACR capability.

Question 5

An AKS workload needs to pull private container images from ACR. The organization does not want to store registry passwords in Kubernetes configuration.

Which approach is most appropriate?

A. Use a managed identity with appropriate ACR permissions

B. Store the ACR administrator password in the container image

C. Make the repository publicly accessible

D. Embed an ACR password in the application source code

Answer: A

Explanation: Azure resources can use managed identities to authenticate to ACR without storing credentials in application code or configuration. The identity must be granted the appropriate pull permissions.

Question 6

A development team wants an automated container workflow that performs the following:

Builds an application image.
Runs a test container.
Builds another image.
Pushes the resulting images.

Which ACR capability should the team use?

A. ACR repository namespaces

B. ACR multi-step Tasks

C. ACR geo-replication

D. ACR anonymous pull

Answer: B

Explanation: ACR Tasks supports multi-step workflows using YAML. The workflow can build, run/test, and push one or more images. The available step types include build, push, and cmd.

Question 7

An organization repeatedly pushes new builds using the same image tag. After several months, the registry contains significant amounts of storage that cannot be explained by the currently tagged images.

What is the most likely explanation?

A. ACR automatically creates a new repository for every push

B. Geo-replication is duplicating every image within the same region

C. Previous manifests became untagged while their image data remained in the registry

D. ACR stores every Dockerfile indefinitely

Answer: C

Explanation: Repeatedly pushing modified images using the same tag can result in previous manifests becoming untagged. Their layers can continue consuming registry storage until the underlying content is deleted.

Question 8

A company needs to automatically rebuild its application container whenever a new version of the application’s base container image becomes available.

Which capability should be configured?

A. Azure App Service deployment slots

B. ACR geo-replication

C. ACR repository tagging

D. An ACR Task with a base-image update trigger

Answer: D

Explanation: ACR Tasks can automatically trigger builds when a base image is updated. This is useful for rebuilding application images when their underlying base images change.

Question 9

An organization requires private connectivity to its Azure Container Registry through Azure Private Link. Which ACR pricing tier supports this capability?

A. Premium

B. Basic

C. Standard

D. All three tiers

Answer: A

Explanation: Azure Container Registry Premium supports private endpoints through Private Link. Basic and Standard do not provide this capability according to the current ACR SKU documentation.

Question 10

An administrator removes the v1 tag from an image in an ACR repository. The administrator assumes that the underlying image data has immediately been removed from the registry.

Which statement is correct?

A. Removing a tag always immediately deletes every associated layer

B. Removing a tag converts the image automatically into a public image

C. Removing a tag deletes the entire repository

D. The manifest can become untagged while its data continues consuming storage

Answer: D

Explanation: Removing a tag can leave the manifest untagged while its associated data remains in the registry. Untagged artifacts can continue consuming storage until they are deleted. ACR provides mechanisms such as retention policies for eligible untagged manifests.

Final AI-200 Takeaways

For this particular AI-200 objective, concentrate on these distinctions:

Azure Container Registry

Store and manage container images and artifacts.

ACR repository

Organizes related images.

Tag

Human-readable version/reference that can be reassigned.

Digest

Content-addressed identifier for a specific image version.

Manifest

Describes the image/artifact and its layers.

ACR Tasks

Build, test, and automate container image workflows.

az acr build

Perform an on-demand cloud-based container build.

Multi-step ACR Task

Build/test/push multiple images or perform multi-stage workflows.

Managed identity

Authenticate Azure workloads to ACR without managing passwords.

AcrPull

Pull permission for applicable non-ABAC registry scenarios.

AcrPush

Push/pull permission for applicable non-ABAC registry scenarios.

Premium

Required for capabilities such as geo-replication and private endpoints.

Geo-replication

Replicate registry content across Azure regions.

Retention

Help clean up eligible untagged manifests.

The most important exam mindset is to distinguish where the image is stored, how it is identified, how it is built, and how the workload is authorized to retrieve it. Those four dimensions—registry/repository, tag/digest, ACR Tasks, and authentication/RBAC—cover a large portion of the practical knowledge behind this objective.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Databases, NoSQL August 8, 2026August 15, 2026

Implement a change feed processor to detect and handle new or updated items (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Implement a change feed processor to detect and handle new or updated items

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 Cosmos DB for NoSQL provides a change feed that records changes made to items in a container. Applications can consume this feed to react to data changes without repeatedly querying the entire container.

For the AI-200 exam, an important implementation pattern is the change feed processor. It provides a push-based mechanism for detecting changes and delivering them to application code for processing.

A change feed processor is particularly useful when an application needs to perform an action whenever items are created or updated, such as:

Processing newly submitted documents
Generating embeddings for newly created content
Updating a search index
Synchronizing data with another system
Running AI processing when new data arrives
Performing analytics or enrichment
Triggering downstream business workflows
Maintaining materialized or derived data

The change feed processor also handles important operational concerns such as checkpointing, load balancing, lease management, and recovery.

1. What Is the Azure Cosmos DB Change Feed?

The change feed is a persistent record of changes to items in an Azure Cosmos DB container.

Conceptually, it looks like this:

			
Application
    |
    | Creates/updates items
    v
Azure Cosmos DB Container
    |
    | Change feed
    v
Change Feed Processor
    |
    +--> Process new item
    +--> Generate embedding
    +--> Update search index
    +--> Call downstream service
    +--> Store derived data

		

Instead of repeatedly asking:

“Which items have changed since the last time I checked?”

the application can consume the change feed and process changes incrementally.

This makes the change feed especially useful for event-driven and near-real-time architectures.

2. Latest Version Change Feed Mode

For the AI-200 scenario involving detection of new or updated items, the default latest version change feed mode is particularly important.

In latest version mode:

Creates appear in the change feed.
Updates appear in the change feed.
Deletes do not appear.
If an item is changed multiple times before it is read, the feed provides the latest version rather than every intermediate version.

For example:

			
Item created
     |
     v
Status = "Pending"
     |
     v
Status = "Processing"
     |
     v
Status = "Completed"

		

If these changes occur before the consumer reads the feed, latest-version mode may expose the current version rather than every intermediate state.

Therefore, latest-version mode is appropriate when the application cares about the current state of changed items, rather than every individual mutation.

Important exam distinction

If an application must detect deletes or process every intermediate version, latest-version mode isn’t sufficient.

Azure Cosmos DB also supports all versions and deletes mode, which captures creates, updates, and deletes. That mode has additional requirements, including continuous backup, and is available for Azure Cosmos DB for NoSQL.

3. What Is a Change Feed Processor?

The change feed processor is a higher-level mechanism for consuming the Azure Cosmos DB change feed.

It uses a push model.

Rather than requiring your application to repeatedly pull batches and manage continuation state itself, the processor:

Reads changes from the monitored container.
Determines which changes need to be processed.
Delivers batches of changes to your application code.
Maintains processing state using a lease container.
Distributes work among multiple processor instances.
Recovers work when an instance fails.

The change feed processor is currently provided through the Azure Cosmos DB .NET V3 and Java V4 SDKs. Python and Node.js applications can consume the change feed using the pull model rather than the change feed processor library.

4. The Four Components of a Change Feed Processor

A key AI-200 concept is understanding the four major components.

4.1 Monitored Container

The monitored container is the Azure Cosmos DB container whose changes you want to process.

For example:

			
Database: AIApplication
Container: Documents
Partition key: /customerId

The processor monitors Documents.

When items are created or updated, those changes become available through the change feed.

4.2 Lease Container

The lease container stores the state used by the change feed processor to coordinate processing.

This is extremely important.

The lease container allows multiple processor instances to share the workload without processing the same lease simultaneously.

Conceptually:

                 Lease Container
                /       |       \
               /        |        \
              v         v         v
          Lease 1    Lease 2    Lease 3
             |          |          |
             v          v          v
          Worker A   Worker B   Worker C

The leases represent ownership and progress for portions of the change feed.

The lease container can be in the same Cosmos DB account as the monitored container or in a separate account.

Exam tip

If a question asks:

What component maintains the state of change feed processing?

The answer is generally:

The lease container.

5. Compute Instances

A compute instance hosts the change feed processor.

Examples include:

Azure Kubernetes Service pods
Azure App Service instances
Azure Virtual Machines
Long-running application processes
Hosted background services

For example:

			
AKS Cluster
Pod 1 --> Change Feed Processor
Pod 2 --> Change Feed Processor
Pod 3 --> Change Feed Processor

Each processor instance must have a unique instance name.

The processor distributes leases among the available instances.

6. The Delegate

The delegate is your application code that processes the changes.

For example, suppose an AI application stores documents in Cosmos DB.

When a document changes, the delegate might:

Extract the text.
Generate an embedding.
Store the embedding.
Update a vector index.
Record processing status.

Conceptually:

			
Cosmos DB Change
       |
       v
Change Feed Processor
       |
       v
Delegate
       |
       +--> Extract text
       |
       +--> Generate embedding
       |
       +--> Store embedding
       |
       +--> Update AI search data

		

The delegate is therefore where the application’s business logic lives.

7. How the Processing Lifecycle Works

The basic lifecycle is:

			
Read change feed
       |
       v
Are there changes?
   /          \
 No            Yes
 |              |
 v              v
Wait          Send batch
 |              |
 +------<-------+
                |
                v
        Delegate succeeds?
           /        \
         No          Yes
         |            |
         v            v
     Retry from    Update
     checkpoint    lease

		

More precisely, the processor:

Reads the change feed.
Waits if no changes are available.
Sends a batch of changes to the delegate.
Waits for successful processing.
Updates the lease with the latest successfully processed position.
Continues processing.

The checkpoint is therefore advanced after successful processing.

8. Why the Change Feed Processor Uses At-Least-Once Processing

One of the most important concepts for the exam is that the change feed processor provides an at-least-once delivery guarantee.

Suppose the processor reads:

			
Change A
Change B
Change C

and passes them to your delegate.

If the delegate fails before the checkpoint is successfully updated, the processor can process those changes again.

Therefore:

			
Change A
Change B
Change C
      |
      v
   Process
      |
      X Failure
      |
      v
Retry
      |
      v
Change A
Change B
Change C

		

This means your application should generally be idempotent.

9. Why Idempotency Matters

An idempotent operation can safely be executed more than once without producing an incorrect final result.

For example, suppose the change feed processor receives:

			
{
    "id": "document-123",
    "status": "completed"
}

Your processing logic might update a downstream record:

document-123 -> completed

If the same change is processed twice, the final state remains:

document-123 -> completed

That is preferable to an operation such as:

balance = balance + 100

where processing the same event twice could incorrectly add the amount twice.

Exam rule

Design change feed handlers assuming a change may be delivered more than once.

10. Lease-Based Load Distribution

The change feed processor can distribute processing across multiple instances.

For example:

			
Change Feed
------------------------------------------------
Partition Range 1
Partition Range 2
Partition Range 3
Partition Range 4
------------------------------------------------
        |          |          |          |
        v          v          v          v
     Worker 1   Worker 2   Worker 3   Worker 4

		

The lease container coordinates ownership of these workloads.

If one worker fails, its leases can eventually be acquired by another worker.

This provides fault tolerance without requiring the developer to manually coordinate workers.

11. Scaling the Change Feed Processor

Suppose you initially have:

Worker 1

and later add:

			
Worker 2
Worker 3

The change feed processor can redistribute leases among the workers.

Conceptually:

			
Before:
Worker 1
 ├── Lease 1
 ├── Lease 2
 ├── Lease 3
 └── Lease 4
After scaling:
Worker 1
 ├── Lease 1
 └── Lease 2
Worker 2
 └── Lease 3
Worker 3
 └── Lease 4

		

This allows processing to be parallelized.

However, simply adding instances does not mean that processing becomes infinitely parallel.

The available workload is constrained by the number of leases/partition ranges.

The number of processor instances should not exceed the number of available leases for meaningful distribution.

12. Partitioning and Change Feed Processing

Azure Cosmos DB containers are partitioned using a partition key.

For example:

			
Container: Documents
Partition key: /customerId

The change feed processor works with the underlying partition ranges.

Each range can be processed independently, allowing parallel processing.

This is one reason that selecting an appropriate partition key remains important even when using the change feed.

A poor partition key can create an uneven workload.

13. Starting Position

An important implementation detail is the processor’s starting position.

When a change feed processor is initialized for the first time, its starting point determines which changes it processes.

In latest-version mode, you can configure the processor to start from a specified time or from the beginning of the container’s lifetime.

For example:

			
Container history
|
|---- Change A
|---- Change B
|---- Change C
|---- Change D
|---- Change E
|
             ^
             |
       Start processor

		

If configured to begin at Change A, the processor can process the historical changes.

If configured to start from the current point, older changes aren’t processed.

Important

The starting-position configuration is used when initializing the processor. Once the lease container has established the processor’s state, changing the starting configuration doesn’t reset the existing checkpoint.

14. Change Feed Processor vs. Pull Model

There are two major approaches to consuming the change feed.

Feature	Change Feed Processor	Pull Model
Processing style	Push	Pull
Checkpoint management	Lease container	Application-managed continuation
Load balancing	Built in	Application responsibility
Error/retry infrastructure	Built in	Application responsibility
.NET support	Yes	Yes
Java support	Yes	Yes
Python	Not through processor library	Yes
Node.js	Not through processor library	Yes

The change feed processor is generally easier when you want Azure Cosmos DB to manage the mechanics of distributing work and maintaining processing state.

15. Change Feed Processor vs. Azure Functions Trigger

Another important distinction is between the change feed processor and the Azure Functions trigger for Cosmos DB.

Both can be used to build event-driven applications.

For example:

			
Cosmos DB
   |
   +----> Change Feed Processor
   |
   +----> Azure Functions Trigger

		

The change feed processor is useful when you need more direct control over a long-running processing application.

The Azure Functions trigger is useful when you want a serverless implementation.

The Azure Functions trigger also uses a lease container to maintain processing state.

16. Handling Processing Failures

Suppose your delegate encounters an exception:

			
Batch
  |
  v
Delegate
  |
  X Exception

		

The processor doesn’t simply assume the batch succeeded.

Because the checkpoint hasn’t advanced successfully, the processor can retry the batch.

This behavior produces the at-least-once guarantee.

Important design consideration

If a particular item consistently causes processing to fail, the processor can repeatedly encounter the same problem.

A robust application should therefore have an error-handling strategy.

For example:

			
Change
  |
  v
Process
  |
  X Failure
  |
  +--> Retry
  |
  +--> Persistent failure
          |
          v
     Error/DLQ storage

		

An application might persist information about the failed change to another Cosmos DB container or another durable store so that the processing pipeline doesn’t remain permanently blocked by one problematic change.

17. Monitoring Change Feed Lag

A change feed processor can fall behind the incoming changes.

For example:

			
New changes:
1000 events/sec
Processing:
700 events/sec
Result:
Change feed lag increases

		

The change feed estimator can be used to monitor processor progress and estimate lag.

This can help identify:

Insufficient processing capacity
Slow downstream services
Throttling
Application errors
Lease problems
Processing bottlenecks

18. Request Units and the Change Feed

Change feed processing isn’t free from a Cosmos DB throughput perspective.

Reading the change feed from the monitored container consumes request units (RUs).

Operations involving the lease container also consume RUs.

For example:

			
Monitored Container
       |
       +--> Change feed reads --> RU consumption
Lease Container
       |
       +--> Lease reads
       +--> Lease updates
       +--> Lease coordination
                    |
                    v
               RU consumption

		

If the monitored or lease container experiences throttling, change processing can be delayed.

This is especially important when deploying multiple processor instances or multiple processing workloads that share a lease container.

19. Lease Container Permissions

When Microsoft Entra ID authentication is used, the processor’s identity needs appropriate permissions.

The monitored container requires permissions related to:

Reading account metadata
Reading the change feed

The lease container requires permissions for operations such as:

Reading items
Creating items
Replacing items
Deleting items
Executing queries

This is an important distinction:

The application doesn’t just need permission to read the monitored data; it also needs permission to maintain the processor’s lease state.

20. Using a Global Endpoint

For a change feed processor workload, Microsoft recommends using the global Cosmos DB endpoint rather than a region-specific endpoint.

For example:

			
Preferred:
https://contoso.documents.azure.com

rather than:

https://contoso-westus.documents.azure.com

Regional preferences should be configured through the appropriate SDK region settings.

This is important because lease documents are scoped to the configured endpoint. Changing endpoints can result in separate lease state.

21. A Typical AI Application Architecture

Consider an AI document-processing application.

A user uploads a document, and the application stores metadata in Cosmos DB.

The desired workflow is:

			
User
 |
 v
Application
 |
 v
Cosmos DB
 |
 | New/updated document
 v
Change Feed
 |
 v
Change Feed Processor
 |
 v
Processing Delegate
 |
 +--> Extract document text
 |
 +--> Generate embedding
 |
 +--> Store vector
 |
 +--> Update search metadata
 |
 +--> Notify downstream application

		

This architecture avoids repeatedly scanning the entire container looking for new work.

It also allows the processing workload to scale independently from the application that writes the data.

22. Example .NET Concept

A simplified .NET implementation conceptually looks like this:

			
var processor = monitoredContainer
    .GetChangeFeedProcessorBuilder<MyDocument>(
        "documentProcessor",
        HandleChangesAsync)
    .WithInstanceName("worker-01")
    .WithLeaseContainer(leaseContainer)
    .Build();
await processor.StartAsync();

		

The important concepts are:

monitoredContainer — where changes originate.
leaseContainer — where processing state is maintained.
HandleChangesAsync — your business logic.
WithInstanceName — uniquely identifies the processor instance.
Processor startup — begins monitoring the change feed.

The exact SDK APIs can vary by SDK version, so the exam focus should be on understanding the architecture and responsibilities rather than memorizing every method signature. The current change feed processor documentation identifies .NET V3 and Java V4 as the SDKs that provide the processor library.

23. Important Exam Concepts to Remember

For AI-200, make sure you can distinguish the following:

Monitored container

Contains the data whose changes are being detected.

Lease container

Maintains processor state and coordinates work across instances.

Delegate

Contains the application’s processing logic.

Compute instance

Hosts the change feed processor.

Latest-version mode

Captures the latest versions of creates and updates; deletes aren’t included.

All versions and deletes mode

Captures creates, updates, and deletes, including intermediate changes.

Checkpoint

Records the latest successfully processed position.

At-least-once delivery

A change can be processed more than once, so handlers should be idempotent.

Pull model

The application manages reading, continuation state, and processing coordination.

Change feed processor

Provides a higher-level push-based processing model with lease-based coordination.

Practice Exam Questions

Question 1

An AI application stores documents in an Azure Cosmos DB for NoSQL container. Whenever a document is created or updated, the application must perform additional processing. The development team wants Azure Cosmos DB to manage checkpointing and distribute processing across multiple application instances.

Which solution should the team implement?

A. A timer-triggered Azure Function that scans the container

B. Periodic SQL queries

C. Azure Cosmos DB analytical store queries

D. Change feed processor

Answer: D

Explanation

The change feed processor is designed to process changes incrementally and provides built-in lease-based coordination and checkpoint management. It can distribute change feed processing across multiple instances.

The other approaches require the application to identify changes itself and are less appropriate for event-driven incremental processing.

Question 2

A change feed processor processes a batch of changes successfully but fails before the processing state is checkpointed. What should the application expect?

A. The changes are permanently discarded

B. The batch can be delivered again

C. The entire Cosmos DB container is automatically restored

D. The change feed is permanently disabled

Answer: B

Explanation

The change feed processor provides at-least-once delivery. If processing succeeds but the checkpoint isn’t successfully advanced, the processor can process the same changes again.

Application processing logic should therefore be designed to be idempotent.

Question 3

Which component is primarily responsible for maintaining the state and coordinating ownership of change feed processing across multiple processor instances?

A. Monitored container

B. Compute instance

C. Lease container

D. Application Gateway

Answer: C

Explanation

The lease container stores the state used by the change feed processor to coordinate processing across instances.

The monitored container provides the source data, while compute instances host the processing application.

Question 4

An application uses the default latest-version change feed mode. An item is created and then updated three times before the processor reads the changes. What behavior should the application expect?

A. Only the delete operation is returned

B. All four versions are guaranteed to be returned

C. No changes are returned because the item changed multiple times

D. The latest version of the item is available rather than every intermediate version

Answer: D

Explanation

Latest-version mode provides the latest version of an item in the feed rather than preserving every intermediate change between reads.

If the application needs every create, update, and delete operation, it should consider all versions and deletes mode instead.

Question 5

A developer is building a change feed processor application that will run on three AKS pods. What is the primary purpose of assigning each processor instance a unique instance name?

A. To identify each compute instance participating in lease distribution

B. To specify the Cosmos DB partition key

C. To determine the consistency level

D. To select the Cosmos DB database

Answer: A

Explanation

Each change feed processor instance should have a unique instance name. The processor uses the instances and leases to distribute processing work across the deployment.

The instance name is unrelated to partition-key selection, database selection, or consistency configuration.

Question 6

An AI application must react when documents are deleted from an Azure Cosmos DB for NoSQL container. Which change feed capability is most appropriate?

A. Latest-version change feed mode

B. All versions and deletes change feed mode

C. Increasing the consistency level

D. Increasing the container’s RU/s

Answer: B

Explanation

All versions and deletes mode captures creates, updates, and deletes.

Latest-version mode does not capture deletes.

All versions and deletes mode has additional requirements, including continuous backup, and is specifically available for Azure Cosmos DB for NoSQL.

Question 7

A change feed processor application experiences increasingly large processing delays. Investigation shows that the application is processing changes correctly but cannot keep up with incoming changes.

Which metric or capability is most useful for determining whether the processor is falling behind?

A. Azure DNS query count

B. Azure Storage blob count

C. Change feed estimator

D. Azure Resource Manager activity log

Answer: C

Explanation

The change feed estimator can be used to estimate the lag between the changes available in the monitored container and the progress of the change feed processor.

This can help identify processing bottlenecks and determine whether additional processing capacity may be necessary.

Question 8

A change feed processor’s delegate updates an external database. The same change may occasionally be delivered more than once. What should the developer do?

A. Disable checkpointing

B. Use an idempotent processing design

C. Increase the Cosmos DB consistency level to strong

D. Disable leases

Answer: B

Explanation

The change feed processor provides at-least-once delivery, meaning a change can be processed more than once.

The delegate should therefore be designed to handle duplicate processing safely. Idempotent operations are one of the most important techniques for doing this.

Question 9

A company runs several change feed processor instances and notices that the lease container is experiencing RU throttling. What is a likely consequence?

A. Change feed processing can be delayed

B. All documents in the monitored container are deleted

C. The Cosmos DB account automatically switches to strong consistency

D. The application automatically receives unlimited RU/s

Answer: A

Explanation

The lease container performs operations that consume request units. If the lease container is throttled, lease coordination and renewal can be delayed, which can delay change feed processing.

The monitored container’s change feed reads also consume RUs. Both the monitored and lease containers should therefore be appropriately provisioned.

Question 10

A development team wants to consume an Azure Cosmos DB change feed from a Python application. They want to use the built-in change feed processor library that automatically handles lease-based processing.

What should the team do?

A. Use the .NET change feed processor library from Python

B. Use the Java change feed processor library from Python

C. Use the change feed pull model from Python

D. Use Azure SQL Database instead

Answer: C

Explanation

The Azure Cosmos DB change feed processor library is available for .NET and Java. Python applications can consume the change feed using the pull model, where the application manages continuation state and processing.

Key Takeaways

For the AI-200 exam, the most important ideas are:

The change feed records changes to Azure Cosmos DB items.
The change feed processor provides a push-based processing model.
The monitored container is the source of changes.
The lease container stores processing state and coordinates workers.
The delegate contains the application’s change-processing logic.
Multiple processor instances can share the workload through leases.
Change feed processing provides at-least-once delivery.
Handlers should therefore be idempotent.
Latest-version mode captures creates and updates but not deletes.
All versions and deletes mode captures creates, updates, and deletes.
The change feed processor library is available for .NET and Java; Python and Node.js use the pull model.
Change feed processing consumes RUs.
Throttling of the monitored or lease container can delay processing.
The change feed estimator can help identify processing lag.
The lease container is fundamental to distributed, fault-tolerant change feed processing.

The exam’s scenario questions are likely to test whether you can select the right change feed mode, processing model, lease architecture, error-handling strategy, and scaling approach, rather than simply recognizing the term “change feed.”

Go to the AI-200 Exam Prep Hub main page

azure, Databases, DP-800, Microsoft Certification, SQL August 1, 2026August 1, 2026

Handle changes by using change event streaming (CES), change data capture (CDC), Change Tracking, Azure Functions with SQL trigger binding, or Azure Logic Apps (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Integrate SQL solutions with Azure services
      --> Handle changes by using change event streaming (CES), change data capture (CDC), Change Tracking, Azure Functions with SQL trigger binding, or Azure Logic 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.

Introduction

Modern applications rarely operate in isolation. A single database update often needs to trigger downstream actions such as updating search indexes, synchronizing data warehouses, refreshing caches, sending notifications, invoking APIs, or triggering AI pipelines.

Microsoft SQL Server and Azure SQL provide several mechanisms to detect and react to data changes. The DP-800 exam expects candidates to understand the capabilities, strengths, limitations, and appropriate use cases for each technology.

The primary technologies include:

Change Data Capture (CDC)
Change Tracking
Change Event Streaming (CES)
Azure Functions with SQL Trigger Binding
Azure Logic Apps

Understanding when and why to use each technology is more important than memorizing implementation details.

Why Change Detection Matters

Applications often need to know when data changes occur without continuously querying every table.

Examples include:

Synchronizing CRM and ERP systems
Triggering AI workflows after new customer data arrives
Updating recommendation engines
Refreshing search indexes
Sending order confirmation emails
Replicating data into Microsoft Fabric
Populating analytical data lakes
Updating Power BI semantic models

Without an efficient change detection mechanism, applications would have to repeatedly scan entire tables, resulting in:

Poor performance
Increased costs
Higher latency
Unnecessary resource utilization

Overview of Available Technologies

Technology	Detects Inserts	Updates	Deletes	Provides Changed Values	Typical Use
Change Tracking	Yes	Yes	Yes	No	Lightweight synchronization
Change Data Capture	Yes	Yes	Yes	Yes	ETL and replication
Change Event Streaming	Yes	Yes	Yes	Event stream	Event-driven architectures
Azure Functions SQL Trigger	Yes	Yes	Yes	Current row	Serverless processing
Azure Logic Apps	Yes	Yes	Yes	Depends on connector	Workflow automation

Change Data Capture (CDC)

What is CDC?

Change Data Capture records every data modification that occurs within selected database tables.

Unlike Change Tracking, CDC stores:

The type of operation
Before and after values (where applicable)
Transaction information
Log Sequence Numbers (LSNs)
Timestamps

CDC reads changes directly from the SQL Server transaction log instead of requiring application modifications.

How CDC Works

User modifies data.
SQL writes changes to the transaction log.
CDC captures the changes.
Changes are written into CDC system tables.
Applications or ETL tools read the captured changes.

			
Application
      │
      ▼
SQL Table
      │
Transaction Log
      │
      ▼
CDC Capture Process
      │
      ▼
CDC Change Tables
      │
      ▼
ETL / Azure Data Factory / Fabric

		

Information Stored by CDC

For every change, CDC stores:

Insert
Update
Delete
Transaction sequence
Changed columns
Original values
New values
Commit time
Log sequence number

This provides a complete history of modifications.

Advantages of CDC

Minimal application changes

Applications continue performing normal INSERT, UPDATE, and DELETE operations.

Incremental processing

Instead of processing millions of rows:

			
Yesterday:
10 million rows
Today:
Only 1,250 rows changed
CDC processes only 1,250 rows.

		

This dramatically improves ETL performance.

Supports Historical Analysis

CDC retains detailed change history.

Example:

Customer Name

Original:

John Smith

Updated:

John A. Smith

CDC preserves both versions.

Common CDC Use Cases

Azure Data Factory incremental loads
Microsoft Fabric ingestion
Data warehouse updates
Database replication
AI training pipelines
Audit solutions
Event publishing
Synchronizing microservices

Limitations

CDC:

Uses additional storage
Requires SQL Agent jobs (SQL Server)
Introduces some overhead
Retention must be managed
Generates additional transaction log activity

Change Tracking

What is Change Tracking?

Change Tracking is a lightweight feature that records which rows have changed, but does not store the actual changed values.

Instead, it stores metadata indicating:

Row changed
Row deleted
Version number

Applications retrieve the latest row directly from the table.

How Change Tracking Works

Instead of saving old values:

CustomerID 101 changed.

The application retrieves:

			
SELECT *
FROM Customers
WHERE CustomerID = 101

Only the current version is available.

Advantages

Very lightweight.

Minimal storage.

Minimal performance impact.

Simple synchronization.

Fast processing.

Limitations

Cannot determine:

Old value

↓

New value

Only knows:

Row changed

No historical audit.

No before-and-after comparison.

Best Use Cases

Mobile synchronization

Offline applications

Client synchronization

Web applications

Caching

Incremental refresh

Applications only needing current data

CDC vs Change Tracking

Feature	CDC	Change Tracking
Detect Inserts	Yes	Yes
Detect Updates	Yes	Yes
Detect Deletes	Yes	Yes
Stores Old Values	Yes	No
Stores New Values	Yes	No
Historical Data	Yes	No
Storage Usage	Higher	Lower
ETL Friendly	Excellent	Limited
Synchronization	Good	Excellent
Auditing	Excellent	Poor

Choosing Between CDC and Change Tracking

Choose CDC when:

Building ETL pipelines
Loading data warehouses
Creating audit systems
Tracking complete history
AI model retraining
Replication

Choose Change Tracking when:

Synchronizing mobile devices
Synchronizing applications
Detecting row changes only
Performance is critical
History is unnecessary

Change Event Streaming (CES)

What is Change Event Streaming?

Change Event Streaming is an event-driven approach that publishes database changes as events immediately after they occur.

Instead of applications polling for changes:

			
Did anything change?
Did anything change?
Did anything change?

The database immediately emits an event.

Event-Driven Architecture

			
INSERT Order
      │
      ▼
Database
      │
      ▼
Event Published
      │
 ┌────┼────┐
 ▼    ▼    ▼
Function
Logic App
Service Bus

		

One database change can notify many downstream services simultaneously.

Advantages

Near real-time processing

Low latency

Highly scalable

Excellent for cloud-native applications

Supports asynchronous processing

Works well with event hubs and messaging systems

Common Scenarios

Order processing

Inventory updates

Recommendation engines

AI pipelines

Search indexing

Notifications

Microservices

IoT

Streaming analytics

Benefits over Polling

Polling example:

Check database every minute

Potential issues:

Delayed processing
Unnecessary database queries
Higher compute costs

Event streaming:

			
Change occurs
↓
Immediate notification

Much more efficient.

Azure Functions with SQL Trigger Binding

Overview

Azure Functions provide a serverless compute platform capable of automatically executing code when database changes occur.

SQL Trigger Binding enables Azure Functions to react to SQL data modifications without requiring custom polling logic.

Typical workflow:

			
Database Change
↓
SQL Trigger
↓
Azure Function
↓
Business Logic

		

Common Scenarios

Automatically:

Send emails
Generate invoices
Update search indexes
Invoke AI models
Call REST APIs
Update Cosmos DB
Write to Azure Storage
Publish Service Bus messages

Benefits

Serverless

Automatic scaling

Pay only for executions

Minimal infrastructure management

Easy integration with Azure services

Supports event-driven architectures

Example Scenario

A customer places an order.

INSERT Orders

The SQL trigger starts an Azure Function.

The function:

Validates inventory
Sends confirmation email
Updates recommendation engine
Notifies shipping
Publishes event

No manual polling required.

Azure Logic Apps

What Are Logic Apps?

Azure Logic Apps are low-code workflow automation services that integrate SQL databases with hundreds of Microsoft and third-party services.

Rather than writing custom code, workflows are built visually.

Example:

			
SQL Row Updated
↓
Logic App
↓
Teams Notification
↓
Outlook Email
↓
SharePoint Update
↓
CRM Update

		

Common SQL Integrations

SQL Server

Azure SQL Database

Microsoft Dataverse

Dynamics 365

Salesforce

Microsoft Teams

SharePoint

Azure Storage

Azure Service Bus

Azure Event Grid

Power Automate

Typical Workflow

			
Customer Created
↓
Logic App
↓
Create CRM Record
↓
Send Welcome Email
↓
Create Help Desk Ticket
↓
Notify Sales Team

		

Advantages

Low-code

Rapid development

Hundreds of connectors

Visual designer

Built-in retry policies

Error handling

Scheduling

Monitoring

Enterprise integration

Limitations

Logic Apps are ideal for orchestration and workflow automation but are not intended for high-throughput transactional processing where custom code or event streaming solutions may provide better scalability and lower latency.

Choosing the Right Technology

Requirement	Recommended Solution
Incremental ETL	CDC
Data Warehouse Loading	CDC
Audit History	CDC
Mobile Sync	Change Tracking
Cache Refresh	Change Tracking
Event-Driven Processing	Change Event Streaming
Serverless Business Logic	Azure Functions SQL Trigger
Workflow Automation	Azure Logic Apps
AI Pipeline Trigger	Azure Functions or CES
Multi-System Integration	Logic Apps

Best Practices

Enable Only What You Need

Enable CDC or Change Tracking only on tables that require change detection.

Monitor Storage

CDC tables can grow quickly.

Implement retention policies and cleanup jobs.

Prefer Event-Driven Architectures

Avoid continuous polling whenever possible.

Use:

CES
Azure Functions
Event Grid
Service Bus

for scalable cloud-native applications.

Separate Operational and Analytical Workloads

Use CDC to move transactional data into analytical platforms instead of querying production systems directly.

Secure Integration Endpoints

Protect Azure Functions and Logic Apps using:

Microsoft Entra ID
Managed identities
Azure Key Vault
Least privilege access
Network restrictions where appropriate

Monitor Reliability

Track:

Failed executions
Retry attempts
Dead-letter queues
Function failures
Logic App run history
Event delivery failures

DP-800 Exam Tips

Remember these common exam distinctions:

CDC records complete data changes, including inserted, updated, and deleted values, making it ideal for ETL, auditing, and replication.
Change Tracking records only that a row changed, making it a lightweight solution for synchronization scenarios.
Change Event Streaming supports near real-time, event-driven architectures by publishing change events to downstream consumers.
Azure Functions with SQL Trigger Binding are best when database changes should execute custom serverless code automatically.
Azure Logic Apps are the preferred choice for orchestrating business workflows and integrating SQL databases with Azure and third-party services through low-code connectors.
When selecting a technology, evaluate latency requirements, scalability, historical tracking needs, operational overhead, and integration requirements rather than choosing a single solution for every scenario.

Summary

Modern SQL applications extend well beyond traditional databases, serving as event sources for cloud-native architectures, AI pipelines, analytics platforms, and business workflows. Microsoft provides several complementary technologies to detect and process database changes, each optimized for different scenarios.

For the DP-800 exam, you should understand not only how these technologies work, but also when to choose one over another. CDC excels at incremental ETL and auditing, Change Tracking offers lightweight synchronization, Change Event Streaming enables real-time event-driven systems, Azure Functions execute custom business logic in response to changes, and Azure Logic Apps simplify workflow automation across enterprise services.

A solid understanding of these tools will help you design scalable, maintainable, and performant AI-enabled database solutions in Azure.

Practice Exam Questions

Question 1

A company loads data from an Azure SQL Database into a Microsoft Fabric warehouse every hour. The ETL process should retrieve only rows that have changed since the previous load, including the previous and new values of updated rows.

Which technology should you recommend?

A. Change Tracking

B. Change Data Capture (CDC)

C. Azure Logic Apps

D. Azure Functions with SQL Trigger Binding

Correct Answer: B

Explanation

CDC is specifically designed for incremental data movement scenarios. It captures inserts, updates, and deletes directly from the transaction log and stores detailed information about each change, including before and after values where applicable.

Why the other options are incorrect:

A: Change Tracking identifies changed rows but does not store previous values.
C: Logic Apps orchestrate workflows but do not capture database changes.
D: Azure Functions respond to events but are not intended to maintain historical change data for ETL.

Question 2

A mobile application periodically synchronizes customer records with an Azure SQL Database. The application only needs to know which rows have changed since the last synchronization and does not require historical values.

Which feature is most appropriate?

A. Change Event Streaming

B. Azure Functions SQL Trigger

C. Change Tracking

D. CDC

Correct Answer: C

Explanation

Change Tracking is optimized for synchronization scenarios. It records that rows have changed while minimizing storage and processing overhead.

Why the other options are incorrect:

A: CES is designed for event-driven architectures.
B: Azure Functions execute custom code rather than maintaining synchronization metadata.
D: CDC stores detailed change history, which is unnecessary here.

Question 3

An online retailer wants every new order inserted into the Orders table to immediately trigger inventory updates, shipping notifications, and fraud detection.

Which solution best supports this requirement?

A. Scheduled polling queries

B. Change Tracking

C. Change Event Streaming (CES)

D. Nightly ETL jobs

Correct Answer: C

Explanation

CES enables near real-time event publishing whenever database changes occur. Multiple downstream systems can subscribe to the same event without repeatedly querying the database.

Why the other options are incorrect:

A: Polling introduces unnecessary latency and database load.
B: Change Tracking is intended for synchronization rather than event processing.
D: Nightly ETL introduces unacceptable delays.

Question 4

A database update should automatically execute custom C# code that calls several REST APIs and writes audit information to Azure Storage.

Which Azure service should you recommend?

A. Azure Functions with SQL Trigger Binding

B. CDC

C. Change Tracking

D. SQL Agent Job

Correct Answer: A

Explanation

Azure Functions with SQL Trigger Binding automatically execute custom code when qualifying database changes occur, making them ideal for serverless business logic.

Why the other options are incorrect:

B: CDC records changes but does not execute code.
C: Change Tracking simply records row modifications.
D: SQL Agent jobs rely on scheduled execution rather than event-driven processing.

Question 5

Which statement correctly compares Change Tracking and Change Data Capture?

A. CDC captures complete change history while Change Tracking records only that rows changed.

B. Change Tracking captures previous values while CDC does not.

C. Both features store identical information.

D. CDC only tracks INSERT operations.

Correct Answer: A

Explanation

CDC stores detailed information about every change, including inserts, updates, deletes, timestamps, and transaction metadata. Change Tracking only identifies which rows have changed.

The remaining options are incorrect because they reverse the capabilities or incorrectly describe CDC.

Question 6

A business analyst wants to automate the following workflow without writing custom code:

Detect a new customer record.
Send an Outlook email.
Post a Microsoft Teams notification.
Update a SharePoint list.

Which solution is the best choice?

A. CDC

B. Azure Logic Apps

C. Change Tracking

D. SQL CLR

Correct Answer: B

Explanation

Azure Logic Apps provide low-code workflow automation with hundreds of built-in connectors, making them ideal for orchestrating business processes across Microsoft services.

Why the other options are incorrect:

A: CDC captures changes but does not automate workflows.
C: Change Tracking only records modified rows.
D: SQL CLR requires custom coding and is not intended for cloud workflow automation.

Question 7

A development team currently polls the database every minute to determine whether new records have been inserted.

What is the primary disadvantage of this design?

A. It reduces database normalization.

B. It prevents indexing.

C. It increases transaction isolation.

D. It generates unnecessary database workload and introduces latency.

Correct Answer: D

Explanation

Polling repeatedly queries the database even when no changes exist, increasing resource consumption while delaying event processing.

Event-driven solutions such as CES or Azure Functions eliminate this inefficiency.

Question 8

Which technology is most appropriate when an organization must maintain a complete historical record of all row changes for regulatory auditing?

A. Azure Logic Apps

B. Change Tracking

C. Change Data Capture

D. Azure Functions

Correct Answer: C

Explanation

CDC preserves detailed information about inserts, updates, deletes, transaction sequence numbers, and timestamps, making it ideal for compliance and auditing.

The other technologies either automate workflows or identify changes without preserving historical values.

Question 9

Which feature is specifically intended to minimize synchronization overhead by storing only metadata about changed rows?

A. Azure Functions SQL Trigger

B. Change Tracking

C. Change Event Streaming

D. Azure Event Grid

Correct Answer: B

Explanation

Change Tracking records lightweight metadata that indicates which rows have changed, allowing applications to retrieve only the latest row versions.

The other options serve different purposes:

Azure Functions execute code.
CES publishes events.
Event Grid distributes events but does not track database modifications.

Question 10

A solution architect is selecting a technology for an event-driven microservices architecture. Multiple independent services must react immediately whenever product inventory changes.

Which solution best satisfies this requirement?

A. Nightly ETL processing

B. Change Tracking

C. Database polling every five minutes

D. Change Event Streaming (CES)

Correct Answer: D

Explanation

CES is designed for event-driven systems where multiple subscribers consume database change events in near real time. It minimizes latency and reduces unnecessary database queries.

Why the other options are incorrect:

A: Nightly processing is far too slow.
B: Change Tracking is intended for synchronization rather than event broadcasting.
C: Polling introduces unnecessary workload and delays.

Exam Tips

For the DP-800 exam, remember these key distinctions:

Change Data Capture (CDC) is best for incremental ETL, auditing, replication, and historical change tracking.
Change Tracking is designed for lightweight synchronization when only the fact that a row changed is needed.
Change Event Streaming (CES) enables near real-time event-driven architectures by publishing database changes to downstream consumers.
Azure Functions with SQL Trigger Binding are ideal for executing custom serverless code in response to database changes.
Azure Logic Apps provide low-code workflow automation for integrating Azure SQL with Microsoft and third-party services.
On the exam, Microsoft often presents multiple technologies that could work. Choose the one that best aligns with the business requirement, considering factors such as latency, historical tracking, automation, scalability, and operational overhead, rather than selecting the most feature-rich option.

Go to the DP-800 Exam Prep Hub main page

azure, Databases, DP-800, Microsoft Certification, SQL August 1, 2026August 1, 2026

Recommend Azure Monitor configurations, including Application Insights and Log Analytics (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Integrate SQL solutions with Azure services
      --> Recommend Azure Monitor configurations, including Application Insights and Log Analytics

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.

Introduction

Modern SQL applications extend far beyond storing and retrieving data. Today’s applications often expose APIs, integrate with AI services, support microservices, and serve users around the world. As systems become more distributed, monitoring application health, database performance, security, and user activity becomes increasingly important.

Azure Monitor is Microsoft’s unified monitoring platform for collecting, analyzing, visualizing, and acting upon telemetry from Azure resources, applications, virtual machines, containers, databases, and on-premises environments. For SQL AI developers preparing for the DP-800 certification, understanding Azure Monitor—and specifically Application Insights and Log Analytics—is essential for designing highly observable, reliable, and performant database solutions.

The DP-800 exam expects candidates to know when and how to recommend monitoring configurations that support troubleshooting, performance optimization, security monitoring, operational excellence, and AI-enabled database applications.

Understanding Azure Monitor

Azure Monitor is a comprehensive monitoring service that provides:

Metrics collection
Log collection
Distributed tracing
Alerting
Dashboards
Workbooks
Performance analytics
Diagnostic settings
Resource health monitoring

Azure Monitor collects telemetry from virtually every Azure service, including:

Azure SQL Database
Azure SQL Managed Instance
SQL Server on Azure VM
Azure App Service
Azure Functions
Azure Kubernetes Service (AKS)
Azure Container Apps
Data API Builder (DAB)
Azure OpenAI
Azure AI Search
Microsoft Fabric
Virtual Machines

Azure Monitor Architecture

A simplified monitoring architecture looks like this:

			
Applications
       │
Databases
       │
Azure Services
       │
Diagnostic Settings
       │
Azure Monitor
       │
 ┌───────────────┐
 │ Metrics       │
 │ Logs          │
 │ Traces        │
 │ Alerts        │
 └───────────────┘
       │
Application Insights
       │
Log Analytics
       │
Dashboards / Alerts / Workbooks

		

Core Azure Monitor Components

Azure Monitor consists of several integrated services.

Metrics

Metrics are numerical measurements collected at regular intervals.

Examples include:

CPU utilization
Memory usage
DTU utilization
vCore utilization
Storage usage
Active sessions
Requests per second
Response times

Metrics are lightweight and optimized for near real-time monitoring.

Logs

Logs contain detailed event information.

Examples:

SQL errors
Login attempts
Application exceptions
API requests
Deadlocks
Security events
Query execution details

Logs support historical analysis and forensic investigations.

Alerts

Azure Monitor alerts notify administrators when predefined conditions occur.

Examples include:

CPU > 80%
Database unavailable
Deadlock detected
Slow API response
Failed deployments
Authentication failures

Alerts can trigger:

Email
SMS
Azure Functions
Logic Apps
Webhooks
ITSM integrations

Dashboards

Dashboards combine metrics and logs into a centralized monitoring view.

Typical dashboard elements include:

Database performance
API latency
Error rates
Availability
Query duration
Resource utilization

What Is Application Insights?

Application Insights is an Azure Monitor feature designed to monitor applications.

It automatically collects telemetry such as:

HTTP requests
Dependencies
SQL calls
Exceptions
Page views
Response times
Availability tests
Distributed traces

Application Insights helps developers understand application behavior rather than infrastructure performance alone.

Telemetry Collected by Application Insights

Application Insights automatically captures:

Requests

Every REST or GraphQL request can be monitored.

Information includes:

URL
Duration
Response code
Success or failure
Timestamp

Dependencies

Dependencies include calls made by applications to external resources.

Examples:

Azure SQL Database
Azure OpenAI
Azure AI Search
Storage Accounts
REST APIs
Service Bus
Cosmos DB

Dependency tracking identifies slow downstream services.

Exceptions

Application Insights records:

SQL exceptions
.NET exceptions
Java exceptions
Node.js exceptions
Python exceptions

Developers can investigate stack traces and failure frequency.

Performance Counters

Examples include:

CPU
Memory
Thread count
Request queue
Process utilization

Availability Tests

Availability tests periodically verify that applications remain accessible.

Types include:

URL ping tests
Multi-step web tests (legacy)
Standard availability tests

Useful for:

REST APIs
Data API Builder endpoints
Web applications

Distributed Tracing

Modern applications often involve:

Application

↓

REST API

↓

Data API Builder

↓

Azure SQL Database

↓

Azure OpenAI

↓

Azure AI Search

Application Insights correlates all these operations into a single transaction, allowing developers to trace requests end-to-end.

Benefits include:

Root cause analysis
Performance bottleneck identification
Dependency tracking
Service latency analysis

What Is Log Analytics?

Log Analytics is Azure Monitor’s centralized log repository and query engine.

Logs from multiple Azure resources are stored in a Log Analytics Workspace.

Examples include:

SQL diagnostics
Application Insights logs
Azure Activity Logs
VM logs
Azure Firewall logs
Microsoft Defender logs

Log Analytics Workspaces

A Log Analytics Workspace stores telemetry collected across Azure.

Benefits include:

Centralized logging
Long-term retention
Cross-resource analysis
Kusto Query Language (KQL) support
Security investigations

Multiple Azure resources can send data to a single workspace.

Kusto Query Language (KQL)

Log Analytics uses KQL for querying data.

Example:

			
requests
| where success == false
| order by timestamp desc

Example:

			
dependencies
| summarize avg(duration) by target

Example:

			
exceptions
| summarize count() by type

The DP-800 exam expects familiarity with Log Analytics and awareness that KQL is the query language used to analyze collected telemetry.

Diagnostic Settings

Azure resources send telemetry through Diagnostic Settings.

Diagnostic Settings determine where logs are stored.

Possible destinations include:

Log Analytics Workspace
Storage Account
Event Hub
Partner solutions

For Azure SQL Database, diagnostic logs commonly include:

SQLInsights
Automatic tuning
Deadlocks
Query Store Runtime Statistics
Errors
Wait statistics
Timeouts

Monitoring Azure SQL Database

Important Azure SQL metrics include:

CPU percentage
DTU percentage
vCore utilization
Data IO
Log IO
Storage percentage
Sessions
Workers
Connections

These metrics help identify capacity issues before users experience failures.

Monitoring Data API Builder (DAB)

DAB deployments should enable:

Request logging
Response times
Authentication failures
GraphQL execution errors
REST endpoint usage
SQL dependency tracking

Application Insights provides excellent visibility into DAB performance.

Monitoring AI-Enabled SQL Applications

Applications integrating Azure OpenAI or Azure AI Search should monitor:

API latency
Request failures
Token usage (where available)
Dependency duration
Timeout frequency
Retry attempts

Dependency tracking in Application Insights helps identify whether delays originate from the database or external AI services.

Azure Monitor Alerts

Common production alerts include:

Condition	Alert
CPU > 80%	Warning
DTU > 90%	Critical
Deadlock detected	Critical
Failed SQL login	Security
API response > 2 seconds	Warning
Storage > 85%	Capacity alert
Application unavailable	Critical

Alerts should prioritize actionable events while minimizing alert fatigue.

Workbooks

Azure Monitor Workbooks create interactive reports using:

Metrics
Logs
Charts
Maps
Tables
KQL queries

Typical workbook examples:

SQL performance dashboard
API performance trends
AI service latency
Database growth analysis
Security monitoring

Retention Policies

Organizations should configure log retention based on:

Compliance requirements
Storage costs
Investigation needs
Security policies

Short retention reduces storage costs, while longer retention supports audits and forensic analysis.

Best Practices for Monitoring SQL Solutions

Microsoft recommends:

Enable Application Insights for applications.
Send diagnostic logs to Log Analytics.
Enable distributed tracing.
Configure proactive alerts.
Monitor dependencies.
Use dashboards for operational visibility.
Review telemetry regularly.
Monitor failed authentication attempts.
Monitor slow SQL queries.
Use KQL for troubleshooting.

Common DP-800 Exam Scenarios

You may be asked to determine:

Which monitoring service collects application telemetry.
When to use Application Insights versus Log Analytics.
How to troubleshoot slow SQL queries.
Which service stores centralized logs.
How to monitor Data API Builder.
Which service provides distributed tracing.
How to configure alerts for production systems.
Which Azure Monitor feature supports long-term log analysis.

DP-800 Exam Tips

Remember these key points:

Azure Monitor is the overarching monitoring platform.
Application Insights monitors application performance and dependencies.
Log Analytics centralizes logs and supports KQL queries.
Diagnostic Settings send Azure resource logs to destinations such as Log Analytics.
Application Insights supports distributed tracing.
Azure Monitor Alerts automate operational notifications.
Workbooks provide customizable dashboards and reports.
Azure SQL Database metrics help identify capacity and performance issues.
Use Application Insights to monitor Data API Builder and AI-enabled applications.
KQL is the primary language for querying Log Analytics data.

Practice Exam Questions

Question 1

A company wants to monitor the performance of a .NET application that accesses Azure SQL Database through Data API Builder. The solution must automatically capture request latency, SQL dependencies, exceptions, and distributed traces.

Which Azure service should you recommend?

A. Azure Storage Explorer

B. Azure Monitor Metrics

C. Application Insights

D. Azure Advisor

Answer: C

Explanation: Application Insights is designed to monitor application performance by collecting requests, dependencies, exceptions, distributed traces, and performance telemetry automatically.

Question 2

Your organization needs a centralized repository for logs collected from Azure SQL Database, Azure App Service, Azure Functions, and Application Insights.

Which Azure service should you use?

A. Azure Log Analytics Workspace

B. Azure Backup

C. Azure Key Vault

D. Azure Files

Answer: A

Explanation: A Log Analytics Workspace provides centralized storage and analysis for telemetry collected from multiple Azure resources.

Question 3

An administrator wants to query failed HTTP requests over the past 24 hours using Kusto Query Language (KQL).

Which Azure service provides this capability?

A. Azure Portal Metrics Explorer

B. Azure Cost Management

C. Azure Monitor Alerts

D. Log Analytics

Answer: D

Explanation: Log Analytics stores log data and enables querying through Kusto Query Language (KQL) for detailed analysis and troubleshooting.

Question 4

A development team wants to receive an email whenever Azure SQL Database CPU utilization exceeds 85% for more than five minutes.

Which Azure Monitor feature should be configured?

A. Diagnostic Settings

B. Azure Policy

C. Azure Monitor Alerts

D. Application Insights Availability Tests

Answer: C

Explanation: Azure Monitor Alerts evaluate metric or log conditions and can notify administrators through email, SMS, webhooks, or automated workflows.

Question 5

Which Azure Monitor feature is responsible for routing Azure SQL Database diagnostic logs to a Log Analytics Workspace?

A. Azure Monitor Metrics

B. Diagnostic Settings

C. Availability Tests

D. Resource Locks

Answer: B

Explanation: Diagnostic Settings configure where Azure resource logs are sent, including Log Analytics Workspaces, Storage Accounts, and Event Hubs.

Question 6

A developer needs to identify which downstream dependency is causing increased response times in an AI-enabled application.

Which Application Insights capability should they use?

A. Backup Reports

B. Dependency Tracking

C. Cost Analysis

D. Resource Graph

Answer: B

Explanation: Dependency Tracking records calls to Azure SQL Database, Azure OpenAI, Azure AI Search, REST APIs, and other services, making it easier to identify performance bottlenecks.

Question 7

Your organization wants to monitor whether a public REST endpoint remains accessible from multiple geographic regions.

Which Application Insights feature is most appropriate?

A. Live Metrics

B. Snapshot Debugger

C. Availability Tests

D. Smart Detection

Answer: C

Explanation: Availability Tests periodically check endpoint accessibility and response times from multiple locations, helping detect outages before users report them.

Question 8

Which Azure Monitor capability provides end-to-end visibility by correlating requests across multiple services such as Data API Builder, Azure SQL Database, and Azure OpenAI?

A. Azure Advisor

B. Distributed Tracing

C. Cost Management

D. Azure Policy

Answer: B

Explanation: Distributed Tracing correlates operations across application components, enabling developers to follow a single request through multiple services and identify performance bottlenecks.

Question 9

A database administrator wants to build an interactive dashboard that combines charts, tables, KQL queries, and performance metrics into a single operational view.

Which Azure Monitor feature should be recommended?

A. Azure Workbooks

B. Azure Bastion

C. Microsoft Purview

D. Azure Resource Graph

Answer: A

Explanation: Azure Workbooks create interactive monitoring dashboards that combine metrics, logs, charts, visualizations, and KQL queries for operational reporting.

Question 10

An organization wants to monitor a production SQL solution while minimizing unnecessary notifications that could overwhelm administrators.

Which recommendation represents a monitoring best practice?

A. Generate alerts for every informational event.

B. Disable monitoring during peak usage.

C. Configure actionable alerts based on meaningful thresholds and business impact.

D. Collect only CPU metrics.

Answer: C

Explanation: Effective monitoring focuses on actionable alerts that indicate genuine operational issues. Carefully chosen thresholds reduce alert fatigue while ensuring that critical events receive timely attention.

Go to the DP-800 Exam Prep Hub main page

azure, Data Development, Databases, DP-800, Microsoft Certification August 1, 2026August 1, 2026

Configure and implement DAB deployment (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Integrate SQL solutions with Azure services
      --> Configure and implement DAB deployment

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.

Introduction

Modern applications frequently require secure, scalable APIs to expose database objects without developers having to build and maintain extensive backend code. Data API Builder (DAB) is a Microsoft open-source runtime that automatically exposes Azure SQL Database, SQL Server, Azure Cosmos DB, PostgreSQL, and MySQL databases through REST and GraphQL endpoints.

While creating DAB configuration files is important, equally critical is deploying DAB securely and reliably into development, testing, staging, and production environments. The DP-800 exam expects SQL AI Developers to understand how DAB fits into CI/CD pipelines, containerized environments, Azure App Service, Azure Container Apps, Kubernetes, authentication systems, and infrastructure automation.

Understanding deployment strategies helps ensure that APIs remain secure, available, scalable, and maintainable.

What Is Data API Builder Deployment?

Deployment refers to the process of publishing the DAB runtime together with its configuration so that applications can consume database APIs.

A deployment includes:

Installing the DAB runtime
Providing the configuration file
Supplying environment variables
Configuring authentication
Connecting to databases
Deploying to the chosen hosting platform
Configuring monitoring
Configuring scaling
Managing updates

Unlike traditional applications, DAB is largely configuration-driven. Most deployments involve changing configuration rather than application code.

Common Deployment Targets

Microsoft supports several deployment options.

Local Development

Developers often begin locally using:

Windows
Linux
macOS

Example:

dab start

Advantages include:

Fast testing
Easy debugging
Local SQL Server integration
Rapid API validation

Local deployments should never expose production credentials.

Azure App Service

Azure App Service is one of the simplest production deployment options.

Benefits include:

Fully managed hosting
HTTPS enabled
Automatic scaling
Managed Identity
Deployment slots
Azure Monitor integration

Typical architecture:

			
Client
     |
Azure App Service
     |
Data API Builder
     |
Azure SQL Database

		

Azure Container Apps

Many organizations package DAB inside a Docker container.

Advantages include:

Container portability
Autoscaling
Microservices architecture
Revision management
Simple CI/CD integration

Container Apps are becoming increasingly common for cloud-native solutions.

Azure Kubernetes Service (AKS)

Larger organizations often deploy DAB using Kubernetes.

Benefits include:

High availability
Rolling updates
Horizontal scaling
Container orchestration
Service mesh integration

Although AKS offers the most flexibility, it is also the most complex deployment option.

Docker

DAB is commonly deployed as a Docker container.

Example Dockerfile:

			
FROM mcr.microsoft.com/data-api-builder
COPY dab-config.json /App/

Benefits include:

Consistent environments
Easy version control
Portable deployments
Works across cloud providers

DAB Configuration During Deployment

Every deployment needs access to:

dab-config.json
Database connection information
Authentication settings
Runtime configuration

The configuration file should be packaged together with the deployment or mounted as a configuration volume.

Environment Variables

Production deployments should avoid hardcoded settings.

Instead, use environment variables.

Examples:

			
SQL_CONNECTION_STRING
AZURE_CLIENT_ID
AZURE_TENANT_ID
JWT_AUDIENCE

Benefits include:

Improved security
Easier environment changes
Better DevOps automation

Secure Connection Strings

Never store credentials directly inside configuration files.

Instead use:

Azure Key Vault
GitHub Secrets
Azure DevOps Library
Kubernetes Secrets
Environment variables

Example:

Instead of:

Password=MyPassword123

Use:

Password=${SQL_PASSWORD}

Managed Identity

One of Microsoft’s recommended deployment practices is using Managed Identity.

Instead of storing SQL credentials:

			
Application
    |
Managed Identity
    |
Azure SQL

		

Benefits include:

No stored passwords
Automatic credential rotation
Azure AD authentication
Reduced attack surface

DP-800 heavily emphasizes Managed Identity.

Authentication Configuration

Production deployments usually configure authentication providers such as:

Microsoft Entra ID
JWT providers
OAuth 2.0
Static development authentication (development only)

Authentication should be enabled before exposing APIs publicly.

HTTPS

Production DAB deployments should always use HTTPS.

Benefits include:

Encrypts traffic
Protects authentication tokens
Prevents packet interception
Supports secure REST and GraphQL endpoints

Azure App Service enables HTTPS automatically.

Reverse Proxies

Many production deployments place DAB behind:

Azure API Management
Azure Front Door
Azure Application Gateway
NGINX
Traefik

Advantages:

Centralized security
Rate limiting
Caching
Authentication
Request logging

CI/CD Deployment

DAB deployments fit naturally into DevOps pipelines.

Typical pipeline:

			
Developer
      |
Git Repository
      |
Build Pipeline
      |
Unit Tests
      |
Create Docker Image
      |
Deploy
      |
Smoke Tests
      |
Production

		

Azure DevOps Deployment

Typical stages include:

Restore dependencies
Build
Validate DAB configuration
Build container
Push image
Deploy
Run validation tests

GitHub Actions

GitHub Actions commonly automate DAB deployment.

Example workflow:

			
Push
↓
Build
↓
Run Tests
↓
Create Container
↓
Publish Image
↓
Deploy Azure

		

Infrastructure as Code

Many organizations deploy DAB using:

Bicep
ARM templates
Terraform

Benefits include:

Repeatability
Version control
Consistent infrastructure
Automated provisioning

Configuration Validation

Before deployment, validate:

JSON syntax
Entity definitions
Authentication settings
Database connectivity
GraphQL relationships
Stored procedure mappings

Validation reduces deployment failures.

Monitoring

Production deployments should include monitoring.

Useful Azure services include:

Azure Monitor
Application Insights
Log Analytics
Azure Diagnostics

Monitor:

Request latency
Errors
Authentication failures
API throughput
CPU
Memory

Logging

Logs assist troubleshooting.

Typical events:

Startup failures
Invalid requests
Authentication failures
Database connection errors
SQL execution errors

Logs should never expose sensitive information.

Scaling DAB

Scaling depends on the hosting platform.

Azure App Service

Scale up
Scale out

Azure Container Apps

Autoscaling
Revision-based deployments

AKS

Horizontal Pod Autoscaler
Multiple replicas

High Availability

Production deployments commonly use:

Multiple DAB instances
Load balancers
Regional redundancy
Health probes

These reduce downtime.

Deployment Slots

Azure App Service supports deployment slots.

Example:

			
Production
↓
Staging Slot
↓
Validation
↓
Swap

		

Benefits:

Zero-downtime deployment
Easy rollback
Safe production updates

Versioning

Multiple API versions may run simultaneously.

Example:

			
v1
v2
v3

Benefits include:

Backward compatibility
Easier client migration
Controlled feature rollout

Rollback Strategy

Every deployment should support rollback.

Common methods:

Previous Docker image
Previous deployment slot
Previous Git tag
Previous release pipeline

Rollback minimizes production risk.

Security Best Practices

Recommended practices include:

HTTPS only
Managed Identity
Least privilege
Azure Key Vault
Authentication enabled
Authorization configured
Secure secrets
Monitor logs
Enable auditing
Disable unused endpoints

DP-800 Exam Tips

Remember these key points:

DAB deployments commonly use Azure App Service, Azure Container Apps, Docker, or AKS.
Avoid hardcoded secrets.
Prefer Managed Identity over SQL usernames/passwords.
Store secrets in Azure Key Vault.
Automate deployments using GitHub Actions or Azure DevOps.
Validate configurations before deployment.
Use deployment slots to minimize downtime.
Monitor deployments with Azure Monitor and Application Insights.
Use HTTPS for every production deployment.
Implement rollback strategies.

Practice Exam Questions

Question 1

Your organization wants to deploy Data API Builder with automatic operating system patching, built-in HTTPS, deployment slots, and minimal administrative overhead.

Which deployment target best meets these requirements?

A. Azure Kubernetes Service

B. Azure App Service

C. Self-managed virtual machine

D. Docker Desktop

Answer: B

Explanation: Azure App Service is a fully managed platform that provides HTTPS, automatic OS maintenance, deployment slots, autoscaling, and simplified application hosting.

Question 2

A company wants to eliminate database passwords from its DAB deployment while securely authenticating to Azure SQL Database.

What is the recommended authentication method?

A. Store SQL credentials in Git

B. Use SQL Authentication with encrypted passwords

C. Use Azure Managed Identity

D. Create a shared administrator account

Answer: C

Explanation: Managed Identity removes the need to store credentials, uses Microsoft Entra ID authentication, and automatically manages credential rotation.

Question 3

Which deployment practice provides the greatest protection for database connection strings?

A. Embed the connection string in the DAB configuration file

B. Store the connection string in application source code

C. Save credentials in a shared documentation file

D. Store secrets in Azure Key Vault and reference them during deployment

Answer: D

Explanation: Azure Key Vault securely stores secrets outside application code and integrates with Managed Identity and deployment pipelines.

Question 4

During deployment, a development team wants every code commit to automatically build, validate, test, and deploy DAB.

Which approach should they use?

A. Manual deployment using PowerShell

B. SQL Server Management Studio

C. A CI/CD pipeline using GitHub Actions or Azure DevOps

D. Windows Task Scheduler

Answer: C

Explanation: CI/CD pipelines automate builds, testing, validation, packaging, and deployment, reducing manual effort and deployment errors.

Question 5

Why should production DAB deployments use HTTPS?

A. It increases SQL query speed.

B. It compresses GraphQL responses.

C. It encrypts network communication between clients and the API.

D. It eliminates authentication requirements.

Answer: C

Explanation: HTTPS protects sensitive information such as authentication tokens and API traffic from interception during transmission.

Question 6

Which Azure service is specifically designed to collect application telemetry, performance metrics, and diagnostics for deployed DAB applications?

A. Azure Application Insights

B. Azure Storage Explorer

C. Azure Bastion

D. Azure Data Factory

Answer: A

Explanation: Application Insights provides monitoring, distributed tracing, diagnostics, performance metrics, and failure analysis for deployed applications.

Question 7

A team wants to release a new DAB version without interrupting production users and retain the ability to roll back immediately if problems occur.

Which Azure App Service feature should they use?

A. Reserved instances

B. Deployment slots

C. Availability zones

D. Geo-replication

Answer: B

Explanation: Deployment slots allow applications to be validated before swapping into production and enable quick rollback if issues are discovered.

Question 8

Why are environment variables commonly used during DAB deployment?

A. They automatically optimize SQL queries.

B. They eliminate authentication requirements.

C. They reduce GraphQL response sizes.

D. They separate configuration from application code and simplify deployment across environments.

Answer: D

Explanation: Environment variables allow different settings for development, testing, and production without modifying the application or configuration files.

Question 9

Which deployment platform provides the highest level of container orchestration and scalability for large enterprise DAB deployments?

A. Azure Kubernetes Service

B. Azure App Service

C. Windows Server

D. Docker Desktop

Answer: A

Explanation: AKS offers advanced orchestration, automatic scaling, rolling updates, service discovery, and high availability for enterprise containerized workloads.

Question 10

Before promoting a DAB deployment to production, what validation activity is most important?

A. Disable authentication temporarily.

B. Increase CPU resources.

C. Validate configuration files, authentication settings, and database connectivity.

D. Remove monitoring to improve performance.

Answer: C

Explanation: Validating configuration, connectivity, and authentication helps prevent deployment failures and ensures the API functions correctly before reaching production users.

Go to the DP-800 Exam Prep Hub main page

Overview

1. Understanding Kubernetes Manifest Files

2. YAML Manifest Structure

3. The apiVersion Property

4. The kind Property

5. Kubernetes Deployments

6. Labels and Selectors

Exam Tip

7. Container Images

Best Practice

8. Connecting AKS to Azure Container Registry

9. Exposing an Application with a Service

10. Service Types

ClusterIP

NodePort

LoadBalancer

11. Deploying a Manifest to AKS

12. Applying Multiple Resources in One File

13. Connecting kubectl to AKS

Exam Tip

14. Namespaces

15. Environment Variables

16. ConfigMaps

17. Kubernetes Secrets

18. Resource Requests and Limits

Requests

Limits

19. Health Probes

Startup probe

Readiness probe

Liveness probe

Exam Distinction

20. Updating an Application

21. Checking Deployment Status

22. Viewing Application Logs

23. Using kubectl describe

24. Common Deployment Problems

ImagePullBackOff

CrashLoopBackOff

Pod stuck in Pending

Service has no endpoints

25. Managing Applications Declaratively

26. Manifest Files and CI/CD

27. Example Complete Manifest

28. Important Commands to Know

29. Key Exam Takeaways

Manifest

Deployment

Pod

Service

Labels

Selectors

ConfigMap

Secret

kubectl apply

ACR

Readiness probe

Liveness probe

Startup probe

kubectl describe

kubectl logs

Practice Exam Questions

Question 1

Answer: A

Explanation

Question 2

Answer: B

Explanation

Question 3

Answer: C

Explanation

Question 4

Answer: B

Explanation

Question 5

Answer: A

Explanation

Question 6

Answer: D

Explanation

3. The `apiVersion` Property

4. The `kind` Property

13. Connecting `kubectl` to AKS

23. Using `kubectl describe`

`ImagePullBackOff`

`CrashLoopBackOff`

Pod stuck in `Pending`

`kubectl apply`

`kubectl describe`

`kubectl logs`

7. `minReplicas`

8. `maxReplicas`

Mistake 4: Forgetting `maxReplicas`