Microsoft AI-200: A Hands-On Study Plan
AI-200 validates the Azure AI Cloud Developer Associate role. The AI-200 exam currently covers containerized solutions on Azure, AI solutions using Azure data management services, Azure messaging and eventing, Azure Functions, and the security, monitoring, and troubleshooting practices needed to operate those applications.
The best study plan is one production-style application that grows each week. Microsoft expects Python proficiency, Azure SDK familiarity, vector databases, data services, containers, messaging, monitoring, and security. Connecting those skills in one system is more useful than completing separate tutorials for every service.
Week 1: build and containerize a small API
Create a Python API, build a container image, publish it to Azure Container Registry, and run it on a managed Azure container platform. Practice configuration, environment variables, logs, revisions, and scaling.
Then break the image or startup configuration. Diagnose whether the failure belongs to the container, registry access, application configuration, or platform. The exam expects developers who can operate what they deploy.
Week 2: compare Container Apps, App Service, and AKS
Deploy the same simple application to more than one hosting option and compare operational control, scaling, networking, deployment complexity, and observability. Do not assume the most flexible platform is the best answer.
The internal Azure Container Apps deployment article can support this phase. Use hands-on comparison to understand when a managed container platform is enough and when a Kubernetes requirement is real.
Add ingress, scaling, secret access, and revision behavior to the comparison. A platform can be easy to deploy yet unsuitable if the application needs a network or scheduling capability it does not provide.
Observe what the developer must operate in each model. AKS exposes more control and more responsibility; managed application platforms reduce some infrastructure work. The exam rewards choosing the right level of control.
Week 3: build vector retrieval with Cosmos DB
Create a small dataset, generate embeddings, store them, build a vector index, and perform similarity search with metadata filtering. Observe how indexing and consistency decisions affect request units, latency, and retrieval behavior.
Add a change-feed processor so downstream work reacts to new or updated items. This connects AI retrieval to normal application data engineering and helps you understand why vector search is one capability inside a broader database design.
Create a small evaluation set for retrieval quality. Record which records should appear for each query, then change indexing or metadata filters and see whether the result improves.
This prevents vector search from becoming magic. Retrieval is a database behavior that can be measured, optimized, and debugged like other application dependencies.
Week 4: repeat retrieval with PostgreSQL and Redis
Use Azure Database for PostgreSQL with pgvector and compare schema, indexing, vector search, throughput, and connection management with the Cosmos DB design. Then use Azure Managed Redis for caching or vector indexing where the workload fits.
The Azure PostgreSQL material can refresh relational-service concepts. Your goal is to choose the data platform from access pattern and operational requirements rather than from familiarity.
Test connection behavior under load. PostgreSQL connection limits and pooling can become bottlenecks before the query itself is slow. Compare persistent connection management with application patterns that open a new connection per request.
For caching, define invalidation and expiry clearly. A fast cache serving stale or unauthorized data is not an improvement. Cache design should include how data becomes fresh and how user or tenant boundaries are preserved.
Week 5: add messaging and event-driven work
Put slow or retryable processing behind Azure Service Bus and use topics or subscriptions where multiple consumers need the same event. Add a dead-letter path and make the consumer idempotent.
Then create an Event Grid workflow for lightweight event notification. Compare queueing, pub/sub messaging, and event-driven notification so you can explain which pattern fits reliability, fan-out, ordering, and retry requirements.
Test duplicate delivery and consumer restart. The application should not create duplicate business actions when a message is retried. Idempotency is part of reliable cloud development.
Monitor queue age and dead-letter volume, not only total message count. A small queue containing old stuck work can be more serious than a large burst that is draining normally.
Week 6: use Azure Functions for focused serverless work
Build a function with an HTTP or event trigger and connect it to one data or messaging dependency. Configure the function app, deployment, secrets, and logging.
Do not make every application serverless. Use the lab to understand event-driven and short-lived workloads, then compare them with always-running containerized services. Architecture choice should follow workload behavior.
Add retry and poison-message handling to an event-triggered function. Serverless code still needs idempotency, observability, and a recovery strategy when downstream dependencies fail.
Compare cold-start and scaling behavior with the user requirement. A function may be operationally simple but unsuitable if response latency must remain extremely consistent under infrequent traffic.
Week 7: design identity and secrets correctly
Use Microsoft Entra identities and Azure Key Vault rather than embedding credentials. Give the application only the permissions it needs to reach data, messaging, or configuration services.
The Entra ID and Azure RBAC article is useful because authentication and authorization are separate. Test a valid identity that still receives an authorization denial and fix the scope rather than replacing it with a broad role.
Add Azure App Configuration for non-secret settings and Key Vault for secrets or keys. Separating configuration from credentials makes environment promotion safer and reduces the chance that sensitive values end up in source control.
Rotate one secret or credential and verify the application continues to operate through the intended mechanism. Security controls are only useful when lifecycle operations are tested.
Week 8: trace the request with OpenTelemetry and KQL
Add distributed tracing and structured logs so one user request can be followed through the API, data store, message, function, and downstream service. Write KQL queries to find errors and latency spikes.
Measure performance before optimizing. A slow user experience may be caused by vector retrieval, database connections, messaging backlog, model or downstream service latency, or application code. Observability should tell you which component owns the delay.
Create one KQL query for errors, one for latency, and one for dependency failures. Then correlate the same request across traces and logs. This builds the exact habit needed when several Azure services participate in one user-visible failure.
Add an alert only after you know what action follows. Monitoring becomes useful when a signal has an owner, severity, and response path rather than simply generating more notifications.
Use adjacent certifications to keep the role boundary clear
The AI-103 exam goes deeper into Azure AI apps and agents. AI-200 stays broader around cloud application development, data services, messaging, containers, security, and monitoring.
The AI-300 exam focuses on MLOps and GenAIOps. It becomes relevant when your responsibility shifts from building the application to operationalizing models and generative AI systems at scale.
The AI-901 exam is fundamentals-level context. Use it only to close concept gaps quickly; most AI-200 preparation should be code, deployment, data, identity, messaging, monitoring, and troubleshooting.
AI-200 candidates should also keep standard cloud-development habits visible: API contracts, tests, retries, security, configuration, versioning, and observability. AI features should be added to a sound application rather than used as an excuse to ignore software-engineering fundamentals.
When a lab becomes mostly about model evaluation, agent orchestration, or production ML lifecycle, note that you have crossed into AI-103 or AI-300 territory. That boundary helps keep AI-200 preparation broad enough for the developer role without becoming unfocused.
Exam week: rebuild one end-to-end application.
Recreate the smallest version of your project from source control: container, data service, vector retrieval, messaging or eventing, one function, secure identity, configuration, and telemetry. Break one dependency and recover it.
The Microsoft certification inventory can help map the wider AI family. Your AI-200 readiness should be visible in a working cloud application whose architecture and failure behavior you can explain from request to data to telemetry.
Write a one-page architecture note with component, responsibility, identity, data flow, failure behavior, and telemetry. If a component cannot be described in those terms, revisit it.
A cloud developer is valuable because they can connect code with platform behavior. The final project should prove that the application can be deployed, secured, observed, and recovered—not only executed locally.
Add a short postmortem after the deliberate failure. Record what broke, which telemetry revealed it, how recovery worked, and what design change would make the same issue easier to prevent or diagnose next time.
That habit ties development to operations and is a strong final check for AI-200: the application should not only work, it should be supportable by someone who was not present when you built it.
Keep the rebuild small enough to finish in one sitting, but complete enough that identity, data, messaging, deployment, and telemetry all participate. That is a better readiness signal than another disconnected tutorial.
If every component has a clear responsibility and failure path, the study plan is aligned with the role.
- Category: All Certifications Certifications
