AI-200 Developing AI Cloud Solutions on Azure Exam Topics and Questions

Containers are where this exam starts, and the breadth here is deliberate. You are expected to move fluently across the full stack: building and storing images, running them on managed platforms, and operating them at scale under an orchestrator. The gaps that trip candidates up are usually operational, not conceptual. Knowing what Azure Container Registry does is not enough; you need to know what breaks at runtime and how to find it.

– Building and managing container images

Azure Container Registry (ACR) is the anchor for this group. You need to know how images move through ACR: tagging and versioning conventions, how repositories are structured, and what geo-replication and retention policies affect at scale. ACR Tasks is the part candidates underestimate. Tasks let you build images in the cloud without a local Docker daemon, trigger builds on base-image updates, and chain multi-step workflows. The exam tests whether you know when to use a quick task versus a scheduled or triggered task, and what configuration each requires. The distinction between building an image and running it inside a Task step matters here: these are not the same thing, and confusing them leads to wrong choices on configuration questions.

– Hosting containers on App Service and Container Apps

Azure App Service supports single-container workloads and is often the right answer when the scenario is a web application with no orchestration requirement. The testable detail is how App Service consumes secrets and environment variables: whether a value comes from a Key Vault reference, a direct app setting, or a container environment variable changes the answer to configuration questions. Azure Container Apps sits in the middle ground between App Service and full Kubernetes. Revision management is the mechanism that controls traffic splitting and rollback, and the exam expects you to know how revisions are activated and deactivated. Event-driven scaling through KEDA is a frequent topic: you need to understand what a scaler is, what triggers it, and how scaling rules are defined in a Container App environment, not just that KEDA exists.

– Orchestration, AKS, and observability

Azure Kubernetes Service questions almost always arrive in the form of a manifest file scenario. You are expected to read a YAML fragment and identify what is missing, misconfigured, or inconsistent with the stated requirement. Deployments, Services, ConfigMaps, and resource limits are the objects that appear most often. Knowing the imperative kubectl commands is useful for troubleshooting questions, but the exam leans on declarative manifests. Monitoring and troubleshooting spans both AKS and Container Apps. Log streams, container logs from kubectl or the Azure portal, and Azure Monitor integration are all in scope. End-to-end connectivity questions test whether you can reason about what a pod can and cannot reach, given a network policy or a missing service definition. The observability sub-topic ties directly to Topic 4, so the skills compound.

How Develop containerized solutions on Azure is tested

Items in this topic are scenario-driven and technical. A typical item gives you a partial configuration, a deployment requirement, and asks you to complete or correct it. The demand is precision: candidates who understand concepts but cannot map them to specific Azure resource properties lose marks on the configuration details. KEDA scaling rules and Container Apps revision modes are common sources of errors because they involve multiple interacting settings. AKS manifest questions reward candidates who can read YAML and reason about what a given spec will actually do at runtime, not just what it is intended to do. Troubleshooting items test log inspection and connectivity reasoning: you are expected to know which tool surfaces which information and what a given log entry implies about the system state. Candidates who prepare only the happy-path deployment flows and skip the monitoring and revision management sub-topics tend to lose marks in clusters, because several items share the same underlying concepts.

From containers, the exam moves into the data layer that AI workloads actually depend on. This topic is wider than it looks: three distinct services, each with its own SDK, indexing model, and vector search story. The AI angle is not decorative. Embeddings, semantic retrieval, and retrieval-augmented generation (RAG) patterns are first-class exam content here, not background context. Where candidates lose marks is in treating each service as a generic database and missing the AI-specific configuration decisions.

– Cosmos DB for NoSQL: querying, consistency, and vectors

Connecting to Cosmos DB via the SDK and running queries is the baseline. The exam goes further by testing whether you know how indexing policies affect which queries are efficient and which trigger a full scan, and how consistency levels change the trade-off between read latency and data freshness. These two levers interact: a query that performs well at one consistency level may become expensive at another. The vector search sub-topic is specific to AI workloads. Storing embeddings in Cosmos DB and executing a vector similarity search requires knowing how to configure the vector index policy, what distance metrics are available, and how semantic retrieval differs from a standard filter query. Change feed processor questions test whether you understand the lease container model and how a processor instance handles partitions when the item count grows.

– PostgreSQL: schema, indexing, and vector workloads

Azure Database for PostgreSQL brings a relational model into the AI data story. Schema design and data type choices matter here because the wrong type for an embedding column, or a missing index, has measurable performance consequences. The pgvector extension is the mechanism for storing and querying embeddings, and the exam tests the compute overhead that comes with approximate nearest-neighbour indexes at scale. Reducing that overhead is a configuration problem: index type, lists parameter, and probes setting are all levers. Query latency optimisation and the choice between exact and approximate search are testable distinctions. RAG pattern questions in this service context ask you to combine vector similarity search with metadata filters, which means understanding how a WHERE clause interacts with an index scan on a pgvector column. Connection optimisation, including PgBouncer configuration, is in scope because throughput and latency under AI workloads are sensitive to connection pool settings.

– Azure Managed Redis: caching, expiration, and vector indexing

Redis in an AI solution is primarily a cache and a vector index. The exam tests the operational side: setting expiration policies, understanding cache invalidation strategies, and knowing when a cache miss has a functional consequence rather than just a performance one. Vector indexing in Redis uses a different model than Cosmos DB or pgvector. You need to know how to define a vector field in a Redis index, what search commands are used for similarity queries, and how the index interacts with key expiration. Candidates who know Redis only as a key-value store and skip the vector indexing sub-topic are exposed to a cluster of items they cannot answer confidently. The integration angle matters too: Redis in an AI pipeline is often a semantic cache layer sitting in front of a more expensive retrieval call, and the exam expects you to reason about where it fits in that chain.

How Develop AI solutions by using Azure data management services is tested

This topic produces some of the most technically layered items in the exam. Many items present a performance or correctness problem in an AI pipeline and ask you to identify the configuration change that resolves it. The trap is that the same symptom, for example slow retrieval, can have different root causes depending on which service is in scope: an indexing policy in Cosmos DB, a pgvector index parameter in PostgreSQL, or a missing expiration policy in Redis. Items reward candidates who can distinguish between these causes and apply the right fix to the right service. Vector search items are particularly demanding because they require you to reason about both the data model and the query pattern at the same time. RAG pattern questions test whether you understand the retrieval step well enough to configure it correctly, not just name it. Candidates who treat the three services as interchangeable lose marks on items where the service-specific detail is exactly what changes the answer.

Once data is handled, the exam turns to the integration layer: how AI workloads communicate, trigger work, and expose functionality. This topic covers messaging, eventing, and serverless compute. The sub-topic count is smaller than the previous two, but the depth per area is significant. Candidates who have worked mainly with synchronous REST APIs can find the asynchronous and event-driven patterns here less intuitive, and that unfamiliarity shows in the results.

– Messaging and event-driven workflows

Azure Service Bus and Azure Event Grid serve different purposes, and the exam tests whether you know which to reach for given a scenario's requirements. Service Bus is for reliable, ordered, or transactional message delivery. The dead-letter queue is a specific testable mechanism: you need to know under what conditions a message lands there, how to inspect it, and how to reprocess or abandon it. Topics and subscriptions add filtering to the delivery model, and the exam expects you to configure subscription filters, not just describe the architecture. Event Grid is for reactive workflows where a publisher does not need to know who is listening. Custom events, event filters, and retry policies are all in scope. The key distinction the exam probes is durability and ordering guarantees: Event Grid and Service Bus make different promises, and choosing the wrong one for a given scenario is a common error.

– Azure Functions: triggers, bindings, and deployment

Azure Functions questions are grounded in practical implementation. Triggers define what starts a function; bindings define how it reads input and writes output without explicit SDK calls. The exam tests whether you can match a trigger type to a scenario requirement and whether you understand what a binding declaration looks like in code or configuration. Service Bus triggers and Event Grid triggers appear often, which ties this group directly to the messaging group above. Building a serverless API means understanding HTTP triggers, route configuration, and authorization levels. Function app configuration and deployment covers application settings, deployment slots, and the distinction between consumption and premium plan behaviours that affect scaling and connectivity. Candidates who know triggers conceptually but have not worked through binding configuration in practice tend to miss items that hinge on the exact shape of a binding definition.

How Connect to and consume Azure services is tested

Items in this topic often present an integration requirement, such as a downstream system that must process messages in order, or a workflow that must react to a blob upload, and ask you to select or complete the correct configuration. The demand is matching the right service and the right configuration to the stated guarantee. Dead-letter queue items reward knowing the specific conditions that trigger dead-lettering in Service Bus, not just that the mechanism exists. Event Grid items test filter syntax and retry behaviour in scenarios where events are being dropped or duplicated. Functions items frequently combine a trigger with a binding in the same scenario, so you need to reason about both at once. Candidates who prepare messaging and eventing as separate silos and do not practise scenarios that cross both services tend to lose marks on items that require you to connect the two. Deployment configuration questions reward knowing which settings are environment-specific and which are shared across slots.

Security and observability are where the exam tests whether you can operate a solution, not just build one. After three topics of construction, this one asks what happens when something goes wrong or when a credential needs to change without downtime. The skills here are cross-cutting: Key Vault references appear in container configurations from Topic 1, and log analysis connects directly to the troubleshooting sub-topics you saw there too. Candidates who treat this topic as a standalone unit miss the way its items reference the full solution stack.

– Secrets, configuration, and secure access

Azure Key Vault is the standard answer for secrets management, but the exam goes past the concept. Secret rotation is the operational detail that generates the most errors: you need to know how an application retrieves a rotated secret without a redeploy, which means understanding Key Vault references in App Service settings, managed identity access policies, and the difference between a secret version and the current version pointer. Azure App Configuration sits alongside Key Vault for non-secret settings: feature flags, environment-specific values, and configuration snapshots. The exam tests retrieval patterns and how App Configuration integrates with the configuration pipeline of a function app or container. Confusing what belongs in Key Vault versus App Configuration is a reliable source of wrong answers, because the services are complementary rather than interchangeable.

– Distributed tracing and log analysis

OpenTelemetry is the observability standard the exam expects you to work with. The testable content is practical: how you instrument an application to emit traces and spans, how context propagation works across service boundaries, and what a broken trace looks like when propagation fails. Distributed tracing questions often involve a multi-service AI pipeline, which connects back to the architectures in Topics 2 and 3. KQL is the query language for Azure Monitor Logs and Application Insights. The exam does not expect you to write complex analytical queries from scratch, but it does expect you to read a KQL fragment, understand what it returns, and identify what change would produce a different result. Filtering by time range, joining tables, and summarising by a field are the operations that appear most often. Candidates who have not practised KQL at all find these items disproportionately difficult relative to the time available.

How Secure, monitor, and troubleshoot Azure solutions is tested

Items in this topic tend to be diagnostic: a scenario describes a symptom, and you must identify the cause and the fix. Secret rotation items reward knowing the exact retrieval mechanism an application uses and where in that chain a stale value gets cached. App Configuration items test whether you understand the SDK's refresh model and what triggers a configuration reload at runtime. OpenTelemetry items reward candidates who understand context propagation, because a missing trace correlation in a distributed system is a specific failure with a specific fix. KQL items present a query and a data set description, then ask what the query returns or what change produces the desired output. The trap in KQL items is misreading the operator precedence or the filter scope. Candidates who skip KQL practice and rely on general log-reading experience often find the syntax precise enough to cause errors under time pressure. Combining security and observability knowledge in a single scenario is common, so preparation across both sub-groups pays off.