AI-200 - Microsoft Certified Azure AI Cloud Developer Associate Cheat Sheet

Updated 2026-08-07

Next Topic: AI-300 - Microsoft Certified Machine Learning Operations Engineer Associate Cheat Sheet

🎯Take a practice test on this topic7 practice tests · 236 questions→

🧠Study flashcards on this topic194 cards · spaced repetition→

The AI-200 exam certifies your ability to build and operate AI solutions on Azure, with a heavy focus on the back-end services that hold an AI application together (containers, data platforms, messaging, and observability) rather than the AI models themselves. Candidates are expected to be comfortable with Azure SDKs, third-party SDKs, Python, and the full delivery lifecycle from requirements and design through deployment, security, and monitoring. The exam leans hardest on Azure's data layer: Cosmos DB for NoSQL, Azure Database for PostgreSQL with pgvector, and Azure Managed Redis, since vector storage and retrieval-augmented generation patterns are the backbone of most production AI apps. Expect scenario questions that test whether you reach for the right service under pressure, such as Service Bus versus Event Grid for a given workload, the right KEDA scale trigger for a bursty queue, or the exact Cosmos DB consistency level a design calls for.

What This Cheat Sheet Covers

This topic spans 21 focused tables and 195 indexed concepts, 194 flashcards, 7 practice tests with 236 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Container Registry & App Service HostingTable 2: Azure Container Apps: Deployment, Environments & RevisionsTable 3: KEDA Event-Driven Autoscaling in Container AppsTable 4: AKS Deployment via Manifest FilesTable 5: Monitoring & Troubleshooting AKS and Container AppsTable 6: Cosmos DB for NoSQL: SDK Connectivity & QueriesTable 7: Cosmos DB for NoSQL: RU Optimization, Indexing Policies & Consistency LevelsTable 8: Cosmos DB for NoSQL: Vector Search & EmbeddingsTable 9: Cosmos DB for NoSQL: Change Feed ProcessingTable 10: Azure Database for PostgreSQL: Connectivity, Queries & Connection OptimizationTable 11: Azure Database for PostgreSQL: Schema Design, Data Types & Table IndexingTable 12: Azure Database for PostgreSQL: pgvector Performance & Resource ConfigurationTable 13: Azure Database for PostgreSQL: Vector Similarity Search & RAG PatternsTable 14: Azure Managed Redis: Caching Operations & Vector Indexing for AITable 15: Azure Service Bus: Queues, Topics, Subscriptions & Dead-Letter HandlingTable 16: Azure Event Grid: Event-Driven Workflows, Filters & RetriesTable 17: Azure Functions: Triggers, Bindings & DeploymentTable 18: Securing Secrets with Azure Key VaultTable 19: Azure App Configuration: Storing & Retrieving App SettingsTable 20: Distributed Tracing with OpenTelemetry SDKsTable 21: Log & Metric Analysis with KQL

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Container Registry & App Service Hosting

Covers building, storing, versioning, and managing container images in Azure Container Registry (ACR), automating builds with ACR Tasks, and deploying those images to Azure App Service with the right environment variables and secrets.

Concept	Example	Description
Repositories & Tags	`docker push myregistry.azurecr.io/samples/nginx:v1` (after `az acr login`)	• A repository groups every version of one image; each push adds a new tag inside it. • Registries hold both Windows and Linux images, plus OCI artifacts like Helm charts, as read-only snapshots.
Image Tag Versioning (Stable vs Unique Tags)	Stable: `myimage:1` (keeps receiving updates) Unique: `myimage:build482` (never reused)	• Use a stable tag only for base images you want to keep patching • use a unique tag for every deployment so a restart or scale-out can't silently pull a newer, inconsistent image • Not the same as locking a tag, which stops accidental deletion, not drift
az acr import (Import Images Without Docker)	`az acr import --name myregistry --source docker.io/library/hello-world:latest --image hello-world:latest`	• Copies an image directly between registries (a public registry, Docker Hub, Microsoft Container Registry, or another ACR) server-side, with no local Docker install and no pull/push round trip. • Handy for privately caching a public base image.
Container Registry SKU Tiers	Basic (dev/test) • Standard (more storage/throughput) • Premium (geo-replication, content trust, private endpoints)	• All tiers support webhooks, Microsoft Entra sign-in, and delete • only Premium adds geo-replication for serving one registry across regions and content trust for signed image tags • Picking Basic and then needing geo-replication is a common under-provisioning gap
Auto-Purge Untagged Manifests	`az acr run --cmd "acr purge --filter 'hello-world:.*' --untagged --ago 1d" --registry myregistry /dev/null`	• `acr purge` is designed to run as the command inside an ACR Task (on demand or on a schedule), not as a portal setting. • Untagged manifests pile up whenever a stable tag gets moved to a new digest.
ACR Quick Task (az acr build)	`az acr build --registry myregistry --image helloacrtasks:v1 --file Dockerfile .`	• Runs a one-off `docker build` plus `docker push` in Azure on demand, with no local Docker Engine required • It's the inner-loop way to validate a build before committing code, not a way to react to future events
Automatically Triggered Task (Source Commit)	`az acr task create --registry myregistry --name taskhelloworld --image helloworld:{{.Run.ID}} --context https://github.com/user/repo.git#main --file Dockerfile --git-access-token $GIT_PAT`	• Builds automatically whenever code is committed to the configured branch • the commit trigger is on by default, but the pull-request trigger is off by default and must be enabled separately • Needs a personal access token to register the repo webhook
Base Image Update Trigger	`az acr task update --registry myregistry --name mytask --base-image-trigger-enabled False` (it's `True` by default)	• ACR Tasks discovers an image's base-image dependency the first time the task actually builds it, then rebuilds every dependent application image whenever that base image updates, automating OS/framework patching • The base image needs a stable tag, and only runtime images are tracked, not intermediate multi-stage buildtime images
Multi-Step Tasks	`steps:` `• - build: -t $Registry/app:$ID .` `• - push: ["$Registry/app:$ID"]` `• - cmd: $Registry/app-test:$ID`	• One YAML file defines `build`, `push`, and `cmd` steps with dependencies between them, so a single task run can build an image, run a test container against it, and only push on success. • Steps can run in series or in parallel.
Scheduled Task (Timer Trigger)	`az acr task timer add --name timertask --registry myregistry --timer-name timer2 --schedule "30 10 * * *"`	• Adds a recurring cron trigger (5 fields: minute hour day month day-of-week, UTC, no seconds or year) to an existing task, useful for a nightly purge or maintenance run • A timer can be layered onto a task alongside its other triggers
Deploy Container to App Service (Private Registry)	`az webapp config container set --name myapp --resource-group mygroup --container-image-name myregistry.azurecr.io/myimage:v1 --docker-registry-server-url https://myregistry.azurecr.io --docker-registry-server-user <user> --docker-registry-server-password <pwd>`	• Points a web app at a custom image and its private registry using explicit credentials; App Service pulls and runs that image instead of a built-in language stack. • The `WEBSITES_PORT` setting tells App Service which single port the container exposes.
Managed Identity + AcrPull Role (App Service to ACR)	`az webapp identity assign ...` then `az role assignment create --assignee <principalId> --scope <acrResourceId> --role "AcrPull"`	• Microsoft's recommended way for App Service to pull from ACR: give the web app a managed identity, then grant it the AcrPull role on the registry, with no stored credentials at all • The registry must also accept ARM audience tokens, or the pull fails with an UNAUTHORIZED error
ACR Admin Account	`az acr update -n myregistry --admin-enabled true` (disabled by default)	• One shared username/password pair with full push and pull access to the whole registry, designed for a single user's testing, not for production App Service deployments • Not to be confused with managed identity, the recommended production path that needs no admin user enabled at all
App Service Application Settings as Environment Variables	`az webapp config appsettings set --resource-group mygroup --name myapp --settings DB_HOST="myserver.mysql.database.azure.com"`	• Every App Service application setting is injected into the container process as an environment variable at startup. • Settings are encrypted at rest, but for a secret that needs central rotation and auditing, a Key Vault reference is the better fit.
Key Vault References for App Service Secrets	`@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)`	• Stores an app setting's value as a pointer to a Key Vault secret instead of the raw value • App Service resolves it at runtime using the app's managed identity, which needs the Key Vault Secrets User role on the vault • Rotating the secret in the vault updates the app with no redeploy

Table 2: Azure Container Apps: Deployment, Environments & Revisions

Azure Container Apps deploys a containerized workload into an environment and tracks every change to it as an immutable revision. This table maps the deployment commands, environment types, and revision-mode mechanics an AI-200 candidate needs for the Implement container-orchestrated solutions task area.

Concept	Example	Description
Container Apps Environment	`az containerapp up --name <APP> --image <IMG> --ingress external --target-port 80` auto-creates an environment and a Log Analytics workspace if none exists in the resource group	• The secure boundary a container app runs inside; the platform handles OS upgrades, scale operations, failover, and resource balancing for every app and job placed in it. • Apps in the same environment share one virtual network and one log destination • Not a self-managed cluster, there are no nodes to patch yourself

The rest of this section is part of the full cheat sheet

Table 3: KEDA Event-Driven Autoscaling in Container Apps

Covers Implement container-orchestrated solutions, specifically enabling KEDA (Kubernetes Event-driven Autoscaling) based scale rules, limits, and behavior for Azure Container Apps.

Concept	Example	Description
KEDA (Kubernetes Event-Driven Autoscaling)	`Container Apps → KEDA evaluates HTTP, TCP, and custom scale rules alike`	• The engine built into Container Apps that evaluates every scale rule you define. • Supports HTTP requests, TCP connections, CPU/memory load, and event sources (Service Bus, Event Hubs, Kafka, Redis). • Ships built in, never installed or patched separately.

The rest of this section is part of the full cheat sheet

Table 4: AKS Deployment via Manifest Files

Covers deploying and managing applications on Azure Kubernetes Service (AKS) with Kubernetes manifest files: the declarative kubectl apply workflow, the Deployment/ReplicaSet/Pod object model, Service types and Ingress for exposing an app, Namespaces for isolation, ConfigMaps for externalized config, and rolling updates with rollback.

Concept	Example	Description
Declarative Manifest Deployment	`kubectl apply -f aks-store-quickstart.yaml`	• A manifest file declares a cluster's desired state (images, replicas, Services) • `kubectl apply -f` reconciles the live AKS cluster to match it • Preferred over one-off imperative commands for a reviewable, repeatable deployment

The rest of this section is part of the full cheat sheet

Table 1: Container Registry & App Service Hosting

Concept	Example	Description
Repositories & Tags	`docker push myregistry.azurecr.io/samples/nginx:v1` (after `az acr login`)	• A repository groups every version of one image; each push adds a new tag inside it. • Registries hold both Windows and Linux images, plus OCI artifacts like Helm charts, as read-only snapshots.
Image Tag Versioning (Stable vs Unique Tags)	Stable: `myimage:1` (keeps receiving updates) Unique: `myimage:build482` (never reused)	• Use a stable tag only for base images you want to keep patching • use a unique tag for every deployment so a restart or scale-out can't silently pull a newer, inconsistent image • Not the same as locking a tag, which stops accidental deletion, not drift
az acr import (Import Images Without Docker)	`az acr import --name myregistry --source docker.io/library/hello-world:latest --image hello-world:latest`	• Copies an image directly between registries (a public registry, Docker Hub, Microsoft Container Registry, or another ACR) server-side, with no local Docker install and no pull/push round trip. • Handy for privately caching a public base image.
Container Registry SKU Tiers	Basic (dev/test) • Standard (more storage/throughput) • Premium (geo-replication, content trust, private endpoints)	• All tiers support webhooks, Microsoft Entra sign-in, and delete • only Premium adds geo-replication for serving one registry across regions and content trust for signed image tags • Picking Basic and then needing geo-replication is a common under-provisioning gap
Auto-Purge Untagged Manifests	`az acr run --cmd "acr purge --filter 'hello-world:.*' --untagged --ago 1d" --registry myregistry /dev/null`	• `acr purge` is designed to run as the command inside an ACR Task (on demand or on a schedule), not as a portal setting. • Untagged manifests pile up whenever a stable tag gets moved to a new digest.
ACR Quick Task (az acr build)	`az acr build --registry myregistry --image helloacrtasks:v1 --file Dockerfile .`	• Runs a one-off `docker build` plus `docker push` in Azure on demand, with no local Docker Engine required • It's the inner-loop way to validate a build before committing code, not a way to react to future events
Automatically Triggered Task (Source Commit)	`az acr task create --registry myregistry --name taskhelloworld --image helloworld:{{.Run.ID}} --context https://github.com/user/repo.git#main --file Dockerfile --git-access-token $GIT_PAT`	• Builds automatically whenever code is committed to the configured branch • the commit trigger is on by default, but the pull-request trigger is off by default and must be enabled separately • Needs a personal access token to register the repo webhook
Base Image Update Trigger	`az acr task update --registry myregistry --name mytask --base-image-trigger-enabled False` (it's `True` by default)	• ACR Tasks discovers an image's base-image dependency the first time the task actually builds it, then rebuilds every dependent application image whenever that base image updates, automating OS/framework patching • The base image needs a stable tag, and only runtime images are tracked, not intermediate multi-stage buildtime images
Multi-Step Tasks	`steps:` `• - build: -t $Registry/app:$ID .` `• - push: ["$Registry/app:$ID"]` `• - cmd: $Registry/app-test:$ID`	• One YAML file defines `build`, `push`, and `cmd` steps with dependencies between them, so a single task run can build an image, run a test container against it, and only push on success. • Steps can run in series or in parallel.
Scheduled Task (Timer Trigger)	`az acr task timer add --name timertask --registry myregistry --timer-name timer2 --schedule "30 10 * * *"`	• Adds a recurring cron trigger (5 fields: minute hour day month day-of-week, UTC, no seconds or year) to an existing task, useful for a nightly purge or maintenance run • A timer can be layered onto a task alongside its other triggers
Deploy Container to App Service (Private Registry)	`az webapp config container set --name myapp --resource-group mygroup --container-image-name myregistry.azurecr.io/myimage:v1 --docker-registry-server-url https://myregistry.azurecr.io --docker-registry-server-user <user> --docker-registry-server-password <pwd>`	• Points a web app at a custom image and its private registry using explicit credentials; App Service pulls and runs that image instead of a built-in language stack. • The `WEBSITES_PORT` setting tells App Service which single port the container exposes.
Managed Identity + AcrPull Role (App Service to ACR)	`az webapp identity assign ...` then `az role assignment create --assignee <principalId> --scope <acrResourceId> --role "AcrPull"`	• Microsoft's recommended way for App Service to pull from ACR: give the web app a managed identity, then grant it the AcrPull role on the registry, with no stored credentials at all • The registry must also accept ARM audience tokens, or the pull fails with an UNAUTHORIZED error
ACR Admin Account	`az acr update -n myregistry --admin-enabled true` (disabled by default)	• One shared username/password pair with full push and pull access to the whole registry, designed for a single user's testing, not for production App Service deployments • Not to be confused with managed identity, the recommended production path that needs no admin user enabled at all
App Service Application Settings as Environment Variables	`az webapp config appsettings set --resource-group mygroup --name myapp --settings DB_HOST="myserver.mysql.database.azure.com"`	• Every App Service application setting is injected into the container process as an environment variable at startup. • Settings are encrypted at rest, but for a secret that needs central rotation and auditing, a Key Vault reference is the better fit.
Key Vault References for App Service Secrets	`@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)`	• Stores an app setting's value as a pointer to a Key Vault secret instead of the raw value • App Service resolves it at runtime using the app's managed identity, which needs the Key Vault Secrets User role on the vault • Rotating the secret in the vault updates the app with no redeploy

Table 2: Azure Container Apps: Deployment, Environments & Revisions

Concept	Example	Description
Container Apps Environment	`az containerapp up --name <APP> --image <IMG> --ingress external --target-port 80` auto-creates an environment and a Log Analytics workspace if none exists in the resource group	• The secure boundary a container app runs inside; the platform handles OS upgrades, scale operations, failover, and resource balancing for every app and job placed in it. • Apps in the same environment share one virtual network and one log destination • Not a self-managed cluster, there are no nodes to patch yourself

Table 3: KEDA Event-Driven Autoscaling in Container Apps

Covers Implement container-orchestrated solutions, specifically enabling KEDA (Kubernetes Event-driven Autoscaling) based scale rules, limits, and behavior for Azure Container Apps.

Concept	Example	Description
KEDA (Kubernetes Event-Driven Autoscaling)	`Container Apps → KEDA evaluates HTTP, TCP, and custom scale rules alike`	• The engine built into Container Apps that evaluates every scale rule you define. • Supports HTTP requests, TCP connections, CPU/memory load, and event sources (Service Bus, Event Hubs, Kafka, Redis). • Ships built in, never installed or patched separately.

Table 4: AKS Deployment via Manifest Files

Concept	Example	Description
Declarative Manifest Deployment	`kubectl apply -f aks-store-quickstart.yaml`	• A manifest file declares a cluster's desired state (images, replicas, Services) • `kubectl apply -f` reconciles the live AKS cluster to match it • Preferred over one-off imperative commands for a reviewable, repeatable deployment