Skip to content

Case studies ​

The real AI-200 exam includes case studies: a single scenario described up front, followed by several questions that test whether you can apply the concepts in context. Read the scenario, then answer the linked questions; the scenario stays on screen the whole time.

📋 Contoso — containerized inference APID1 · Containerized solutions
Scenario

Contoso runs an AI inference API packaged as a container image. Images are built in CI and stored in an Azure Container Registry (Premium) named contosoacr. A separate base image is patched frequently for OS security updates.

The API is hosted on Azure Container Apps. Most traffic is HTTP, but a companion background worker processes jobs from an Azure Service Bus queue and is idle for hours overnight. The team also runs a latency-sensitive variant on Azure Kubernetes Service (AKS) that loads a 2 GB model into memory on startup, taking about 40 seconds before it can serve requests.

Security requires that no registry usernames or passwords are stored anywhere in the apps.

📋 Fabrikam — RAG knowledge baseD2 · Data management services
Scenario

Fabrikam builds a retrieval-augmented generation (RAG) assistant over a large product knowledge base. Documents and their 3,072-dimension embeddings are stored together in Azure Cosmos DB for NoSQL, partitioned by /tenantId for a multitenant SaaS product.

A separate analytics workload uses Azure Database for PostgreSQL flexible server with pgvector for cosine-similarity retrieval. An Azure Managed Redis instance caches model responses to identical prompts.

Under load, the team sees occasional HTTP 429 responses from Cosmos DB, and they need new or updated documents to be embedded and indexed automatically as they arrive.

📋 Tailwind — order processing pipelineD3 · Connect & consume services
Scenario

Tailwind Traders processes online orders through an event-driven pipeline. When an order is placed, a single order event must be handled independently by an inventory service and a billing service.

Messages for the same order must be processed strictly in sequence. Orders that repeatedly fail processing must not block the pipeline. Downstream work runs in Azure Functions, which must persist a record to Cosmos DB with minimal code.

A separate reactive workflow reacts to Azure Blob Storage events, but only for files uploaded under /invoices/ ending in .pdf, and the subscriber endpoint occasionally goes offline for maintenance.

📋 Northwind — securing & observing the platformD4 · Secure, monitor, troubleshoot
Scenario

Northwind runs a containerized AI platform on Azure. Application secrets and a third-party API key live in Azure Key Vault (configured with the Azure RBAC permission model). Shared configuration and feature flags are managed centrally in Azure App Configuration.

Services are instrumented with OpenTelemetry exporting to Application Insights. The team analyzes logs and metrics in a Log Analytics workspace with KQL.

Two microservices currently appear as a single node on the Application Map, and users intermittently get HTTP 500s that the team must root-cause. A new feature must be rolled out to specific pilot users and to 20% of a beta group.

📋 Adatum — agent platform on AKSMixed · Cross-domain
Scenario

Adatum hosts a multi-agent AI platform on Azure Kubernetes Service. Agent images are built and patched in Azure Container Registry. Each agent pod must read secrets from Azure Key Vault and pull images from ACR, and the security team forbids any stored credentials or connection strings anywhere.

Agents retrieve context from a vector store in Azure Cosmos DB for NoSQL and enqueue long-running tool calls onto an Azure Service Bus queue, processed by an Azure Functions app. The whole platform is instrumented with OpenTelemetry exporting to Application Insights.

During a traffic spike the team sees Cosmos DB HTTP 429s, Service Bus messages being redelivered, and two services collapsing into one node on the Application Map.

📋 Litware — serverless document intelligenceMixed · Cross-domain
Scenario

Litware ingests uploaded contracts into Azure Blob Storage. Each upload must trigger a serverless pipeline that extracts text, generates embeddings, and stores them for retrieval. The pipeline is built on Azure Functions and reacts to Blob Created events through Azure Event Grid.

Embeddings and chunks are stored in Azure Database for PostgreSQL flexible server using pgvector for cosine-similarity retrieval. A third-party document-AI API key is required and must never appear in source control or images. Configuration and feature flags (such as enabling a new extraction model) are managed centrally and must update without redeploying.

Occasionally the document-AI endpoint returns HTTP 429, and the Event Grid subscriber is briefly unavailable during deployments.

📋 Wingtip — GPU inference on AKSD1 · Containerized solutions
Scenario

Wingtip serves a large vision model from GPU nodes on Azure Kubernetes Service. Container images are built and patched in Azure Container Registry, and the security team forbids stored registry credentials.

Each pod loads a 2 GB model into GPU memory and needs roughly 40 seconds before it can serve requests. A nightly batch-scoring workload is cost-sensitive and can tolerate interruption. A separate worker scales on the depth of an Azure Service Bus queue.

Production manifests must guarantee that every node pulls the exact same image bits, even if someone later re-pushes a tag.

📋 Proseware — multi-store vector retrievalD2 · Data management services
Scenario

Proseware powers a RAG assistant. Documents and their 3,072-dimension embeddings live in Azure Cosmos DB for NoSQL, partitioned by /tenantId. An analytics path uses Azure Database for PostgreSQL with pgvector for cosine retrieval, and Azure Managed Redis caches identical-prompt responses.

Under peak load Cosmos DB returns HTTP 429. Some workflows must update several items for one tenant atomically.

The Redis cache should expire entries after an hour, and the team is unsure why keys without a TTL never get evicted under memory pressure.

📋 VanArsdel — event-driven ingestionD3 · Connect & consume services
Scenario

VanArsdel ingests millions of IoT telemetry events per second for real-time analytics and later replay. Separately, when an order is placed, the event must be processed independently by an inventory service and a billing service.

Order messages that repeatedly fail must not block the pipeline. Downstream processing runs on Azure Functions, which must scale to zero between bursts yet reach backend resources over a virtual network.

A document workflow reacts to Azure Blob Storage events but only for files under /invoices/ ending in .pdf, and the subscriber endpoint is briefly offline during deployments.

📋 Fourth Coffee — zero-trust secrets & observabilityD4 · Secure, monitor, troubleshoot
Scenario

Fourth Coffee runs a containerized AI platform. Secrets and a rotated third-party API key live in Azure Key Vault (Azure RBAC permission model); shared configuration and feature flags are centralized in Azure App Configuration.

Services export OpenTelemetry to Application Insights and are analyzed in Log Analytics with KQL. Two microservices currently appear as one node on the Application Map.

A new feature must be enabled for a set of pilot users and 20% of a beta group, and the team needs the 95th-percentile request duration per operation.

📋 Woodgrove Bank — containerized document scoringD1 · Containerized solutions
Scenario

Woodgrove Bank runs DocScore, an ASP.NET Core minimal API service that classifies scanned loan documents. It ships as a Linux custom container built by Azure Container Registry Tasks and currently runs on Azure App Service. The service reads a database password and a model API key that both live in Azure Key Vault, and the platform team has removed all registry admin credentials from the app configuration.

The team is migrating DocScore to Azure Container Apps. The target environment is injected into a custom virtual network that uses Woodgrove's own DNS servers rather than Azure-provided DNS. Bank policy states that test and production workloads must never share compute resources or a virtual network. Support engineers also need to trace an individual customer complaint from the ingress layer down to the application's own log lines.

Compliance requires that every deployed image be traceable to the build that produced it, and that accidental registry deletions remain recoverable. Observability for both the current App Service deployment and the new Container Apps deployment must be queryable with KQL.

📋 Kestrel Freight — shipment document assistantD2 · Data management services
Scenario

Kestrel Freight runs a .NET back end on Azure Container Apps that answers questions about shipment paperwork. Scanned documents are normalized into an Azure Cosmos DB for NoSQL container named documents, partitioned by /customerId. A separate .NET worker uses the change feed processor in latest version mode against documents, with a leases container in the same database; its delegate calls Azure OpenAI to create embeddings and writes them back to a /contentVector property on each item.

The container holds roughly 4 million vectors of 1,536 dimensions and uses the cosine distance function. Every retrieval query filters on customerId first, but a single large customer can own several hundred thousand documents. An Azure Managed Redis instance on the Balanced tier — created without the RediSearch module — caches assistant answers keyed by a hash of the prompt.

Three incidents are open. A bug in the chunking code means every document must be re-embedded from the beginning of the container's history. A vector query shipped last week caused a large request unit spike. And cache reads intermittently time out when a cached answer embeds a document excerpt of several megabytes, even though the instance's CPU and memory metrics stay low.

📋 Meridian Freight — AI document intake pipelineD3 · Connect & consume services
Scenario

Meridian Freight processes customs paperwork for cross-border shipments. Carriers upload scans of bills of lading, packing lists, and customs declarations; a .NET back end extracts fields with an Azure AI service and assembles a structured shipment record. The extraction and assembly stages run as C# isolated-worker functions in an Elastic Premium plan, connected by an Azure Service Bus namespace on the Standard tier. Each uploaded page becomes one message, and the pages of a single shipment must be assembled in the order the carrier submitted them, while different shipments are assembled concurrently. Today the assembly queue has no sessions and the team regularly sees pages stitched together in the wrong order once the app scales past one instance.

Downstream teams — billing, customer notifications, and a fraud-scoring model — each want to react to business milestones such as ShipmentAssembled and DeclarationRejected. Meridian does not want the assembly function to call each consumer directly, and the platform team has standardised on the CloudEvents v1.0 format across the company so events can be handled by the same tooling on other clouds.

Releases are currently deployed straight to production, which terminates in-flight extractions, and the on-call rota reports two recurring problems: a small number of documents end up in the dead-letter queue with no diagnosis, and settings that work on developer laptops go missing after a publish.

📋 Lakeshore Logistics — Tracing and securing a dispatch assistantD4 · Secure, monitor, troubleshoot
Scenario

Lakeshore Logistics runs a .NET dispatch assistant on Azure Container Apps. A front-end API container answers driver questions over HTTP, and a separate worker container consumes Azure Service Bus messages, calls an Azure OpenAI deployment, and then calls an internal routing API. Both containers are instrumented with the Azure Monitor OpenTelemetry Distro and export to a single Application Insights resource. The routing API key and a third-party geocoder key are stored in Azure Key Vault; feature flags and tunable values such as retry counts live in Azure App Configuration. Both stores are read with a user-assigned managed identity.

After a release, the on-call team reports several problems. Spans the worker creates around message processing show up in the dependencies table with type InProc rather than as incoming operations, so Application Map shows no entry point for the worker. Support also needs to reconstruct exactly what happened during individual failed dispatches, and finance needs an exact count of distinct drivers affected by an outage window — an approximate number is not acceptable for the customer credit calculation.

Separately, an operations engineer published a new value for the flag Dispatch:MaxRetries in App Configuration, but all running replicas kept serving the old value indefinitely. The team's startup code calls AddAzureAppConfiguration once during container start-up and then reads values out of IConfiguration. The team also plans to turn on fixed-percentage sampling to cut telemetry cost, and wants its production alerts to remain accurate afterwards.

📋 Harbourline Logistics — containerising the tracking APID1 · Containerized solutions
Scenario

Harbourline Logistics runs a shipment tracking API that is currently deployed as a virtual machine scale set. The team is moving it to containers. The API is stateless, receives bursty traffic that falls to almost nothing overnight, and calls an Azure Cosmos DB account and an Azure Cache for Redis instance. A background worker drains an Azure Service Bus queue of carrier status updates; the queue is empty for hours at a time and then receives tens of thousands of messages within a few minutes.

Images are built by an Azure Pipelines job and pushed to an Azure Container Registry in the same region. Security requires that no registry password, Cosmos DB key or Redis key is stored in the deployment definition or in any pipeline variable. The platform team has no Kubernetes experience and has asked explicitly for the smallest operational surface that meets the requirements.

The API takes roughly 40 seconds to warm its in-process cache at start-up. During the previous release the team pushed a broken build straight to production and had no way back other than redeploying the old tag, which took eleven minutes.

📋 Meridian Health — retrieval over clinical guidance documentsD2 · Data management services
Scenario

Meridian Health runs an internal assistant that answers clinician questions from a corpus of about 900,000 chunks extracted from clinical guidance PDFs. Each chunk carries a 1536-dimension embedding from text-embedding-3-small, plus structured metadata: the specialty, the issuing body, the publication date, and a boolean marking whether the guidance is superseded.

The chunks and their metadata currently live in Azure Database for PostgreSQL flexible server, alongside the relational tables that record which documents each clinician's department has licensed. Almost every query filters on specialty and excludes superseded guidance before ranking by vector similarity. The team reports that recall is poor: for narrow specialties the assistant frequently returns nothing relevant even though matching chunks exist.

Separately, conversation transcripts are written to Azure Cosmos DB for NoSQL, partitioned by /conversationId, and a change feed processor pushes them into an analytics pipeline. The team also wants to add a semantic cache so that repeated questions do not re-run retrieval, and they have provisioned an Azure Managed Redis instance for it.

Compliance requires that no service authenticates with a shared key or password.

📋 Calderwood Utilities — smart meter ingestion and billing eventsD3 · Connect & consume services
Scenario

Calderwood Utilities collects readings from roughly two million smart meters. Each meter reports every fifteen minutes, and readings arrive as small JSON payloads over HTTPS into an ingestion tier. A .NET back end validates each reading, stores it, and raises downstream business events. The platform team has standardised on Azure Functions in the isolated worker model.

Readings from a single meter must be processed in the order the meter reported them, because a corrected reading supersedes the one before it and applying them out of order produces a wrong bill. Readings from different meters are independent and should be processed with as much parallelism as the platform allows.

Three downstream teams — billing, the customer mobile app, and a fraud model — need to react to business milestones such as ReadingValidated and TamperSuspected. Each team wants only a subset of these, filtered by event type and by region, and the team that raises the events does not want to know who the consumers are. Consumers must be able to be added without redeploying the publisher.

The analytics group separately needs the complete raw reading stream retained for thirty days so it can re-run a new model over historical data without asking the ingestion tier to replay anything.

During a recent regional incident the billing consumer was down for four hours. Nobody noticed until customers complained, and the team discovered that some events raised during the outage could not be accounted for afterwards.

📋 Aldermere Bank — securing and observing a customer assistantD4 · Secure, monitor, troubleshoot
Scenario

Aldermere Bank runs a customer-facing assistant built on an Azure OpenAI deployment, fronted by an ASP.NET Core API on Azure Container Apps and backed by a retrieval service. The platform team is preparing it for a regulated production launch and has been told that no credential may appear in application configuration, source control, or a pipeline variable.

The API currently reads an Azure OpenAI key and a database connection string from environment variables set at deployment. A third-party sentiment API key is also in use; that vendor issues keys through its own portal and there is no programmatic way to generate one.

The compliance team requires that audit logs for credential access be retained for one year, that they be searchable when an auditor asks — which happens perhaps twice a year — and that the monitoring data never traverse the public internet.

Operationally the team is struggling. During a recent slowdown they could see that requests were slow but could not tell whether the retrieval service or the model was responsible, because each service reported telemetry independently and nothing joined up. Separately, the assistant began returning errors at a steady rate one afternoon; the team eventually found HTTP 429s from the model deployment, but only after customers complained.

The team also discovered that their Application Insights counts did not match the application's own request tallies, which made them distrust the telemetry during the incident.

How to approach case studies

Read the scenario twice and note the hard constraints. Most case-study questions hinge on matching one of those constraints to the right feature.

Unofficial study hub. Content grounded in the official Microsoft Learn study guides.