Microsoft AI-102 to AI-103: Practical Transition Exercises

Moving from AI-102 to Microsoft AI-103 is easier when preparation is built around things you can actually design, implement, and diagnose. AI-102 retired in 2026, but many of its engineering foundations still matter: Azure AI services, language, vision, search, document processing, secure integration, and application development. The center of gravity has moved. The current Microsoft AI-103 expects those skills to operate inside Microsoft Foundry, generative applications, agentic workflows, retrieval pipelines, multimodal systems, and production controls.

Practical rehearsal is therefore more valuable than rereading a legacy objective list. Do not reproduce every lab you once used for Microsoft AI-102. Rebuild the durable skill underneath each lab in a scenario that exposes the decisions AI-103 now emphasizes: deployment, retrieval quality, tool authority, evaluation, safety, and observability.

The exercises below are designed for that purpose. They can be implemented in a sandbox or worked through as detailed architecture drills when a full Azure environment is not available. In either case, write down your decisions. A transition exercise is useful only if it reveals why you chose a service, permission model, retrieval pattern, orchestration boundary, or evaluation method.

Begin with one end-to-end Foundry deployment

Start by designing a small generative application that could plausibly be deployed for internal users. Give it a defined business task, a model, an application layer, and one governed source of enterprise knowledge. Then force yourself to make the production decisions around it.

Choose where the model and application are deployed. Decide how the application authenticates to Azure resources. Separate configuration from secrets. Define the network boundary. Identify which permissions are needed at each hop. Add a simple CI/CD path and write down how model, prompt, configuration, and application changes would be promoted safely.

This exercise exposes a common transition gap: candidates who can write AI code but have not treated deployment architecture as part of the AI solution. A production-ready design has to account for model endpoints, application identity, configuration, networking, deployment, quotas, and operational evidence. Those relationships are the core of Foundry deployment architecture.

Do not finish the exercise when the app returns an answer. Add a rate-limit scenario, a cost constraint, and a requirement for private access. If you cannot explain what changes, the lab has found a real study gap.

Rebuild retrieval as a pipeline you can measure

For the second exercise, add retrieval-augmented generation. Use a small collection of documents with enough overlap that retrieval quality actually matters. Define ingestion, chunking, metadata, enrichment if needed, indexing, retrieval, grounding, and generation as separate stages.

Run the same query through different retrieval choices. Compare keyword, semantic, vector, or hybrid approaches where appropriate. Change chunk size or metadata filters and observe how the evidence changes. Then create failure cases: a relevant document that ranks too low, a stale document that ranks too high, a query that retrieves nothing useful, and a response that goes beyond the retrieved evidence.

The point is to learn where a RAG failure originates. A weak answer is not automatically a model problem; it may begin in ingestion, indexing, retrieval, ranking, context selection, or grounding. Working through RAG and grounding pipelines helps separate those stages so poor evidence can be diagnosed before the generation step is blamed.

Build an agent that has useful tools but limited authority

Next, create or model an agent that can do more than answer questions. Give it two or three tools with clearly different purposes—for example, a read-only knowledge lookup, a business API, and an action that changes state. Define the schema for each tool and decide exactly which actions the agent may perform automatically.

Then add an approval boundary. A read operation may be autonomous, while an action that sends, deletes, purchases, changes access, or modifies production data may require review. Ask what identity actually executes the tool call and what happens if the model selects the wrong tool or supplies a bad argument.

This is the difference between knowing that agents can call tools and understanding agent architecture. Tool definitions, least-privilege permissions, explicit state, retries, validation, and human approval are part of the system. Strong agent orchestration and tool use keeps authority boundaries and handoffs visible instead of treating every agent workflow as a prompt problem.

Compare a deterministic workflow with a multi-agent design

Take the same business task and implement it conceptually in two ways. First, design a deterministic workflow in which steps run in a known sequence. Second, design an agentic version in which a coordinator chooses or delegates work. Do not assume the agentic version is better.

Compare them across predictability, auditability, context needs, failure recovery, cost, latency, and permissions. If the task always follows the same sequence, a rules-based workflow may be simpler and safer. If the task requires discovery, variable decomposition, or specialized reasoning, an agentic approach may add value.

Then test a multi-agent split. Give each agent a narrow responsibility and define the handoff contract. Decide what context is shared, what stays isolated, and who owns the final answer. Introduce one bad intermediate result and trace whether it contaminates the rest of the workflow. That failure exercise teaches more than building a happy-path demo.

Turn a familiar vision or language task into a multimodal application

AI-102 candidates often have strong experience with language and computer vision. Preserve that advantage, but update the exercise. Instead of calling a single service and returning a label, build a workflow in which visual, audio, or text evidence participates in a larger application.

For example, accept an image, produce an accessibility-oriented description, identify structured facts, and use those facts as context for a downstream response. Or process a short video segment, extract relevant evidence, and pass only the necessary representation to the next stage. Add a safety policy that blocks or flags a prohibited output and explain where that control should be enforced.

The objective is to move from “I know the vision service” to “I can reason about a multimodal pipeline.” If image/video generation, multimodal understanding, or cross-modal safety controls are unfamiliar, a focused review of multimodal generation and understanding is more useful than relearning every legacy vision topic.

Build an information-extraction workflow that preserves provenance

Choose a document set such as invoices, forms, policy documents, or contracts. Design the path from ingestion through OCR or content understanding to structured output. Decide how layout, fields, tables, or free-form text are represented, and preserve enough provenance to trace an extracted value back to its source.

Now connect that structured output to a search or agent workflow. The downstream component should know whether it is using an extracted fact, a generated summary, or a model inference. Add a validation step for critical fields and define what happens when confidence is low or the document does not match the expected structure.

This exercise links legacy document-processing knowledge with the current expectation that extracted information becomes clean, grounded input for later reasoning.

Add safety, evaluation, and observability before calling the system finished

Repeat one of the earlier exercises, but this time treat quality and operations as first-class requirements. Build a small evaluation set with normal cases, edge cases, unsafe inputs, and intentionally weak retrieval. Define what success means for accuracy, groundedness, safety, latency, and cost.

Add traces that let you follow a request through retrieval, model calls, tools, and downstream services. Record the signals you would use to diagnose a slow request or a low-quality answer. Decide how you would detect drift or a drop in retrieval relevance. Add a safety event and specify which team should see it and what evidence they need.

The current AI-103 blueprint makes this operational mindset unavoidable. Effective responsible AI and safety controls should be designed alongside evaluation and deployment, while monitoring and GenAIOps provide the evidence needed to diagnose quality, latency, failures, safety events, and cost in production.

For each exercise, record three forms of evidence: the decision you made, the artifact or behavior that proves it worked, and the failure you were able to diagnose. A successful deployment with no explanation is weaker evidence than a deployment you can intentionally break and repair. For example, remove a role assignment, corrupt a retrieval filter, change an agent tool schema, or introduce a malformed document. If you can predict the symptom and locate the cause, you are building the reasoning that scenario questions reward.

Keep the log short enough to review. One line per important decision is often sufficient: requirement, chosen approach, rejected alternative, validation method, and unresolved weakness. After several exercises, patterns emerge. You may discover that you repeatedly understand model behavior but miss identity boundaries, or that retrieval works until metadata filtering and authorization are introduced. Those patterns should determine the next lab—not whichever topic feels most familiar.

Use a transition log to decide what deserves more study

After each exercise, record four things: the decision you made, the evidence that supported it, the failure you deliberately introduced, and the topic you had to look up. Those notes become a far more accurate study plan than a percentage score from a generic quiz.

Patterns will emerge. You may discover that language and vision are strong but agent permissions are weak. You may be comfortable with Azure networking but uncertain about Foundry project deployment. You may understand RAG conceptually but struggle to diagnose relevance failures. Study the repeated weakness, not the topic that merely feels unfamiliar.

Keep the transition practical. The strongest AI-102 experience is worth preserving, but it should be rehearsed in the system shape that AI-103 now measures. When you can build, secure, evaluate, trace, and explain the newer architecture—not simply recognize its vocabulary—you have converted legacy preparation into current exam readiness.