Microsoft AI-102 to AI-103 Practical Transition: Scenarios, Exercises, and Skills to Rehearse

 

Preparing for AI-103 after spending time on AI-102 material is not a matter of reading the old notes one more time. The useful parts of AI-102-era knowledge still provide leverage, especially around Azure AI services, search, language, vision, responsible AI, authentication, and solution integration, but Microsoft retired AI-102 on June 30, 2026. The current role-aligned exam is AI-103, Developing AI Apps and Agents on Azure, and its blueprint places much more explicit emphasis on generative AI, agents, retrieval, evaluation, observability, controlled tool use, deployment, and lifecycle operations.

That makes practical transition work especially important. The goal is not to prove that you remember a service name. It is to rehearse the engineering decisions the current exam can ask you to make. A useful exercise should force you to identify requirements, select an architecture, implement enough of the design to expose real constraints, inject a failure, and explain why the correction belongs at a particular layer. The exercises in this guide are organized around that pattern so that prior AI-102 familiarity becomes current, testable skill rather than comfortable but outdated recognition.

Begin with a transition lab inventory, not a list of old topics

Before building anything, inventory the hands-on artifacts you already have. Separate them into three categories: still representative, technically transferable but outdated in context, and no longer useful as current evidence. A simple image-analysis script may still demonstrate request-and-response reasoning. An old search lab may still teach indexing and relevance. A notebook built around a retired portal workflow may preserve conceptual value but should not be treated as proof that you can operate the current platform.

For each artifact, write down what engineering skill it actually demonstrates. Does it prove you can authenticate securely? Choose a model? Create a searchable knowledge source? Diagnose poor retrieval? Trace a request through multiple components? Constrain a tool? Evaluate generated output? If the answer is only “I successfully followed the steps,” the lab is weak evidence even if it once matched AI-102 perfectly.

The most efficient transition strategy is to reuse an old artifact only when it shortens the path to a current decision. If an old Azure AI Search project already contains useful sample documents, reuse the documents and rebuild the retrieval and authorization logic around current requirements. If an old language lab demonstrates text extraction, place that capability inside a modern agent or workflow rather than repeating the isolated exercise.

Exercise 1: turn a familiar service-selection problem into a system-design problem

Start with a scenario that resembles classic AI-102 preparation: a business needs to classify support requests, extract entities, summarize the request, and route it to an appropriate queue. Under an older study style, you might map each task to a service and stop. For AI-103 transition practice, continue until the system boundary is clear.

Write the requirements before naming any service. Which outputs must be deterministic enough for automation? Which outputs may be generative? Is the source data sensitive? What latency is acceptable? What happens when confidence is low? Does the system need to explain why a case was routed? Which identity reads the source queue and which identity writes to the destination? What telemetry is required to investigate incorrect routing?

Then design two architectures. The first should use specialized capabilities where they are easy to validate. The second can use a generative model for more of the workflow. Compare them on quality, operational complexity, cost, failure isolation, and testability. The exercise teaches an important transition habit: current AI engineering is not simply about choosing the newest model. It is about deciding where probabilistic behavior adds value and where deterministic processing is safer.

To finish the exercise, inject one failure, such as malformed input or an unavailable downstream queue. Describe what the user sees, which component should handle the error, and which telemetry would confirm the cause. That final step turns architecture into operations.

Exercise 2: rebuild retrieval as a measurable pipeline

Many AI-102 candidates already understand Azure AI Search at a conceptual level. The current transition challenge is to connect retrieval to grounding quality, authorization, evaluation, and agent behavior. Build a small corpus with deliberately difficult characteristics: two versions of the same policy, one long document with information split across sections, one document that only a subset of users should access, and one irrelevant document that shares important vocabulary with the correct source.

Create an ingestion and retrieval design that preserves useful metadata such as document identity, version, department, effective date, and authorization scope. Decide how content is chunked and what information should remain attached to each chunk. Then create queries that test lexical matching, semantic similarity, metadata filters, and hybrid behavior. The objective is not to maximize one score. It is to understand why different retrieval methods succeed or fail.

Next, connect the retrieved evidence to a generative answer. Inspect the retrieved passages before inspecting the final response. If the model gives a wrong answer, identify whether the error came from ingestion, chunking, filtering, retrieval ranking, prompt construction, or generation. Do not permit yourself to change the prompt until you have proved that the correct evidence reached the model.

Finally, test authorization. Use two fictional users with different document access. A system that retrieves a semantically relevant but unauthorized passage is not merely producing low-quality search; it has a security failure. This exercise transforms search familiarity into the retrieval-and-grounding reasoning AI-103 expects.

Exercise 3: design a tool-using agent with an explicit authority boundary

Choose a simple business process in which an agent can both read information and request a change. For example, the agent may retrieve order status and create a return request. Define two tools rather than one broad “manage order” function. The read tool should expose only the data necessary to answer the user. The write tool should validate parameters, enforce business rules, and require the correct authorization.

Give the agent a natural-language instruction explaining when it may suggest a return, but do not rely on that instruction as the control. Put non-negotiable limits in deterministic application or API logic. If a high-value return requires approval, the approval should be enforced outside the model. If a user may modify only their own order, the downstream authorization should enforce that condition.

Test the design with normal requests, ambiguous requests, attempts to exceed a limit, malformed identifiers, and a prompt that tries to persuade the agent to bypass policy. Record which layer rejects each unsafe action. If every safeguard exists only in the prompt, redesign the system.

Then remove the agent’s permission to call the write tool and observe the symptom. Does the model still decide correctly but the tool returns an authorization failure? Does the application surface the failure clearly? Which trace event makes the cause visible? This is a practical way to rehearse the difference between model reasoning and system authority.

Exercise 4: practice agent memory as governed state

Memory can sound simple in study material because it is often demonstrated as conversation continuity. In real systems, persistent state introduces scope, privacy, retention, relevance, and security decisions. Build a small support agent that remembers a user’s preferred language and the identifier of an active case, but does not persist the full conversation by default.

Define each item of state explicitly. Is it session-only, user-scoped, tenant-scoped, or durable business data? Who can read it? When does it expire? What happens if the user changes role or leaves the organization? Which data should never be stored as conversational memory because a system of record already owns it?

Create a failure scenario in which stale memory points the agent to an old case. The correct solution is not simply to increase context or keep more history. Decide when the agent should revalidate state from the authoritative system. Create a second scenario in which two users share a device or application session and verify that state cannot leak across identities.

This exercise helps AI-102 transition candidates because it reframes memory from a convenient feature to a controlled data design. On AI-103, the important question is often not whether an agent can remember something, but whether it should and under what boundaries.

Exercise 5: compare deterministic workflow orchestration with agentic orchestration

Take a process with four steps: gather a request, validate eligibility, obtain approval when required, and execute an action. First implement or diagram it as a deterministic workflow. The sequence should be fixed, and each branch should be explicit. Then redesign it with an agent that can choose which information to gather and which tool to call.

Compare the two designs using concrete criteria. Does the process actually benefit from flexible planning? Are the tools sufficiently distinct? Can the agent create a side effect that a fixed workflow would have protected? What happens when the model misunderstands the request? How much extra tracing is required? How does the design recover from a failed tool call?

Now change the scenario so that the user may ask open-ended questions requiring several unpredictable information sources before deciding what action is needed. The agentic design may become more justified. The lesson is not “workflow good, agent bad” or the reverse. It is requirement-driven orchestration.

Write a short decision record explaining why you would choose one design for each version of the scenario. Current exam readiness improves when you can defend the simpler architecture and recognize when flexibility earns its additional risk and cost.

Exercise 6: build an evaluation set before tuning the system

Legacy AI labs often end when the API returns a plausible response. Current preparation should continue into evaluation. Choose one of your retrieval or agent exercises and create a small test set before changing prompts or models. Include normal inputs, ambiguous requests, unsupported questions, conflicting evidence, sensitive content, and an attempted policy bypass.

Define success per case. For a grounded answer, success might include relevant retrieval, faithful use of evidence, absence of unsupported claims, and appropriate refusal when evidence is missing. For an agent, add correct tool selection, valid parameters, policy compliance, and safe handling of side effects.

Run the test set, categorize failures, and resist the urge to summarize everything with one percentage. A retrieval failure requires a different correction from a generation failure. An unsafe tool call differs from a harmless formatting problem. A refusal on a valid request is a different risk from a confident answer when no evidence exists.

After one change, rerun the same set and add any newly discovered edge case. This creates the habit of regression testing. It also trains an exam-relevant principle: AI quality is not a feeling generated by a few good demonstrations; it is evidence collected against defined criteria.

Exercise 7: trace an AI request end to end

Create a request path that contains at least four stages: application input, retrieval, model generation, and a tool call. Add a correlation identifier that conceptually follows the request across stages. Decide which timestamps, error codes, model configuration, retrieval metadata, tool parameters, and outcome indicators would be useful during troubleshooting.

Then introduce three symptoms one at a time. First, retrieval returns no useful evidence. Second, the model receives good evidence but produces an unsupported conclusion. Third, the tool call is correct but fails because of permissions. For each symptom, identify the first telemetry you would inspect and the signal that would confirm the failing layer.

A weak diagnostic answer says “check the logs.” A strong answer names the boundary: retrieval trace, model response and safety/evaluation evidence, identity/authorization event, or downstream service error. If the architecture does not produce enough information to distinguish those failures, improve the instrumentation.

Transition candidates should rehearse this deliberately because modern AI applications contain more interacting components than many earlier AI-102 examples. Observability is what prevents every incident from being blamed on the model.

Exercise 8: rehearse quota, retry, and cost decisions with a load scenario

Imagine that a pilot application succeeds and traffic increases tenfold. Users report intermittent latency, some requests are throttled, and monthly model cost rises faster than expected. Build a response plan without inventing undocumented service limits.

First map which components scale independently: application compute, model throughput, retrieval service, storage, and external tools. Then decide where retry with backoff is appropriate and where retries could amplify cost or side effects. A read-only lookup may be safely retried under a controlled policy; a side-effecting tool may require idempotency or a different recovery path.

Inspect cost drivers conceptually. Larger models, long prompts, unnecessary retrieved context, repeated tool calls, excessive agent loops, and high-frequency evaluation or logging can all add cost. Propose optimizations only after deciding which quality and safety requirements cannot be sacrificed.

Finish by defining graceful degradation. If a premium model is temporarily constrained, can a lower-cost model handle a limited class of requests? Can non-urgent work be queued? Should the application return a controlled message rather than repeatedly retrying? This exercise turns scaling from a platform fact into an architecture decision.

Exercise 9: secure the same solution with identity and network controls

Draw a solution containing an application, model endpoint, search or retrieval resource, storage source, tool API, and monitoring destination. Draw every call as an arrow and label the caller identity. Then write the minimum permissions required for each arrow in functional terms, even if you do not memorize exact role names.

Replace embedded keys wherever a supported managed identity or keyless approach is appropriate. Separate application identity from user identity and decide whether any call must preserve user authorization. Add private networking only where the scenario requires isolation, then reason through the consequences for DNS, deployment pipelines, monitoring, and developer access.

Now intentionally break one boundary. Remove the application’s access to the search resource. Change a network rule so the application cannot reach a model endpoint. Give the tool service too much privilege. Predict the symptom in each case and the evidence that would distinguish authentication, authorization, and network reachability problems.

This rehearsal is valuable because security questions often present a working prototype and ask how to make it production-ready. Candidates who treat security as a final toggle miss the end-to-end design.

Exercise 10: connect vision to a wider business workflow

If your AI-102 preparation included computer vision, preserve that knowledge but stop practicing vision as an isolated endpoint. Build a scenario in which a field technician uploads an equipment image, adds a short note, and expects the system to identify a visible component, retrieve relevant maintenance guidance, and draft a recommendation.

Separate the stages. What needs visual understanding? Is OCR required for a serial plate or document label? What information should become structured metadata? What belongs in retrieval? Which output must be grounded in maintenance documentation rather than inferred from the image? How should uncertain recognition be represented?

Add a privacy constraint and a safety constraint. Perhaps the image can include employee badges or customer information. Perhaps the system must never recommend an unsafe repair solely from visual inference. Decide where validation, redaction, or human review belongs.

Then create a bad image, an image with misleading embedded text, and an image that lacks the necessary component. The exercise should force you to consider failure handling and indirect prompt-injection style risks rather than assuming all images are trustworthy evidence.

Exercise 11: compare specialized language processing with generative processing

Choose a text workload such as extracting product names, sentiment, issue category, and a concise summary from customer feedback. Solve it conceptually in three ways: specialized language capabilities, a general generative model, and a hybrid design.

For each, evaluate validation, structured output, adaptability to new categories, latency, cost, and failure behavior. A specialized capability may offer predictable semantics for a bounded task. A generative model may adapt more easily to nuanced instructions but require stronger output validation and evaluation. A hybrid design may use deterministic extraction for known fields while reserving generation for synthesis.

Next, introduce multilingual content, ambiguous tone, and sensitive text. Decide whether translation should occur explicitly or whether a model can process the language directly. Decide how safety handling affects downstream workflows. The objective is to learn task fit rather than memorize a single preferred service.

AI-102 candidates often have useful language-service knowledge. AI-103 transition practice should teach when that specialized knowledge remains the better engineering choice inside a broader generative solution.

Exercise 12: turn information extraction into a governed ingestion pipeline

Use a small document set containing invoices, policies, or service forms. Define which fields must be extracted, which parts need layout preservation, which content becomes searchable, and which values require human validation. Then draw the path from raw document to structured output to index or system of record.

Add operational states: unreadable document, missing field, low-confidence extraction, duplicate upload, schema change, and stale index. Decide which conditions can be retried, which require manual review, and which should stop downstream automation. If extracted data will later be used for retrieval, retain enough provenance to trace a generated answer back to the original source.

Then connect an agent to the resulting knowledge. Ensure the agent cannot silently treat unvalidated extraction as authoritative when the business process requires approval. This shows how information extraction, retrieval, and agent design combine without collapsing into one indistinct AI layer.

The exercise is especially useful for transition preparation because AI-102-era document skills can transfer strongly, but AI-103 expects them to participate in modern knowledge and agent workflows.

Exercise 13: rehearse prompt and context failures separately

Take a grounded assistant that produces an incorrect answer. Hold retrieval constant while changing the system instructions. Then restore the instructions and alter retrieval. Then introduce stale conversation memory. The purpose is to see that prompt, retrieved evidence, and memory are distinct inputs with distinct failure modes.

Create one test where the model receives too much irrelevant context. More context is not always safer. Irrelevant or conflicting passages can dilute the decisive evidence. Create another where a retrieved document contains adversarial instructions. The application should treat retrieved text as data, not as trusted authority that can rewrite system policy.

After each failure, state which layer should be changed. A prompt cannot repair missing authorization. A larger model cannot correct an index that excludes current documents. More memory cannot fix a tool schema. Practicing this separation is one of the best ways to avoid model-centric troubleshooting.

Exercise 14: create a release pipeline that treats AI artifacts as controlled changes

Design development, test, and production environments for one of your earlier scenarios. List the things that can change: application code, prompts, model deployments, tool schemas, retrieval index configuration, evaluation datasets, safety settings, and access policies. Decide which artifacts belong in source control and which require environment-specific configuration.

Define a release gate. A prompt change may need regression evaluation. A model change may need quality, latency, and cost comparison. An index schema change may need a rebuild and retrieval tests. A tool change may need contract and authorization tests. A role assignment change may require security validation.

Then plan rollback. If a new model or prompt degrades production quality, what version information is available and which configuration can be restored? If the change modifies an index or data pipeline, is rollback still simple? This exercise turns CI/CD from a bullet in the blueprint into lifecycle reasoning.

Exercise 15: run a capstone incident that crosses every important boundary

End transition practice with a scenario that cannot be solved by one service. An internal operations assistant retrieves runbooks, analyzes incident text, queries monitoring data, proposes remediation, and can execute only read-only diagnostics automatically. A production change requires human approval and a separate privileged tool.

Inject several faults over the course of the exercise. The assistant retrieves an outdated runbook. A user lacks access to a sensitive environment. A tool returns malformed output. Model latency increases. A retrieved document contains hostile instructions. A proposed remediation conflicts with an approved change freeze. The application hits a quota during a peak incident.

For every fault, identify the layer, the evidence, the immediate safe behavior, and the long-term correction. Do not accept “improve the prompt” as a universal answer. Some faults belong to ingestion, some to identity, some to tool contracts, some to policy, some to scaling, and some to model quality.

If you can reason through the incident without losing track of authority, state, evidence, and observability, you have moved beyond isolated AI-102 familiarity into the integrated engineering mindset the current exam rewards.

Use a rehearsal record that captures decisions rather than screenshots

For every practical exercise, keep a short record with six fields: requirement, architecture, rejected alternative, failure injected, evidence inspected, and lesson learned. Screenshots can remind you what an interface looked like, but they are weak preparation when the platform changes. A decision record preserves the reason behind the implementation.

The rejected alternative is especially valuable. Exam questions often contain several options that would work in some context. If you practice explaining why a tempting alternative violates a requirement, creates unnecessary complexity, weakens security, or fails at the wrong layer, you train exactly the discrimination needed for scenario questions.

The failure field prevents happy-path preparation. A candidate who has only seen successful demonstrations can recognize features but may struggle when the exam describes a symptom. Fault injection turns familiarity into diagnostic skill.

Sequence the exercises by dependency, not by comfort

Do not begin by repeating the topics you liked most in AI-102. Start with the capabilities that other skills depend on. Identity, retrieval, model/application boundaries, agent tool controls, and observability have high dependency value because they recur across many scenarios.

A sensible transition sequence is: requirements and architecture, retrieval, identity, tool use, agent state and orchestration, evaluation, observability, deployment, then modality-specific exercises and cross-domain capstones. Move faster through a familiar area only when you can produce current evidence. Do not spend three days polishing vision simply because it feels easier while agent authorization remains weak.

Alternate building and troubleshooting. Two successful labs in a row can create false confidence. After a build works, change one assumption or break one component. This keeps preparation focused on mechanisms rather than memorized sequences.

Know when an exercise is complete

An exercise is not complete when the demo works once. It is complete when you can explain the requirement, defend the architecture, identify the authority boundaries, reproduce the core implementation without step-by-step instructions, and diagnose at least one realistic failure.

You should also be able to explain what part of the skill came from AI-102-era knowledge and what part reflects the current AI-103 operating model. That distinction keeps transition study efficient. Strong transferable knowledge should be maintained, not rebuilt from zero. Weak or outdated knowledge should be repaired in the context where it now matters.

Finally, revisit one exercise after several days without notes. If you can reconstruct the design and troubleshooting logic, the skill is becoming durable. If you can only remember what the finished screen looked like, repeat the decision process.

Final transition practice strategy

The fastest route from AI-102 history to current AI-103 readiness is not a larger collection of tutorials. It is a deliberate set of scenarios that force the old knowledge to operate inside newer architecture. Rebuild retrieval as a measurable, permission-aware pipeline. Treat agents as constrained applications with tools and state, not as trusted administrators. Put safety, identity, observability, evaluation, scaling, and release control into the design from the beginning. Connect vision, language, and extraction skills to complete workflows instead of studying them as isolated endpoints.

Use each exercise to generate evidence: a diagram, a decision record, a small implementation, a trace, a failure diagnosis, or a regression test. Those artifacts reveal whether a skill has genuinely transferred. They also expose the places where comfortable AI-102 familiarity no longer reaches far enough.

The transition is successful when you can receive an unfamiliar Azure AI scenario, identify its data, model, retrieval, orchestration, tool, identity, safety, deployment, and operations boundaries, and then make a defensible choice under constraints. At that point, the value of your AI-102 experience has not disappeared. It has been upgraded into the broader engineering judgment the current AI-103 exam is designed to measure.