General Exam Tips
- 1.Read ALL four answer options before choosing — AI-200 uses near-miss distractors that are almost correct but miss one key requirement
- 2.Map the data flow before selecting a service — the right Azure primitive almost always surfaces when you trace where data lives and how it moves
- 3.Any answer mentioning connection strings stored in code or environment variables is almost certainly wrong — the correct pattern is managed identity + RBAC
- 4.The exam tests the back-end plumbing that runs AI in production, not AI model selection or training — think containers, vector stores, messaging, and observability
- 5.Domain 2 (AI Data Management Services) is 28% of the exam — roughly 14 questions. If pressed for time, over-invest study hours here
- 6.There is no penalty for wrong answers — flag uncertain questions, finish the exam, and return with fresh eyes
- 7.Case studies present a multi-paragraph scenario then ask 4-6 questions. Read the requirements table first before the narrative
- 8.Beta exam note: AI-200 is in beta as of June 2026. Scores may take up to 8 weeks to arrive. The content and format are the same as GA
Quick Navigation
Develop Containerized Solutions on Azure
Must-Know Facts
- Container Apps vs AKS decision rule: Container Apps = serverless, KEDA-based, no Kubernetes manifest knowledge required; AKS = full Kubernetes, manifest files, ConfigMaps, node pool management, GPU workloads
- ACR Tasks automate image builds on code commit OR base image update — distinct from manual docker build + push workflows
- KEDA event-driven scaling in Container Apps: Service Bus queue depth, Event Grid events, HTTP requests, CPU, and custom metrics are all valid KEDA sources
- Container Apps revisions are IMMUTABLE — every configuration change (scaling rule, env var, image tag) creates a new revision, not an in-place update
- AKS persistent storage: Azure Disk = ReadWriteOnce (single pod, block storage, high IOPS); Azure Files = ReadWriteMany (multiple pods simultaneously, SMB/NFS)
- ConfigMaps in AKS store NON-sensitive data (feature flags, environment URLs). Kubernetes Secrets (or Key Vault CSI driver) store sensitive data like passwords
- Container Insights + KQL is the monitoring solution for both AKS and Container Apps — not Application Insights for container-level diagnostics
- App Service can host containers but is the simplest option with fewest controls — used when you need a basic web endpoint without orchestration needs
Common Traps
Confusing Pairs
Scenario Tips
When the question asks about scaling a containerized AI service based on Azure Service Bus queue depth
Configure a KEDA Azure Service Bus scaler on the Container App with the queue name and target message count threshold, setting minReplicas to 0 for scale-to-zero
CPU-based autoscaling — this reacts to compute load after messages are already being processed, not proactively to queue depth before load materializes
When the question asks about automatically rebuilding a container image whenever the upstream base Python image is updated
Use ACR Tasks with a base image trigger pointing to the base image repository
Azure DevOps scheduled pipeline — that runs on time intervals, not on base image change events
When the question describes an AI workload needing GPU nodes, custom node taints, and direct Kubernetes API access
Use AKS — Container Apps abstracts all Kubernetes primitives and does not expose GPU node pools, taints, tolerations, or the Kubernetes API
Container Apps with custom scaling — Container Apps does not support GPU nodes or Kubernetes-level resource constraints
When the question asks which Kubernetes resource stores non-sensitive configuration data used by multiple pods
ConfigMap — stores key-value pairs for environment variables, config files, or command-line arguments that are not sensitive
Kubernetes Secrets — Secrets are for sensitive data. Using Secrets for non-sensitive config is technically possible but wrong in exam context where ConfigMap is explicitly the right answer
Last-Minute Facts
Develop AI Solutions by Using Azure Data Management Services
Must-Know Facts
- Cosmos DB session consistency is the DEFAULT — not strong. Session consistency gives consistent reads for the same client session but may return slightly stale data for other clients
- Cosmos DB cross-partition queries consume significantly more RUs than single-partition queries with the partition key in the WHERE clause — partition key design is a performance multiplier
- Cosmos DB indexing policy: by default ALL paths are indexed. Excluding unused paths from the index REDUCES RU consumption on writes
- pgvector HNSW does NOT require reindexing after data changes — it is a graph-based index that updates incrementally. IVFFlat DOES require periodic reindexing (VACUUM ANALYZE) as data distribution shifts
- pgvector distance operators: <-> for L2 (Euclidean), <=> for cosine distance, <#> for negative inner product (dot product). Cosine distance is standard for normalized text embeddings
- Azure Managed Redis vector search requires Enterprise tier — the Basic and Standard tiers do NOT support the RediSearch module needed for vector indexing
- Cosmos DB change feed processor requires a lease container — this is a separate Cosmos DB container that tracks which changes have been processed
- RAG pattern with pgvector: store document chunks as rows with a vector column, query with ORDER BY embedding <=> $1 LIMIT k, apply metadata filters in a WHERE clause before the ORDER BY for hybrid search
- Connection pooling (pgBouncer) is mandatory for PostgreSQL at scale — without it, each new request opens a new connection and you hit the connection limit quickly under concurrent AI workloads
Common Traps
Confusing Pairs
Scenario Tips
When the question asks about the fastest vector search query performance at query time and the team can tolerate long index build time
Choose HNSW index — it delivers the best query latency and recall accuracy once built, at the cost of longer initial build time and higher memory usage
IVFFlat — it builds faster but is slower at query time, making it wrong when 'fastest query performance' is the stated requirement
When the question describes a Cosmos DB container receiving millions of documents and asks about reducing RU consumption on writes
Modify the indexing policy to exclude paths that are never queried — fewer indexed paths means lower RU cost per write
Increasing RU throughput — that adds capacity but does not reduce per-operation cost, and the question asks about optimizing consumption not just handling load
When the question asks which Cosmos DB consistency level to choose for a single-user chat application where each user must always see their own latest messages
Session consistency — it guarantees that reads within the same client session always reflect the latest writes from that session, which is exactly what a single-user chat requires, at lower cost than Strong
Strong consistency — technically correct but costs more RUs and is unnecessary when per-session consistency is sufficient for the requirement
When the question asks about detecting and processing new items added to a Cosmos DB container to trigger downstream AI enrichment
Use the Cosmos DB change feed processor with a separate lease container, or an Azure Functions Cosmos DB trigger — both read new and updated items in order
Cosmos DB stored procedures — these execute within a transaction context, not for external event-driven processing
When the question describes a RAG pipeline needing vector similarity search combined with filtering by document category and date
Use PostgreSQL pgvector with a WHERE clause on category and date BEFORE the ORDER BY embedding <=> $1 LIMIT k — this is the pre-filter hybrid search pattern
Cosmos DB vector search — while Cosmos DB supports vector search, it does not handle relational joins and hybrid SQL filtering as elegantly as pgvector's integrated WHERE + ORDER BY pattern
Last-Minute Facts
Connect to and Consume Azure Services
Must-Know Facts
- Service Bus vs Event Grid: Service Bus = messages (commands to be processed, pulled by consumers, guaranteed delivery, ordering, dead-lettering). Event Grid = events (state change notifications, pushed to subscribers, near-real-time, lighter weight)
- Service Bus PeekLock mode: message is locked during processing, explicitly completed or abandoned. ReceiveAndDelete: message deleted immediately upon receive — if processing fails, message is PERMANENTLY LOST
- Dead-letter queue (DLQ): receives messages that exceed MaxDeliveryCount, have expired TTL, or failed filter evaluation. DLQ messages do NOT automatically return to the main queue — you must explicitly process them
- Azure Functions Service Bus trigger uses PeekLock by default — an unhandled exception causes the message to be abandoned and retried up to MaxDeliveryCount before moving to DLQ
- Event Grid subject filters are case-sensitive — /subscriptions/Production will NOT match /subscriptions/production
- Event Grid dead-lettering sends failed events to a STORAGE BLOB CONTAINER, not a Service Bus queue
- Azure Functions output bindings: write data to Cosmos DB, Service Bus, Event Grid, Storage, etc. without writing explicit SDK code — the binding handles it
- Azure Functions input bindings: read data from services at function invocation time without SDK code — useful for loading context data before processing
Common Traps
Confusing Pairs
Scenario Tips
When the question asks about a message queue where messages that fail processing 10 times should be automatically moved out of the main queue for inspection
Service Bus dead-letter queue — when MaxDeliveryCount is exceeded, Service Bus automatically moves the message to the DLQ without any additional configuration
Event Grid dead-lettering — Event Grid dead-letters to a blob storage container, not a queue, and it is for events not commands. Also, the question describes ordered, command-style processing which is Service Bus.
When the question describes multiple independent downstream services that each need to process every AI training completion event
Service Bus Topic with one Subscription per downstream service — each subscription receives its own independent copy of every message
Service Bus Queue — a queue delivers each message to only ONE consumer; the first service to pick it up gets it, and other services never see that message
When the question asks how to build a serverless function that reads an HTTP request, looks up a record from Cosmos DB by ID, and writes a result back to Cosmos DB with minimal code
HTTP trigger + Cosmos DB input binding (for the lookup) + Cosmos DB output binding (for the write) — no SDK code needed for either data operation
HTTP trigger with explicit CosmosClient SDK calls — this works but contradicts the 'minimal code' requirement that signals to use bindings
When the question asks about filtering Event Grid subscriptions to only receive events from a specific environment tag in the event subject
Advanced subject filter or event data filter on the Event Grid subscription — advanced filters can match on custom event data properties or subject patterns
Service Bus topic SQL filters — SQL filters apply to Service Bus, not Event Grid. These are completely different filtering mechanisms for different services.
Last-Minute Facts
Secure, Monitor, and Troubleshoot Azure Solutions
Must-Know Facts
- OpenTelemetry replaces Application Insights SDK on AI-200 — questions reference ActivitySource (for spans/traces) and Meter (for metrics), NOT TelemetryClient
- Managed identities = ALWAYS the correct answer when asked how to authenticate to Azure services without storing credentials — never store connection strings in code
- System-assigned managed identity: 1:1 with the Azure resource, deleted when resource is deleted, cannot be shared. User-assigned: standalone, shareable across multiple resources, persists after resource deletion
- Key Vault soft-delete is ENABLED BY DEFAULT on all new vaults and cannot be disabled — deleted secrets are recoverable for 7-90 days depending on retention policy
- Key Vault vs App Configuration: Key Vault = secrets (passwords, API keys, certificates, connection strings). App Configuration = settings (feature flags, non-sensitive configuration). App Configuration can reference Key Vault secrets via Key Vault references
- KQL case sensitivity: string comparisons with == are case-sensitive; use =~ for case-insensitive comparisons — this is a common KQL trap
- OpenTelemetry ActivitySource creates Spans within a trace; a trace is a collection of spans representing an end-to-end request. W3C TraceContext headers propagate trace context between services
- Azure Monitor receives OpenTelemetry telemetry via the Azure Monitor OpenTelemetry Distro exporter — UseAzureMonitor() is the one-line setup, with custom spans added via ActivitySource
Common Traps
Confusing Pairs
Scenario Tips
When the question asks how to instrument a distributed AI pipeline across three Container Apps services for end-to-end tracing
Install the OpenTelemetry SDK in each service, create an ActivitySource, start spans for each operation, and configure W3C TraceContext propagation for automatic context propagation across HTTP calls. Export to Azure Monitor via UseAzureMonitor()
Application Insights SDK with TelemetryClient — this is the legacy approach and is explicitly NOT what AI-200 tests. Any answer mentioning TelemetryClient is wrong.
When the question asks how to authenticate an AKS pod to Azure Key Vault without storing credentials anywhere
Use workload identity (Azure AD Workload Identity) on the AKS pod, which projects a managed identity into the pod's service account token, granting it RBAC access to Key Vault without any secrets in the pod spec
Mount the Key Vault connection string as a Kubernetes Secret — this stores a credential in a Kubernetes Secret, which is still a credential (base64 encoded, not encrypted at rest by default)
When the question asks which KQL operator to use to count errors by service name regardless of case in the log data
Use =~ for case-insensitive string comparison: where serviceName =~ 'inference-service' | summarize count() by serviceName
Using == (case-sensitive) — will miss records where the service name casing differs from what the query expects, silently returning incomplete results
When the question asks how to store an application setting that references a Key Vault secret so the app only needs one configuration source
Store a Key Vault reference in Azure App Configuration — the value is the Key Vault secret URI, and the App Configuration SDK resolves it at runtime from Key Vault automatically
Store the secret value directly in App Configuration — App Configuration is not designed to protect secret values and does not have Key Vault-level access controls or audit logging