Microsoft AI-103 Exam Guide: Domains, Format and Study Plan

AI-103 is a developer’s exam, not a shopping list of Azure AI products. Microsoft expects candidates to connect a requirement to a working architecture: choose the right Microsoft Foundry capability, implement retrieval or an agent, secure access to data and tools, then prove the result behaves acceptably. Someone who can identify every service name but cannot explain where authentication, evaluation, deployment or failure handling belongs will struggle with the decisions this blueprint makes important.

The current Microsoft AI-103 exam, Developing AI Apps and Agents on Azure, leads to the Azure AI Apps and Agents Developer Associate certification. It assumes practical Python application experience as well as familiarity with Azure AI services. This guide separates Microsoft’s published exam facts from an independent preparation plan, then uses one realistic application to connect the major objectives without treating each service as an isolated fact to memorize.

What the certification expects you to build

An Azure AI app often begins with an ordinary business problem: employees need answers from internal procedures, customers need help completing requests, or a document-processing team wants accurate fields without manual retyping. The AI component is only one part of that system. Data must be retrieved under the user’s permissions, the model must produce a useful response, tools must be constrained to authorized actions, and the application needs a failure path when any of those stages goes wrong.

Microsoft describes the AI-103 audience as engineers who build, manage and deploy Foundry-backed apps and agents. The corresponding work reaches beyond prompting. It includes application code, model deployments, data ingestion and search, durable application state, networking, identity, evaluation and release management. A helpful starting point is to practice matching Foundry services to workload requirements rather than asking which service sounds most powerful. In many scenarios a predictable pipeline is better than an autonomous agent; in others the ability to choose a tool at runtime genuinely matters.

The previous Azure AI Engineer exam, AI-102, was retired by Microsoft on June 30, 2026. AI-100 had already retired in June 2021. Some older tutorials remain useful for understanding language, vision, search or document extraction, but their exam weights and technology assumptions should not be copied into an AI-103 study schedule. AI-103 gives explicit weight to modern agent workflows, Foundry projects, multimodal generation, safeguards and production evaluation. The replacement is a different skills blueprint, not merely a renamed test.

Exam format, scoring and practical prerequisites

Microsoft’s current exam page provides 120 minutes for the assessment. The published passing standard is a scaled score of at least 700; it is not a claim that candidates need 70 percent of a fixed question count. Microsoft displays exam pricing based on the country or region in which the exam is proctored; verify the fee shown during your own registration rather than relying on a fixed price. Available languages, scheduling arrangements, retake limits and accommodations are controlled by Microsoft and its testing provider, so check the registration page for the version that applies to your appointment.

The official description does not guarantee a single number of questions or an unchanging mix of question types. Candidates should be comfortable reading scenario-based requirements and may encounter interactive components. Microsoft offers an exam sandbox and learning paths. Microsoft currently lists an official AI-103 Practice Assessment through AI Skills Navigator, which requires you to sign in before launching it. Check that page for changes, and treat third-party practice questions as independent study material rather than official exam content. Before sitting the test, verify that the published study guide still carries the same revision and objective weights; Microsoft’s exam outlines can change.

There is no benefit to memorizing a headline product name without the ability to explain its runtime responsibilities. The experience that matters is using Python to connect to a Foundry project, calling deployed models or agents, understanding basic API and SDK contracts, and recognizing what happens when retrieval fails or a tool returns invalid data. Familiarity with identity-based access, environment configuration and safe error handling makes the technical objectives more concrete.

The five domains and how they fit together

These ranges are not five independent study silos. The first two domains together represent over half the exam’s assessed skills, and they underpin much of the remaining work. A document agent may depend on extraction, retrieval, identity, model selection and tracing at the same time. A visual support assistant may use vision to interpret a photo, an agent to decide which tool is needed, and a safeguard to prevent an unauthorized operation.

Planning and management is largely about choosing the right operational boundary. Can a small model meet the business threshold? Must a project reach a private search index? Which identity has permission to run a retrieval query? How will the team detect rising cost or declining output quality? Study model selection for real workloads alongside private networking and managed identity; they answer different halves of the same production decision.

Generative apps and agents bring together model calls, retrieval, tool contracts, conversation state and multi-step behavior. It is worth understanding exactly when hybrid retrieval and grounding solve a knowledge problem, when agent tools or memory solve a state or action problem, and when a deterministic workflow should retain control. Evaluate the process, not only the polished final sentence.

Vision, language and extraction put different output contracts around different inputs. A generated image needs creative quality and safety checks; a caption needs fidelity to visual evidence; a speech pipeline needs timing and transcription accuracy; a financial document may need fixed fields with page-level provenance. The relevant reading on multimodal vision workflows, text, speech and translation, and Content Understanding and document extraction explores those distinct failure modes.

Practice one end-to-end application rather than twelve disconnected demos

A useful study project is an internal service desk assistant that answers policy questions and prepares requests for human approval. It can be small enough to build with a test corpus, yet rich enough to expose decisions across the AI-103 outline. Begin with a deliberately narrow requirement: employees ask for the latest equipment-return policy and may request a return authorization. Reading the policy is allowed; creating the authorization requires an approval step. The application must never treat a retrieved document as permission to write a business record.

In the first version, index a handful of policies and make their effective dates, department scope and document permissions explicit. Compare lexical search with vector and hybrid queries. Ask one question that the corpus answers directly, another with conflicting old and new policies, and a third that the corpus cannot answer. The correct solution is not always a confident paragraph: sometimes the appropriate behavior is to identify the missing evidence and stop. Record which passages were retrieved, which filters were applied and whether the answer remained grounded.

Next, give a Foundry agent one narrow read-only lookup tool and a separate action that prepares a draft return request. The action must validate input types and require an independent approval before submission. Keep the approval result in durable application storage, not only in the conversation transcript. Observe what happens when the tool times out, the model supplies a missing field, or an employee asks the agent to skip the required approval. A robust agent should expose a bounded failure path instead of inventing success or retrying a write operation without knowing whether it committed.

Add one document-processing case to this project. A scanned receipt introduces OCR, layout and field extraction; the output should carry enough provenance for a reviewer to inspect the value. Adding one speech interaction introduces transcription, interruption and audio privacy issues. The point is not to build a complicated commercial product. It is to see how the same application requirements force decisions about multiple exam domains and reveal why each Azure component exists.

Finally, instrument the workflow. Log safe trace identifiers, model and prompt versions, retrieval result references, tool status and request latency. Build a modest evaluation set with successful questions, unsupported requests, malformed tool parameters and hostile text placed inside a retrieved document. The comparison between first and later versions should show what improved, what regressed and which control detected the problem. This connects tracing and evaluation to GenAIOps and controlled releases without confusing operational metrics with answer quality.

A four-week study plan organized around evidence

The following schedule is editorial advice, not a timetable mandated by Microsoft. It assumes the reader can already write basic Python and has enough Azure access to create test resources. Someone new to Azure identity or APIs should extend the foundation before treating the four weeks as a deadline. Divide each week between the official objective list, a hands-on exercise and a short written analysis of the trade-offs encountered.

Week 1 — services, models and deployment. Build a Foundry project, inspect the models available in the relevant region and compare at least two suitable deployments on the same representative prompts. Write down why the smaller or larger model meets the task threshold. Trace where endpoint authentication, project permissions and cost controls enter the design. Read a network diagram and distinguish private inbound access from private egress. End the week with an architecture decision: choose components for an FAQ app that uses confidential documents and explain which team owns retrieval, security and monitoring.

Week 2 — RAG, agents and safeguards. Turn a small document collection into a permission-aware retrieval pipeline. Test stale content, query filters and missing-answer behavior. Add a simple agent with one read-only tool, then a separately authorized action. Compare an agent-controlled sequence with a deterministic two-stage workflow. Document the effect of tool errors, excessive retries, conversation history and long-term memory. Study responsible-AI guardrails in relation to a concrete unsafe action, rather than memorizing a list of filters.

Week 3 — multimodal and extraction decisions. Process a scanned document with OCR and preserve sections, fields and source references. Build a language workflow that extracts a predictable JSON record and test ambiguous inputs. Compare image description against structured visual extraction, then map a text-to-image or image-editing requirement to the controls supported by its model. For video, be able to explain reference inputs, asynchronous job states, available editing options and safety checks. Do not assume every deployment supports every generation feature.

Week 4 — evaluation and exam decisions. Return to the original Foundry project and build a repeatable evaluation set. Measure retrieval quality separately from generation quality, and tool selection separately from tool execution. Change one variable—prompt instructions, model, retriever or workflow—and compare results before and after. Practice explaining failed scenarios in a few sentences: the requirement, the correct control, why the tempting alternative is weaker and what evidence would verify the fix. Revisit the official skills guide for under-practiced objectives rather than spending the final week repeating topics that already feel comfortable.

Use a simple readiness ledger with columns for objective, working example, failure case and evidence of mastery. A topic is not really closed because a video tutorial was watched; it is closed when the candidate can implement or explain it without relying on a memorized product description. This approach also exposes hidden weaknesses: someone may understand RAG conceptually but be unable to explain identity filtering or test a tool contract.

How to read AI-103 scenario questions

Good architecture answers begin by classifying the requirement. Consider an application that must answer customers using recently updated internal shipping rules, then create a change request only after approval. There are at least three separate responsibilities: retrieve authorized and current policy evidence, compose a grounded answer, and perform a controlled action. A question may mention an agent, but that word does not settle the architecture. If each stage follows a known sequence, a deterministic workflow with a model inside it may be clearer and safer than allowing a supervisor agent to decide every transition.

Now change one constraint: the employee sometimes asks for comparisons across many policies and needs the system to choose among several specialized tools. Agent-driven decomposition may become useful. The design still needs permissions, structured handoffs, a limit on delegation and an escalation path. Understanding the trade-offs in multi-agent orchestration helps when the question is genuinely about specialization rather than basic data lookup.

Use the same method for security and observability scenarios. If an agent cannot reach a data source, separate networking from identity and role assignment before selecting a fix. If its answers are unsupported, determine whether evidence was absent, retrieval was weak or the model ignored good evidence. If response times rise, inspect spans for search, model and tool calls rather than assuming a new model is necessary. Exam questions often reward the smallest corrective action that directly addresses the stated failure mode.

Two options may both technically work. Prefer the one that preserves the requirement with fewer unnecessary services, clearer authorization and a diagnosable failure path. When an answer depends on model, region or preview availability, treat that as a condition to validate; an answer that assumes universal support is rarely a sound production recommendation.

Checking readiness without misleading shortcuts

Practice questions are useful for identifying which constraint matters, but they should not become a substitute for implementing the core patterns. Ask why each wrong option is wrong, which architecture boundary it violates and what change in the scenario would make it defensible. Build original scenarios from the Microsoft blueprint rather than treating a recalled practice question as an official exam item. Keep a list of repeated errors: missing retrieval authorization, confusion between conversation state and durable business state, unverified model parameters, or equating a fluent answer with a grounded one.

Before scheduling, check Microsoft’s current registration page for price, language, accommodations, exam duration, retake policies and the version of the study guide in force. Reserve time to explore the official exam sandbox so that interface mechanics are not new on the day. Do not rely on an unsupported fixed question count or assume that retired AI-102 preparation material maps directly to AI-103. If your personal skills ledger still contains unresolved implementation tasks, spend another study session on those tasks instead of trying to compensate with more memorization.

The most useful final readiness question is simple: can you take a new business scenario, identify which components require deterministic control, and explain how to test the finished application for correctness, safety, cost and recoverability? That capability matches the real engineering work behind AI-103 better than a list of service acronyms ever will.