Microsoft retired AI-102 and the Azure AI Engineer Associate certification on June 30, 2026. The successor exam, AI-103: Developing AI Apps and Agents on Azure, reflects a different kind of engineering responsibility. Candidates still need to understand Azure AI services, but they must also design applications that retrieve evidence, invoke tools, evaluate results, enforce permissions, and remain observable after deployment.<\/p>\n
That shift matters to anyone returning to Azure AI after studying AI-102. An old computer-vision lab might still teach valuable techniques, while an old objective checklist could lead you away from the current examination. The question is not how much previous material you can reuse; it is whether that material helps you make the decisions expected of an AI-103 developer.<\/p>\n
Start by separating stable skills from examination-specific details. Data preparation, identity, model selection, search relevance, application integration, responsible AI, and operational troubleshooting still matter. Service names, exam weights, and the assumptions behind old exercises need to be checked against the current AI-103 outline. The AI-102 to AI-103 transition<\/a> is most useful when treated as a mapping of responsibilities rather than a list of renamed products.<\/p>\n Make three columns in a skills inventory: transferable, changed, and newly important. An identity-based storage-access exercise may be transferable, while the implementation of a generative application with retrieval and tools may need substantial new work. Give each entry a concrete test. For example, do not mark retrieval as familiar merely because you once created an index; verify that you can explain why a retrieved passage is relevant and what happens when that passage is wrong.<\/p>\n This approach also protects against a subtle study mistake: recognizing old terminology and assuming that recognition proves competence with a newer architecture. If you cannot describe the application boundary, the controlling service, and how you would verify the outcome, the skill is not yet ready to carry into a new exam.<\/p>\n The planning and management domain brings together model choice, Foundry projects, deployment, data, identity, networking, costs, monitoring, and responsible AI<\/a> controls. Those decisions should begin with a workload: what must the application produce, which information may it use, how quickly must it respond, and which operations must remain under human control? A model that performs well in a demonstration may still be unsuitable if it cannot satisfy the workload’s security, latency, or operating constraints.<\/p>\n Use one small Foundry application to make these trade-offs visible. Record the model and deployment choice, the source of application data, the identity used to access it, the observability signals, and a cost boundary. Then change a single constraint, such as private connectivity or reduced tool permission, and explain what else needs to change. The AI-103 architecture roadmap<\/a> can help identify responsibilities your project has not yet exercised; Microsoft\u2019s published objectives remain the final reference for exam coverage.<\/p>\n Be especially careful about treating a successful response as an end-to-end pass. A model response can appear correct even when an application has skipped authorization, retrieved irrelevant data, or failed to record the evidence an operator would need to diagnose a regression.<\/p>\n Generative AI and agentic solutions carry the largest share of the source AI-103 blueprint. The candidate needs to understand more than prompting: retrieval-augmented generation, tool definitions, workflow boundaries, state, memory, evaluation, and the conditions that justify multiple agents. The central design question is which operations a model can propose and which operations the application must validate or approve.<\/p>\n Build an agent that answers questions using a constrained knowledge source and can call one narrowly scoped tool. Give the tool an explicit purpose and permission boundary. Test a normal request, a request for unavailable evidence, and a request that would exceed the tool’s authority. Compare what the model proposes with what the application actually permits. That contrast reveals why reliable generative AI and agents<\/a> require orchestration and controls beyond a successful prompt.<\/p>\n A second agent is not automatically an improvement. Introduce one only if separating responsibilities clarifies access control, reduces unnecessary context, or improves verification. Otherwise the additional handoff can make failures harder to trace. Being able to defend a simple single-agent design is just as important as recognizing a valid multi-agent pattern.<\/p>\n AI-103 also covers getting usable evidence into applications. Document ingestion, OCR, structured extraction, indexing, semantic and vector search, hybrid retrieval, and grounded generation connect several services into one information path. Failure at any stage can produce a polished but unsupported answer. The diagnosis therefore needs to distinguish poor extraction from poor retrieval and poor generation.<\/p>\n Use a small document collection with known answers. Test a query that should retrieve one specific source, a query that needs evidence from two sources, and a query for which the collection has no answer. Examine the retrieved items before judging the generated response. If the grounding fails, change the chunking or retrieval configuration one variable at a time; do not immediately blame the model or compensate with a more elaborate prompt.<\/p>\n For structured extraction, define what a downstream system requires and how missing or uncertain fields will be handled. A schema-compliant response is only the first check. The extracted value should be checked against its source and routed safely when confidence or completeness is insufficient.<\/p>\n Visual AI is no longer limited to recognizing categories in images. The source outline includes multimodal understanding, image and video generation, visual question answering, content understanding, and related safety responsibilities. A useful exercise is to process a visual document, extract a small set of facts, produce a structured result, and show which evidence supports it. Ambiguous images and unsafe inputs should have defined failure behavior instead of silently producing confident outputs.<\/p>\n Text analysis, translation, summaries, entity extraction, sentiment, speech, and other language capabilities also need application context. A standalone demo may prove that an endpoint returns a result, but a production workflow asks whether the output is consistent enough for its next consumer. Build checks for formatting, prohibited content, missing values, and the consequences of an incorrect classification or extraction.<\/p>\n Do not devote the same time to every feature simply because it appears somewhere in older notes. Select exercises that expose the governing design choice: which model or service fits, what evidence is sufficient, where the application boundary lies, and how the operator can recover from an incorrect result.<\/p>\n Operations are not a final decoration on an AI-103 project. The application needs signals for model quality, retrieval relevance, safety, latency, token consumption, tool calls, rejected permissions, and changes in behavior after a deployment. A conventional uptime check can remain green while grounded answers deteriorate or unsafe tool requests increase.<\/p>\n Define a small evaluation set before changing the system. Include expected grounded responses, unanswerable questions, and requests that must not trigger tool activity. Run the same tests after changing a prompt, retrieval source, model, or permission. Compare both quality and operating consequences. The broader field of AI application observability<\/a> connects these signals to the decisions a team can actually make.<\/p>\n Security checks should distinguish model instructions from enforceable application controls. A prompt can ask an agent to respect a boundary; the service receiving the tool call still needs to authorize the real user or workload. Document the approval path, the audit evidence, and what happens after a rejected action, not just what the model was told to do.<\/p>\n Instead of completing every tutorial, finish one capstone that joins a Foundry deployment, a governed identity, retrieval, a constrained agent tool, structured or multimodal input, evaluation, and monitoring. Deliberately introduce a bad retrieval result, revoke a test permission, and change one model or workflow condition. A candidate ready for scenario questions can locate the fault, explain the trade-off, and verify that the correction did not break another part of the application.<\/p>\n Use practice questions after doing the work, not in place of it. A missed question should produce a precise finding: unfamiliar service behavior, wrong control boundary, weak evidence, or a misunderstood dependency. When comparing Microsoft AI-103<\/a> exam resources, prefer exercises that make you defend the choice and reject plausible alternatives over material that rewards memorizing a product name.<\/p>\nPlan and manage the AI application as a system<\/h2>\n
Generative applications and agents change the design questions<\/h2>\n
Grounding and information extraction are part of correctness<\/h2>\n
Computer vision and language tasks belong in application workflows<\/h2>\n
Evaluation, security, and observability cross every domain<\/h2>\n
Make AI-103 readiness an evidence-based decision<\/h2>\n