Microsoft AI-102 to AI-103 Transition Readiness Matrix: How to Diagnose Which Azure AI Skills Still Transfer

 

Microsoft retired AI-102 and the Azure AI Engineer Associate certification on June 30, 2026. That changes the meaning of “AI-102 readiness.” A candidate preparing now should not measure whether old notes are complete enough for a retired exam; the useful question is which AI-102-era skills remain valuable for the current AI-103 Developing AI Apps and Agents on Azure exam, which skills have changed context, and which current capabilities require substantial new preparation.

A transition readiness matrix solves that problem better than a simple topic checklist. It evaluates evidence: can you choose an appropriate Azure AI approach from requirements, implement retrieval rather than merely describe it, design an agent with constrained tools and memory, secure the solution with managed identity and role-based access, observe failures, evaluate quality and safety, and explain operational tradeoffs? The matrix below is designed to reveal where legacy familiarity creates genuine leverage and where it creates false confidence.

Treat the transition as a change in operating model, not a rename

AI-103 still values core Azure AI engineering concepts, but the current blueprint places explicit weight on generative AI, agentic systems, retrieval, evaluation, observability, security, deployment, and solution lifecycle decisions. Candidates coming from AI-102 often recognize many service categories—vision, language, search, content safety, and Azure AI platform concepts. Recognition is helpful, but it is not enough if the current scenario asks you to compose these capabilities into an agentic application with tools, memory, retrieval, approvals, and production monitoring.

The most important diagnostic question is therefore not “Have I seen this service before?” It is “Can I make the engineering decision the current scenario requires?” A legacy skill transfers strongly when the underlying reasoning remains useful. It transfers partially when the technology is still relevant but the architecture around it has changed. It transfers weakly when the candidate remembers a product label without being able to use the capability in a modern solution.

This distinction prevents two opposite mistakes. One is discarding everything learned for AI-102 and starting from zero. The other is assuming that old preparation maps one-to-one onto AI-103. A readiness matrix should preserve real competence while exposing the delta.

Build the matrix around evidence levels

Use four evidence levels for every current AI-103 capability. Level 0 means recognition only: you can define the concept but cannot apply it. Level 1 means guided application: you can follow a documented pattern or lab. Level 2 means independent scenario execution: given requirements, you can choose, configure, and validate an approach without step-by-step instructions. Level 3 means tradeoff reasoning: you can explain why one design is preferable, identify failure modes, and adapt when constraints change.

For exam readiness, Level 2 is a practical minimum for most implementation-oriented areas and Level 3 is desirable for high-weight planning and generative/agentic decisions. The matrix is not an official scoring system; it is a preparation control. Its value is consistency. If you rate every topic using the same evidence standard, the weak areas become visible.

Do not award yourself a higher level because you completed a lab months ago. Reproduce evidence. Explain the design aloud, rebuild the critical part, inspect telemetry, or diagnose a deliberately broken configuration. Readiness should be based on what you can do now.

Domain 1: Plan and manage an Azure AI solution

AI-103 gives substantial weight to planning and management. Legacy AI-102 candidates may be comfortable choosing cognitive services or describing responsible AI, but the current domain demands a wider lifecycle view. You should be able to translate requirements into model and service choices, decide how retrieval and knowledge will be provided, plan tools and memory for agents, select deployment infrastructure, estimate scaling and quota implications, design observability, and secure access.

Rate yourself separately on solution decomposition, platform selection, security, deployment, cost/scale, and monitoring. A candidate may be strong at model selection but weak at network isolation or managed identity. A single “planning = good” score hides that weakness. For each subskill, require a scenario artifact: an architecture sketch, decision table, deployment plan, threat model, or operational dashboard design.

A strong transfer from AI-102 is the habit of matching requirements to Azure AI capabilities. The changed expectation is that the answer often spans multiple components. You may need a model endpoint, vectorized or hybrid retrieval, a knowledge source, a tool API, identity controls, content filters, telemetry, and a deployment pipeline. Readiness means understanding the boundaries between these components rather than treating “Azure AI” as one service.

Planning diagnostic: service and model selection

Take a fictional workload with latency, privacy, multilingual, data-residency, cost, and quality constraints. Can you decide which capabilities need a foundation model, which need deterministic services, which require retrieval, and which should remain conventional application logic? Can you explain why a smaller model may be preferable for a narrow high-volume task while a more capable model is justified for complex reasoning?

Then change one constraint. Suppose sensitive data cannot leave a controlled network path, or throughput increases by an order of magnitude, or the workload requires structured extraction rather than open-ended generation. If your design changes coherently, you are reasoning. If you merely repeat the same service list, the skill is not yet strong.

Legacy AI-102 preparation often emphasized selecting the correct Azure AI service for a recognized task. Keep that skill, but upgrade it to system composition. Current readiness requires choosing a set of components and explaining how they interact under operational constraints.

Planning diagnostic: identity, network, and secrets

A production AI solution should not be considered ready if security is an afterthought. Test whether you can distinguish user authentication from workload identity, use managed identity where appropriate, apply least-privilege role assignments, avoid embedding long-lived keys, and reason about private network access when the scenario requires isolation.

Create a diagram showing an application, AI project/resource, data source, search or retrieval component, tool API, and monitoring destination. Annotate which identity calls which resource and which permissions are required. Then remove a permission and predict the failure. This turns RBAC from terminology into operational understanding.

Candidates with AI-102 history may remember authentication patterns but should verify current platform behavior and current terminology rather than relying on screenshots or portal steps from old materials. Readiness is the principle plus current implementation awareness.

Planning diagnostic: quotas, scaling, cost, and reliability

AI systems fail in production for reasons that do not appear in a happy-path demo: rate limits, token pressure, retrieval latency, downstream API failures, model unavailability, tool timeouts, and runaway agent loops. A current readiness matrix should ask whether you can identify these failure modes and design bounded behavior.

Given a workload, estimate which elements scale independently. Model throughput may be constrained differently from search queries, application compute, or external tools. Decide where to use retry with backoff, where retry could amplify cost, when to cache, when to queue, and how to surface partial failure. You do not need unsupported performance numbers; you need the operational reasoning.

A strong candidate also understands that cost is architectural. Prompt size, model choice, retrieval breadth, tool calls, evaluation frequency, and retention of telemetry can all affect cost. Readiness means being able to trade quality, latency, safety, and cost without treating the cheapest option as automatically correct.

Domain 2: Generative AI and agents—the largest transition zone

The current blueprint gives the largest share to generative AI solutions and agents. This is where AI-102-era familiarity is most likely to be incomplete. Rate yourself on prompt and model configuration, RAG, evaluation, content safety, tool/function calling, agent memory, workflows, approvals, multi-agent design, monitoring, and failure analysis.

The readiness test is architectural behavior. Can you explain what the model knows from its parameters, what the application injects into context, what retrieval contributes, what memory persists, and what tools can change in the external world? If those boundaries are blurred, agent scenarios become confusing because every feature appears to be “more context.”

Do not rate “agents” as one topic. Split it into orchestration, tool contracts, state/memory, knowledge retrieval, guardrails, human approval, observability, and recovery from failure. The exam can test any of these through scenario decisions.

RAG readiness: retrieval is a pipeline, not a checkbox

A useful RAG diagnostic begins with source data. How is content chunked? What metadata should travel with it? How are embeddings or indexes created? Which retrieval strategy is appropriate? How many results should be provided? How do you keep irrelevant or unauthorized content from entering the context? How will citations or provenance be represented to the application?

Then test failure modes. Create a question whose answer exists but is split across chunks. Create one with two contradictory versions. Create a user who should see only one document set. Create a query where semantic similarity retrieves a plausible but irrelevant passage. If you can diagnose these problems, you are beyond the demo level.

AI-102 candidates may have prior Azure AI Search experience. That transfers strongly, but AI-103 readiness requires connecting search decisions to generative quality, grounding, access control, evaluation, and agent knowledge. Retrieval quality is now part of model-system quality.

Agent-tool readiness: distinguish reasoning from authorization

A model deciding to call a tool does not mean the call should automatically be permitted. Your matrix should test whether you can design a narrow tool schema, validate parameters, constrain permissions, enforce business rules outside the model, and require approval for high-impact actions.

Use a scenario such as an agent that can query inventory and create a purchase order. Reading inventory may be low risk; creating an order changes the world. A robust design separates those privileges, validates limits, logs actions, and provides a human approval step when policy requires it. The model can propose; the application remains responsible for authority.

This is a major readiness signal because agentic AI combines probabilistic reasoning with deterministic systems. Candidates who treat the model as a trusted administrator are not ready. Candidates who place controls at tool boundaries and can explain why are much closer.

Memory readiness: state must have scope and retention rules

Agent memory can improve continuity, but uncontrolled memory introduces privacy, relevance, security, and cost problems. Test whether you can distinguish short-lived conversational context from durable user preferences or application state. Decide what deserves persistence, how it is scoped to the correct user or session, how it expires, and how sensitive data is protected.

Create a scenario where a user changes roles, a conversation contains confidential information, or a stored preference becomes stale. Ask what data should remain available and what controls are needed. If the answer is simply “store more context,” the skill needs work.

The core readiness principle is purposeful state. Memory should serve an application requirement and obey data governance, not exist because an agent framework offers a memory feature.

Multi-agent readiness: prove why separation helps

Multi-agent designs can be useful when responsibilities, tools, or control boundaries are genuinely distinct. They can also add latency, cost, coordination failure, and debugging difficulty. A readiness matrix should test whether you can justify multiple agents rather than assuming more agents mean more intelligence.

Take a workflow with research, policy validation, and execution. Decide whether separate roles improve tool isolation or review, or whether one orchestrated agent with deterministic workflow steps is simpler. Define handoff data, failure behavior, and ownership of final decisions.

Candidates should be able to recognize when multi-agent coordination is an architectural tradeoff. The exam is more likely to reward requirement-driven design than trend-driven complexity.

Evaluation readiness: quality must be measured, not admired

Generative output can sound correct while being wrong, unsafe, ungrounded, or irrelevant. Rate yourself on creating evaluation datasets, selecting useful quality and safety criteria, comparing versions, inspecting failures, and separating model quality from retrieval or tool failures.

Build a small test set containing normal requests, ambiguous prompts, adversarial inputs, missing knowledge, conflicting sources, and tool errors. For each, define what success means. The goal is not to produce one universal score. It is to detect regression and understand why the system failed.

Legacy preparation that focused mostly on getting an API response is insufficient. Current readiness includes a feedback loop: instrument, evaluate, analyze, change, and re-evaluate.

Observability readiness: trace the system, not just the model call

An AI application may involve user request handling, retrieval, model inference, agent planning, tool calls, external systems, policy checks, and post-processing. When an answer is slow or wrong, you need enough telemetry to locate the stage responsible.

Design a trace for a single request. Record correlation identifiers, retrieval results or metadata, model configuration, tool calls, latency by stage, errors, safety decisions, and outcome labels where appropriate. Protect sensitive content in logs. Then diagnose three failures: no relevant retrieval, tool timeout, and model fabrication despite correct context.

A candidate who can reason through these distinctions has strong current operational readiness. A candidate who would “check the model logs” without knowing which component produced the failure needs more practice.

Domain 3: Computer vision—legacy skills can transfer strongly

Vision remains part of AI-103. AI-102 experience with image analysis, optical character recognition, or vision service selection can provide useful leverage. The readiness question is whether you understand current capabilities and can integrate them into a wider solution.

Test with scenarios: extracting text from scanned documents, analyzing image content, using multimodal generative models, or deciding when a specialized vision service is preferable to a general model. Identify input constraints, output structure, confidence or validation needs, privacy implications, and downstream processing.

Do not overinvest merely because vision feels familiar. Use the blueprint weighting to keep effort proportional. If you can independently implement and troubleshoot representative vision workflows, extra hours may have lower value than repairing weak agent or planning skills.

Domain 4: Natural language processing and speech

Legacy language-service knowledge can also transfer, but current preparation should emphasize task fit and integration. Can you distinguish deterministic extraction or classification from generative interpretation? Can you choose between speech and text capabilities based on requirements? Can you handle language, format, latency, and confidence considerations?

A useful diagnostic is to solve one business problem three ways: with a specialized language capability, with a generative model, and with a hybrid approach. Explain which is easier to validate, which handles open-ended inputs, which has stronger cost predictability, and where grounding is required.

Readiness is not memorizing that a feature exists. It is selecting an approach and defending the tradeoff under the scenario constraints.

Domain 5: Knowledge mining and information extraction

Information extraction intersects with document ingestion, search, structured outputs, retrieval, and downstream automation. Candidates should be able to identify when the objective is to create a searchable knowledge base, when it is to extract fields into a structured process, and when the two should be combined.

Build an exercise around invoices, policies, or service tickets. Define the source variability, fields or entities, error handling, human validation threshold, indexing strategy, and consumer application. Then add a generative layer that summarizes or reasons over the extracted content. This reveals whether you understand the boundary between extraction and generation.

AI-102 candidates with search or document-processing experience often transfer well here, but they should verify current service names and platform integration rather than relying on retired screenshots.

Score transfer separately from current readiness

For every skill, record two scores: legacy transfer and current execution. High transfer plus high execution means “maintain.” High transfer but low current execution means “refresh.” Low transfer but high current execution means new competence has already been built. Low transfer and low execution is the priority gap.

This two-axis model prevents emotional study decisions. A topic may feel comfortable because it resembles AI-102, yet the current task could be more complex. Conversely, a topic may feel new but already be strong because you have current project experience.

Add a third field for evidence date. AI tooling changes quickly. A lab completed against an obsolete interface may still prove architectural understanding, but it does not prove current operational fluency. Refresh the evidence when platform changes matter.

Use weighted risk to choose study priorities

After scoring, combine three factors: blueprint weight, execution gap, and dependency value. Agentic/generative and planning domains have high weight. Security, retrieval, observability, and evaluation also have high dependency value because they influence multiple scenarios. A narrow low-weight feature with a small gap usually deserves less time.

For example, if you are Level 1 in agent tools and Level 1 in observability but Level 2 in vision, the priority should not be “make vision Level 3 because it is easier.” Repair the high-weight, cross-cutting weaknesses. Study planning should reduce risk, not maximize the number of comfortable topics.

Recalculate after each preparation cycle. A readiness matrix is useful because it changes. If the same weakness remains after several study sessions, switch method: build something, troubleshoot something, or explain a scenario to someone else rather than rereading the same notes.

A practical transition matrix

Create rows for solution decomposition, model/service selection, RAG, agents, tool calling, memory, multi-agent orchestration, evaluation, safety, observability, managed identity/RBAC, private networking, deployment/CI/CD, quotas/cost, computer vision, language/speech, and information extraction. Add columns for legacy transfer, current execution, evidence, failure mode, and next exercise.

An example row might read: “RAG — transfer 2, current execution 1, evidence: old Azure AI Search lab, failure: cannot explain metadata security filtering, next exercise: build retrieval with authorization-aware filtering and evaluate irrelevant chunks.” That row produces an action. A row that says “RAG — 70%” does not.

Another row might be: “Tool calling — transfer 0, current execution 1, evidence: tutorial agent calling weather function, failure: no validation/approval, next exercise: design a high-impact tool with parameter validation, least privilege, and human approval.” Again, the weakness becomes concrete.

Readiness scenarios should cross domains

Realistic questions often combine domains. Design a scenario where a support agent retrieves product documentation, calls a ticket API, handles customer data, and must be monitored for unsafe actions. That exercise tests retrieval, tools, security, observability, and evaluation simultaneously.

Then inject faults. Remove retrieval permissions. Return malformed tool output. Supply a prompt-injection attempt in a retrieved document. Exceed a quota. Provide conflicting knowledge. Ask how the system should fail safely and what telemetry would reveal the issue.

Cross-domain practice is the best test of whether skills have transferred because it prevents isolated memorization. A candidate may know each component separately but still struggle to reason about interaction effects.

Signs that you are ready to shift from learning to review

You are approaching readiness when you can take an unfamiliar scenario and produce a defensible architecture without searching for a template; explain why a simpler alternative is insufficient; identify at least three credible failure modes; secure the major resource boundaries; define how quality and safety will be measured; and predict which telemetry would diagnose common failures.

You should also be able to explain the transition itself. Which AI-102 concepts still matter? Which AI-103 expectations are genuinely new or expanded? Where do agents change the security and observability model? If you cannot articulate that delta, old familiarity may still be masking gaps.

Finally, readiness should survive a cold start. Reattempt a scenario after several days without notes. If you can still reason through the design, your knowledge is becoming durable rather than lab-dependent.

Final transition decision

Do not prepare for a retired exam by polishing a retired checklist. Use AI-102 experience as an asset, but verify it against the current AI-103 blueprint and current Azure AI architecture. Keep transferable reasoning around service selection, responsible AI, search, vision, language, and security. Upgrade it with agentic design, tool boundaries, memory, evaluation, observability, modern deployment, and lifecycle operations.

The readiness matrix should leave you with a short list of evidence-based gaps, not a vague feeling of confidence. If a row lacks current evidence, create it. If a scenario exposes an architectural misunderstanding, correct it. If a legacy skill remains strong, maintain it and spend time elsewhere. That is how AI-102 experience becomes useful preparation for AI-103 instead of a source of false confidence.

Diagnose prompt and context engineering as separate skills

Candidates sometimes place prompting, retrieval, memory, and system instructions in one mental bucket called “prompt engineering.” That hides important boundaries. Prompt instructions tell the model how to behave; retrieved content supplies external knowledge; memory supplies selected state; tool outputs provide results from external actions. A readiness matrix should test each independently because the failure modes differ.

Create an exercise in which a grounded assistant answers a policy question incorrectly. First hold retrieval constant and change the instructions. Then hold instructions constant and change chunking or retrieval filters. Then test whether stale memory is contaminating the answer. If you can isolate the failing layer, you are reasoning operationally. If every failure leads to “rewrite the prompt,” the skill remains shallow.

Also test context-budget judgment. More context can reduce quality when irrelevant content crowds the useful evidence or when conflicting passages are supplied without version controls. A current AI engineer should be able to decide what belongs in context and what should stay outside the model entirely.

Diagnose guardrails and responsible-AI controls at multiple layers

Responsible AI is not a single content-filter switch. Readiness includes recognizing risks during design, controlling inputs and outputs, constraining tools, evaluating safety, monitoring production behavior, and defining escalation or human review for high-impact cases. The right control depends on the harm being addressed.

Use a scenario where an agent summarizes internal HR material and can also open support tickets. Identify privacy risks, prompt-injection risks, inappropriate disclosure, tool abuse, and fabricated claims. Then assign controls to layers: identity and access controls for data exposure, retrieval filtering for authorized knowledge, input/output safety measures for harmful content, application validation for tool actions, and monitoring/evaluation for emerging failure patterns.

A strong transition candidate understands that safety is architectural. Legacy awareness of responsible-AI principles transfers, but AI-103 readiness requires applying those principles to agent workflows and production operations.

Diagnose CI/CD and change-management fluency

An AI solution changes in more ways than conventional application code. Prompts change, model deployments change, indexes are rebuilt, tool schemas evolve, evaluation datasets grow, and safety policies are adjusted. A readiness matrix should ask whether you can treat these artifacts as controlled changes rather than manual portal configuration.

Design a release path with development, test, and production environments. Decide which configuration belongs in source control, how secrets are separated, what automated checks should run, how evaluation gates a release, and how rollback works if a new model or prompt degrades quality. Include infrastructure and role assignments where appropriate rather than assuming environments are identical.

Candidates with strong DevOps habits may discover that this is a transferable strength even if it was not central to their AI-102 preparation. Record it as such; the matrix should capture all relevant experience, not only exam-branded learning.

Diagnose troubleshooting by symptom-to-layer mapping

Create a simple symptom matrix. If answers are irrelevant, investigate retrieval and context before changing model size. If tool calls are correct but actions fail, inspect permissions, API contracts, and downstream errors. If latency spikes only on agent workflows, inspect orchestration depth, tool latency, retries, and model calls. If only some users cannot retrieve documents, inspect identity propagation and authorization filtering.

Then reverse the exercise: deliberately break one layer and predict the observable symptoms. Remove search permissions, corrupt an index, change a tool schema, reduce a quota, or introduce a stale endpoint. The ability to predict consequences is stronger evidence than remembering a troubleshooting checklist.

This skill is especially valuable for transition candidates because old service familiarity can lead to premature diagnosis. Current systems have more interacting layers, so readiness requires locating the failing boundary before prescribing a fix.

Convert the matrix into a seven-day repair cycle

Once the matrix exposes gaps, choose a small set of high-risk rows for one week. Day one should reproduce the weakness with a diagnostic scenario. Days two and three should build or repair the capability. Day four should inject faults. Day five should explain the design and tradeoffs without notes. Day six should solve a mixed scenario that combines the skill with security or operations. Day seven should rescore using fresh evidence.

This cycle keeps preparation active. It also makes progress measurable: a row moves from Level 1 to Level 2 only when you can independently execute the task, not because you spent a certain number of hours studying it. If the score does not improve, change the practice method rather than simply repeating the week.

Over several cycles, the matrix should become less crowded. That is the point. Final review should focus on a manageable set of uncertain decisions, while strong areas are maintained through mixed scenarios rather than endlessly reread.