AI-103 tests the work of an Azure AI developer
AI-103 belongs to Microsoft Certified: Azure AI Apps and Agents Developer Associate. Its intended audience builds, manages, and deploys AI applications and agents with Python and Microsoft Foundry. A useful preparation program should therefore produce engineering evidence rather than a long list of memorized Azure product names. You need to choose a model, connect resources securely, ground answers in accessible data, evaluate application behavior, manage risk, and build multimodal workflows that remain understandable when they fail.
Microsoft’s AI-103 objectives list five domain ranges as of April 16, 2026: plan and manage an Azure AI solution (25–30%); implement generative AI and agentic solutions (30–35%); implement computer vision (10–15%); implement text analysis (10–15%); and implement information extraction (10–15%). These ranges do not guarantee a certain number of questions. Microsoft documents a 120-minute assessment and a passing scaled score of at least 700. Check its site again when registering, because examination details can change.
Microsoft retired AI-102 on June 30, 2026, while AI-103 measures a newer Foundry-centered set of engineering responsibilities. Someone moving from retired AI-102 preparation to Microsoft AI-103 should separate commercial practice products from the updated official Microsoft skills guide before deciding which engineering topics require new study. The AI-102 transition explains what changed; AB-100 business architecture is a separate role with a different emphasis. This study sequence concentrates on work a developer should be able to design, build and evaluate rather than using exam names as substitutes for technical skill.
Build one project to connect the largest domains
Choose a business case whose requirements expose genuine engineering decisions. An internal policy assistant can answer employee questions using a versioned document collection, prepare a support-ticket proposal, and escalate a sensitive decision to an authorized staff member. Design it so ordinary policy lookup is read-only, while ticket creation requires an identity check and a separate approval step. The difference between retrieving information and changing business state provides a testable agent boundary.
Begin with an architecture decision record. Specify the application front end, user authentication, Foundry project, model deployment, search index, storage of conversation and approval state, business tool endpoint, network boundaries, monitoring, and recovery plan. Name an alternative you did not choose and the evidence behind the decision. A candidate who can explain why a deployment is appropriate has learned more than someone who can only repeat the wizard steps.
Build the smallest useful system first: answer one policy question, return a citation to a source revision, and refuse when evidence is missing or user permissions exclude that source. Then add an agent that may propose a ticket but cannot submit it until the application authorizes the operation. This progression covers service choice, model integration, grounded generation, tool contracts, responsible AI, and operational monitoring without requiring multiple artificial demo applications.
Prove model selection, projects, and identity in Python
Learn the difference between a Foundry resource, a project, a model deployment, an inference API, and an agent runtime. An application that can connect to a project does not automatically have permission to search restricted material or invoke an external system. Test at least two roles and verify that retrieved results change appropriately. Server-side authorization—not model-generated language—determines what the application can access.
Use a current version of the Foundry SDK and authenticate with Microsoft Entra identities when suitable. Pin dependencies, keep project endpoints in configuration, and never place secrets in checked-in examples. Understand how a deployed model is called from Python, how the response is validated, how errors and rate limits are handled, and how logging avoids collecting unnecessary personal information.
Compare at least two model candidates on the same evaluation examples. Include a simple lookup, contradictory policy amendments, specialist vocabulary, multilingual content, a malicious retrieved instruction, and a structured JSON result. Measure groundedness, response quality, latency, cost per successfully resolved query, and refusal behavior. Small models may be faster or cheaper on bounded tasks, while larger ones may help with conflicting evidence. Treat observed task success as the criterion rather than assuming model size predicts reliability.
Design retrieval that exposes its evidence
Put short, versioned policy documents in a searchable index and include document IDs, effective dates, access metadata, and source locations. Run an exact keyword query against an equipment code; a vector query against an unfamiliar paraphrase; and a hybrid query against a question containing both. Azure AI Search can combine keyword and vector results, while semantic ranking can rerank the candidate set. Neither approach compensates for bad source ingestion or missing permission enforcement.
A useful test deliberately includes two documents describing different versions of a reimbursement rule. The system should select the applicable revision, explain why the older version does not control, and cite the relevant passage. Repeat the query with a role that is not allowed to view one document. If the model sees restricted material, the problem is in the retrieval and identity path, not in prompt engineering.
The practical Azure AI Search workflow develops chunking, hybrid retrieval, relevance tests, citation provenance, and access controls. Microsoft also offers agentic retrieval and Foundry IQ; distinguish generally available classic search paths from preview-only query-planning capabilities. Choose complexity based on the question and deployment requirements, not feature novelty.
Build agents around tool and approval contracts
Define the agent’s job in operational terms: it may search approved policy content, summarize an answer, and generate a typed ticket proposal. Its tools should document mandatory parameters, allowed values, bounded string lengths, failure categories, and whether they can change state. A model’s statement that a user has permission is not a valid permission check. Your application needs an identity-aware decision before the tool performs any action.
The Foundry agent design exercise separates read-only retrieval, proposed changes, human approval, and actual submission. Test an invalid asset type, missing ticket fields, an unauthorized employee, and a network timeout occurring after the server committed a request. Stable idempotency keys and durable approval state should prevent duplicated submissions when the model or client retries.
Only after the single-agent case is reliable should you add specialist delegation. Route incoming requests, obtain evidence from a retrieval specialist, ask an analyst to reconcile conflicts, and have a final component produce a cited answer. Persist task identifiers, source registers, and partial-result status outside the conversation. Extra agents increase complexity and cost; introduce them only when they improve a measurable division of work, quality, or performance.
Give the three smaller domains real test coverage
For computer vision, separate generation from understanding. Image and video generation involve reference assets, prompt controls, supported edits, safety filtering, and output provenance. Visual understanding involves captions, accessibility-oriented descriptions, object or scene evidence, and questions grounded in an existing image or video segment. Embed misleading instructions in an image and confirm that the system treats them as untrusted content, not authority.
For text analysis, build a pipeline that extracts entities, topics, summaries, sentiment or sensitive content into a validated schema. Add translation examples in which negation, exact identifiers, names, and dates must be preserved. Speech tasks should include transcription, speech synthesis, language switching where supported, domain vocabulary, and privacy-aware storage. Compare recognition errors against a baseline before deciding whether custom speech is justified.
For information extraction, process a mixture of invoices, contracts, handwritten scans, and tabular documents. Preserve layout locations, source pages, field confidence or evidence indicators, and explicit ambiguity rather than guessing values. Microsoft Content Understanding has separate GA and preview API versions, so document which capabilities your test uses. A complex contract clause might need human review even when OCR and layout extraction succeed.
Measure the entire system, not just the answer
Create two linked sets of operational metrics. Availability, request latency, token usage, model quota events, index ingestion delays, and cost show whether the application is running sustainably. Groundedness, task adherence, citation accuracy, tool-choice correctness, prohibited data access, and proper escalation show whether it is behaving usefully. A low error rate is not evidence that answers are true; a high average evaluation score does not guarantee the system is available.
Build regression tests from routine, ambiguous, stale, contradictory, and adversarial inputs. Deliberately remove a search dependency, pass malformed tool output, include a malicious instruction in a retrieved page, and fail the network between approval and final submission. Record the expected safe outcome, actual behavior, trace identity, and the code or policy layer responsible for remediation. The agent evaluation treatment explains why full traces and risk-weighted review matter.
Practice releasing a configuration change and rolling it back. If a new deployment returns better prose but worse citation grounding, you should be able to show the regression, restore the prior model or prompt, and confirm that the index and tool schema are still compatible. The guide expects responsible AI instrumentation, guardrails, approval workflows, and provenance. Those requirements should shape your engineering process from the first lab.
Judge readiness with an unfamiliar scenario
For the final rehearsal, imagine a multilingual permit-assistance application that retrieves public rules, extracts details from uploaded forms, answers a visual question about a site photograph, and prepares a review request for municipal staff. Describe the Foundry resources, model choices, identity boundaries, retrieval plan, OCR and content understanding, speech or translation path, human review, safety controls, operational budget, and measurable acceptance tests.
For each official domain, identify one practical feature implemented, one negative test deliberately introduced, and one observable outcome that proves correct behavior. If you only know which Azure product name appears in a diagram, revisit the lab. If you can defend a trade-off, test failure modes, and recover safely, you are approaching the real developer skills that AI-103 is intended to measure.
Recheck the current issuer guide before booking because service availability, preview status, SDKs, and exam objectives evolve. Keep a pinned environment, dated source references, a small evaluation dataset, and redacted architecture notes. The goal is not to imply a guaranteed passing score; it is to build a reproducible engineering record that remains useful on a real project.