AI-200 Azure AI Cloud Developer Guide (2026)

Exam AI-200: Developing AI Cloud Solutions on Azure is aimed at developers who implement the back-end services and components around AI workloads. The official audience profile spans the full development lifecycle: requirements, design, development, deployment, security, and monitoring. It expects familiarity with Azure and third-party SDKs, Azure data management, messaging and eventing, vector databases, Python, containerized applications, and operational troubleshooting.

That scope makes AI-200 different from a model-only exam. A model invocation can be a small part of a production request. The application still needs a versioned container image, an identity, a configuration source, a vector or operational database, an event or message contract, retries, a dead-letter path, scaling rules, traces, metrics, logs, cost bounds, and a tested cleanup plan. A candidate who memorizes service slogans but cannot diagnose a replica, an RU-heavy query, a stale cache, or a poison message is not preparing for the role described by the guide.

The PrepKloud five-phase AI-200 roadmap turns the blueprint into a sequence. This guide explains why those phases fit together and how to practice them without using exam dumps or marketplace material.

Official AI-200 domains and study allocation

Use the ranges to allocate practice, but do not study the domains as isolated products. A document-processing scenario can begin with an Event Grid event, enter a Function, publish a Service Bus command, wake a KEDA-scaled Container App, write vectors to Cosmos DB, retrieve a third-party secret from Key Vault, and emit OpenTelemetry to Azure Monitor. The architecture crosses all four domains, and the best answer must satisfy every stated constraint.

Domain 1: container artifacts, hosting, orchestration, and diagnosis

Begin at Azure Container Registry (ACR). Understand that a repository holds manifests and layers; a tag is a human-friendly pointer that can move; a digest identifies immutable content. A mature release uses a unique version tag and records the resolved digest so the tested bytes are promoted to production. Rebuilding the same source separately in each environment weakens provenance, while deploying latest makes rollback ambiguous.

ACR Tasks moves image builds and maintenance into Azure. Practice a manual task, a source-triggered build, a scheduled task, and the base-image update pattern. The goal is not to memorize command syntax. It is to decide when a cloud build, an automated patch rebuild, or a repeatable multi-step task removes unmanaged infrastructure and improves traceability.

For Azure App Service custom containers, verify the listening port, the process binding, startup behavior, environment variables, image access, and logs. Keep environment configuration outside the image. App settings become environment variables, and supported Key Vault references can protect values that remain secrets. Prefer managed identity directly to Azure services so fewer secrets exist in the first place.

Azure Container Apps adds revision lifecycle and event-driven scaling. A revision is an immutable snapshot of an application version. Multiple-revision mode and traffic weights enable canary, A/B, and blue-green releases. A safe lab should deploy a candidate digest, send a small percentage of traffic, compare health and latency by revision, then move traffic back without rebuilding when the candidate fails a gate.

Container Apps uses KEDA for declarative scaling. HTTP concurrency suits APIs; queue depth suits workers; CPU and memory can supplement workload signals. Azure Service Bus scalers can use managed identity. Scale-to-zero saves idle cost, but a maximum replica count is equally important: each replica may open database connections or consume model quota. Autoscaling must protect the next bottleneck rather than amplify it.

AKS remains in scope. Practice applying manifests and reading evidence, not only creating a cluster. For a failed pod, inspect conditions, events, describe output, current and previous logs, image pull status, commands, secrets, resource limits, and probes. For a connectivity failure, trace DNS, service selectors, endpoints, ports, network policy, and dependency reachability. “Add more nodes” is not a diagnosis.

Domain 2: build AI retrieval on operational data services

The largest domain covers Cosmos DB for NoSQL, Azure Database for PostgreSQL, pgvector, and Azure Managed Redis. Start with ordinary data operations because vector search does not erase database fundamentals.

In Cosmos DB, use a point read when the item ID and partition-key value are known. Parameterize queries and include the partition key when the access pattern allows one logical partition. Read the request charge and query metrics. Review whether the indexing policy supports filters and ordering. Select consistency from the application's correctness requirements: Session is often a useful starting point for user-scoped read-your-writes behavior, but it is not a universal answer.

For vector search, define a vector embedding policy and compatible index before loading a production corpus. Store the source record and embedding together when that model simplifies consistency. Query with VECTORDISTANCE, use TOP N to bound results, and apply trusted metadata or partition filters. Microsoft warns that omitting TOP N can increase the number of returned results, RU cost, and latency. Evaluate source recall before blaming the generation model.

The Cosmos DB change feed processor is useful when new or updated records should drive embedding, projection, or notification work. Its lease container records progress and coordinates ranges among hosts. Use a stable processor name and make the handler idempotent because failures can lead to reprocessing. An in-memory list of processed IDs does not survive a restart and cannot coordinate replicas.

PostgreSQL with pgvector offers a different shape: vector types and distance operators live beside relational columns, transactions, joins, and trusted metadata filters. A RAG table can enforce tenant, product, language, date, and approval predicates in SQL before returning nearest chunks. Benchmark exact search first on a representative dataset, then evaluate HNSW, IVFFlat, or other currently supported indexes. Compare recall, p95 latency, build time, memory, index size, updates, and filtered-query behavior. No index is automatically best for every workload.

Connection optimization is part of AI-200 because container scaling can overwhelm PostgreSQL. If each of 30 replicas owns a pool of 20, the theoretical demand is 600 connections before migrations, monitoring, or administration. Bound the per-replica pool and maximum replica count, use timeouts, release connections promptly, and evaluate PgBouncer where appropriate. Observe the system during cache misses and bursts, not only during a calm happy path.

Azure Managed Redis supports low-latency state close to application execution. AI patterns include normal key-value caching, session state, semantic caching, memory, vector similarity, and hybrid filtering. A safe cache key must include authorization and freshness dimensions such as tenant, model or embedding version, retrieval policy, and corpus version. Set expiration, define explicit invalidation, and test eviction. Caching every answer forever creates stale responses and may cross identity boundaries.

Domain 3: Functions, Service Bus, Event Grid, retries, and DLQs

Azure Functions triggers define how a function runs; bindings declaratively connect supported inputs and outputs. They reduce SDK plumbing but do not remove validation, authorization, retry awareness, idempotency, or tests. Know when a binding is sufficient and when direct SDK control is needed for sessions, advanced settlement, transactions, or detailed client configuration.

Use a Service Bus queue when one processing group should handle each command. Use a topic when independent subscribers—perhaps extraction, audit, and notification—each need a durable copy. Subscription filters reduce irrelevant messages. Sessions can preserve ordered related streams when the requirement truly needs them, but they add coordination and should not be selected merely because the word “order” appears in a business scenario.

Peek-lock processing requires explicit settlement. Complete after successful durable side effects. Abandon or allow a bounded retry for transient failure. Dead-letter permanent payload failures with useful reason and description. Keep handler duration, lock duration and renewal, concurrency, and idempotency aligned. If processing continues after the lock is lost, another worker can receive the message and duplicate an effect.

Every Service Bus queue and topic subscription has a dead-letter subqueue. It is not automatically emptied. Operators should alert on DLQ count and age, inspect DeadLetterReason and DeadLetterErrorDescription, correct or quarantine the payload, authorize replay, resubmit safely, and explicitly settle the dead-letter message. A replay button without a policy can recreate the original incident at scale.

Event Grid is optimized for routing discrete events. Filter storage events by type and subject prefix or suffix so a workflow receives only approved new PDFs, for example. Advanced filters can evaluate event data. Event Grid retries failed delivery and can send undeliverable events to a dead-letter destination when configured. Its handlers must still be idempotent because at-least-once delivery means duplicates can occur.

Domain 4: identity, secrets, configuration, and telemetry

Managed identity should be the default starting point for Azure-hosted applications. A Container App or Function can obtain a Microsoft Entra token without storing an application credential, and Azure RBAC limits what that identity can do. Separate runtime, deployment, and dead-letter replay duties. A worker that receives from one subscription should not automatically administer the namespace or read every secret in a vault.

Key Vault protects secrets, keys, and certificates that still need to exist. Grant the narrow data-plane role, restrict the network when required, define expiry, and test rotation. Avoid pinning a version unless the rollout deliberately manages versions. If the application caches a secret forever, rotation will not take effect. Never log old and new values to “verify” rotation.

Azure App Configuration is for non-secret settings and feature flags: retrieval count, similarity threshold, cache TTL, model routing, retry category, or an emergency feature switch. Use prefixes and labels to separate applications and environments. Use provider caching and controlled refresh rather than making a configuration call on every API request. Key Vault and App Configuration complement each other; they are not interchangeable stores.

OpenTelemetry, Azure Monitor, KQL, and troubleshooting

Distributed AI back ends need traces, metrics, and logs. Instrument supported runtimes with the Azure Monitor OpenTelemetry distribution or exporter. Propagate W3C trace context across HTTP and Service Bus application properties so an upload, Function, container worker, model call, Redis lookup, and database request appear in one operation.

Use custom spans where automatic instrumentation lacks business stages, but keep attributes bounded. Revision, cache outcome, operation ID, dependency type, embedding version, and retrieval count can be useful. Raw documents, secrets, access tokens, full prompts, and unbounded user IDs can create privacy, cost, and cardinality problems. Sampling is another trade-off: control volume while retaining enough failure evidence.

Application Insights transaction diagnostics and application map show individual and system-level behavior. Kusto Query Language (KQL) turns telemetry into investigations. Start with a time window, filter by operation or revision, summarize p95 latency and failure counts by dependency, and compare cache-hit to cache-miss paths. Join or correlate broker, container, and database evidence only when the shared fields are trustworthy.

Consider a feedback-loop failure: Redis becomes unavailable, every request hits pgvector, PostgreSQL connections spike, latency rises, and Container Apps adds replicas. Each replica opens another pool, so the database slows further. The correct response begins with correlated evidence and bounded concurrency—not unlimited replicas. Traces show the miss path, metrics show connection pressure, KQL compares revisions, and scaling plus pool limits stabilize the system while the root cause is fixed.

Two portfolio projects that cover the blueprint

The first AI-200 portfolio project is a containerized RAG backend. Build the image through ACR, deploy a digest to Container Apps, canary a revision, retrieve tenant-scoped chunks from PostgreSQL pgvector, cache safe repeat work in Azure Managed Redis, and coordinate replica bounds with database pools. Add managed identity, Key Vault, App Configuration, OpenTelemetry, KQL, load tests, cost analysis, and deletion.

The second project is an event-driven AI document platform. Filter BlobCreated events through Event Grid, enter a Function, publish commands to a Service Bus topic, fan out through subscriptions, scale a container worker with KEDA, persist state and vectors in Cosmos DB, and build a change-feed projection. Inject duplicates, malformed payloads, lock loss, endpoint failure, quota errors, and DLQ replay. The project is complete only when one document can be traced end to end and every poison path has an owner.

Both projects use synthetic or public data. That is intentional. A portfolio should demonstrate architecture, code, testing, security, and operations without exposing employer documents, customer prompts, production endpoints, or real secrets.

An eight-to-twelve-week AI-200 study plan

1. Weeks 1–2: read the blueprint, build an ACR image, deploy it to App Service and Container Apps, and diagnose deliberate port, probe, image pull, and setting failures.
2. Weeks 3–4: practice Container Apps revisions, canary traffic, HTTP and Service Bus KEDA scaling, and basic AKS manifests plus logs and events.
3. Weeks 5–6: implement Cosmos DB point reads, partition queries, indexing and consistency experiments, vectors with TOP N, and a lease-backed change feed processor.
4. Weeks 7–8: build PostgreSQL pgvector retrieval, benchmark indexes and filters, add bounded pooling, then add Azure Managed Redis TTL and invalidation.
5. Weeks 9–10: build Functions, Service Bus queues/topics, filters, settlement, retries and DLQs, plus Event Grid filters and dead-letter recovery.
6. Weeks 11–12: add managed identity, Key Vault rotation, App Configuration refresh, OpenTelemetry, Azure Monitor, KQL, load and failure tests, cost review, and cleanup.

Use 25 original AI-200 practice questions to find weak reasoning, not to memorize option positions. Use 25 AI-200 flashcards for active recall. After every wrong answer, open its official reference and explain why each distractor fails the scenario.

Preparation mistakes to avoid

• Studying only model APIs. The blueprint emphasizes back-end cloud components, not one AI provider.
• Deploying mutable image tags. Keep a digest and a tested rollback artifact.
• Scaling without downstream budgets. Replicas multiply connection pools and quota consumption.
• Treating vector search as magic. Evaluate chunking, metadata filters, index recall, latency, and cost separately.
• Using a cross-partition query for a known item. Prefer point reads when ID and partition key are known.
• Assuming retries mean exactly once. Service Bus and Event Grid handlers need idempotent effects.
• Ignoring the DLQ. It needs alerts, an owner, inspection, a replay policy, and explicit settlement.
• Putting every value in Key Vault. Use App Configuration for non-secrets and feature flags.
• Logging full prompts and documents. Observability data can become a sensitive duplicate store.
• Keeping labs running. PostgreSQL, Redis, messaging tiers, private networking, and telemetry can accrue cost while idle.

Official references

• Microsoft Learn: Study guide for Exam AI-200
• Azure Container Registry Tasks overview
• Configure a custom container for Azure App Service
• Azure Container Apps revisions
• Azure Container Apps scaling and KEDA
• Vector search in Azure Cosmos DB for NoSQL
• Cosmos DB change feed processor
• Use pgvector in Azure Database for PostgreSQL
• Vector embeddings and vector search in Azure Managed Redis
• Azure Functions triggers and bindings
• Azure Service Bus dead-letter queues
• Azure Event Grid delivery and retry
• Azure Key Vault best practices
• Azure App Configuration best practices
• Configure Azure Monitor OpenTelemetry

Continue across all PrepKloud surfaces

• AI-200 five-phase roadmap
• AI-200 original practice questions
• AI-200 flashcards
• AI-200 portfolio projects
• Cloud and AI jobs board
• Technology career paths
• All certification roadmaps
• All PrepKloud guides
• PrepKloud editorial policy

Frequently asked questions