What the AI-103 certification actually tests
Microsoft’s AI-103 exam, Developing AI Apps and Agents on Azure, is associated with the Microsoft Certified: Azure AI Apps and Agents Developer Associate credential. It is an engineering-focused assessment for people who build and operate AI-enabled applications using Microsoft Foundry and supporting Azure services. The listed candidate profile expects practical experience developing applications with Python and familiarity with generative AI, traditional AI capabilities, and Azure development services.
The distinction between knowing an AI service and engineering a working application matters throughout the blueprint. Selecting a language model does not, by itself, create a trustworthy assistant. A usable solution also needs an identity and permissions model, reliable retrieval, error handling, evaluation, monitoring, and rules about when a human must approve an action. Likewise, running optical character recognition on a document does not establish that extracted values are complete, current, or safe to act on. AI-103 expects candidates to reason about these connections rather than treat service names as isolated flash cards.
Microsoft’s published skills outline uses five domains. Plan and manage an Azure AI solution accounts for 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 are approximate domain weights, not a promise about a fixed number of questions per service or a checklist of every possible task. Microsoft also cautions that its exam examples illustrate the assessed skill, and that widely used preview functionality can appear alongside generally available features.
Start with an evidence table linking each of Microsoft’s five measured domains to one technical decision you can reproduce: choose a model deployment for a stated workload, ground an agent on authorized current documents, test one denied tool action, compare vision generation with source-based interpretation, and validate a noisy voice transcript or extracted invoice. Record expected failures as well as successful outcomes. The third-party AI-103 practice questions may help challenge that reasoning, but check answer explanations against the current Microsoft Learn study guide and actual service behavior. A commercial question set does not replace the official examination requirements or hands-on engineering tests.
Plan, secure, and operate a Microsoft Foundry solution (25–30%)
The first domain begins before a prompt reaches a model. Given a task and constraints, an engineer must choose appropriate models, model deployment options, and supporting services. A concise structured extraction operation may not call for the same model, response budget, or infrastructure as an assistant that interprets images and uses several tools. Retrieval and indexing decisions also belong at this planning stage: where will trusted knowledge live, how will it be updated, and how will an application recover when relevant evidence is missing?
A useful practice scenario is an internal policy assistant supporting a distributed service team. Its source documents have owners, effective dates, access groups, and changing versions. Before creating the assistant, specify which employees may query which policies, where the search index is hosted, how new policy revisions enter the index, and what the agent should do when a retrieved passage conflicts with a newer record. An architecture sketch that shows only “user → model → answer” omits most of the engineering decisions this domain rewards.
Microsoft Foundry projects also require deployment and operational choices. The current syllabus explicitly names model and agent deployments, infrastructure, CI/CD integration, cost footprints, rate limits, and scaling. Design a process that can distinguish development from production, promote a tested configuration deliberately, and roll back a breaking change. For each deployment, record which model version and prompt configuration were evaluated, because a later behavior change is difficult to investigate without that identity.
Authentication and authorization need their own design. Prefer scoped identities and appropriate Microsoft Entra roles to a shared secret with broad privileges; use private connectivity where the data and operating environment require it. A person allowed to invoke a model should not automatically receive permission to change a deployment, query every knowledge store, or authorize business transactions. The published Microsoft SC-100 material on securing AI workloads provides a complementary architecture perspective, but a security-architect exam and AI-103 measure different jobs.
Monitoring is more than a dashboard of token counts. Track request failure patterns, rate limiting, end-to-end latency, retrieval relevance, model safety signals, document-ingestion quality, and the business action that followed a response. Separate telemetry that helps operators diagnose behavior from sensitive prompt or document content that should not be collected by default. Log enough evidence to reconstruct significant outcomes without treating every customer message as unrestricted monitoring data.
Implement generative AI applications and agents (30–35%)
The largest skills domain brings model applications and agents together. A conventional generative application transforms a controlled input into an output, potentially enriched through retrieval. An agent adds explicit steps such as calling functions, using knowledge sources, coordinating workers, maintaining conversation state, and requesting permission before acting. The practical difference is not whether the interface looks conversational; it is which actions the application allows a model to request and how those actions are validated.
Consider a support assistant asked whether a customer is eligible for a credit. A text-only answer generator can summarize a policy, but it should not be allowed to infer that a refund happened merely because it proposed one. A reliable agent would identify the appropriate policy version, retrieve the customer’s permitted account facts, evaluate the eligibility rule, and return a proposed outcome for the authorized service to confirm. It should preserve the transaction identifier and tool result, handle timeouts without creating duplicate credits, and escalate ambiguous cases. This is an editorial example, not an official AI-103 examination scenario or an executed production workflow.
Retrieval-augmented generation, or RAG, is central to this domain. The engineer must distinguish the user’s question from the evidence retrieved to answer it. Document chunking, indexing, search filters, vector and keyword retrieval, and source citations all affect whether the response can be trusted. A retrieval pipeline can fail even when the model sounds confident: a chunk may have lost its effective date, a permission filter may be wrong, or the top search result may contain an obsolete instruction. Test these conditions explicitly instead of relying only on fluent sample answers.
For agents, define tool interfaces with narrow input contracts, clear outputs, authenticated execution, and explicit failure signals. A tool that can read policy documents should not silently gain access to payment initiation. An orchestration workflow needs a defined rule for worker failure, recovery, and partial completion; a second agent’s confident summary is not proof the first agent completed its work. Model and agent evaluations should include inaccurate retrieval, unauthorized tool requests, incomplete tasks, fabricated citations, and conversations where human approval is required.
The guide also calls out model and application optimization: adjusting generation settings, using evaluation approaches and self-critique, tracing behavior, assessing safety, and combining models, deterministic rules, or workflow components where appropriate. None of those methods justifies skipping independent checks. Compare new versions against a stable test set, inspect exceptions rather than average scores alone, and choose improvements based on real outcomes rather than the number of autonomous steps produced.
Build multimodal image and video workflows (10–15%)
Computer vision in the AI-103 outline includes both understanding media and generating or editing it. Those are different engineering problems. An image-generation workflow turns a prompt and optional reference media into a visual artifact, with controls for content and edit boundaries. An understanding workflow examines actual image or video evidence and returns observations, captions, answers, or structured interpretations. One cannot prove the accuracy of the other.
For example, an equipment-inspection assistant might receive photographs of a damaged device. It should distinguish what is actually visible from what would require an additional photograph or a technician’s inspection. When generating alt text, describe the relevant visual content in a way that helps the intended reader; avoid asserting an unseen cause of damage. In a multi-image workflow, track which observation came from which image rather than merging captions into an untraceable composite claim.
The current study guide covers visual question answering, video-segment interpretation, captions, object or region identification, and Microsoft Content Understanding workflows. It also lists media generation, inpainting and other editing approaches. Practice by designing one understanding workflow and one separate controlled editing workflow. State input format, model capability, expected output, quality checks, and the limits of what can be inferred.
Visual content can also carry malicious instructions. Text embedded inside an image is task data, not a trusted instruction to change the agent’s behavior. Build a test case in which a photographed document contains an instruction that conflicts with the application’s approved task, and confirm the application still follows its policy. Safety filtering, human review, and traceable evidence matter for multimodal systems just as they do for text agents.
Use language and speech capabilities with explicit quality checks (10–15%)
The text analysis domain includes extracting entities and topics, summarization, structured JSON, sentiment or tone detection, safety and sensitive-information handling, and translation. A general-purpose model can perform some of these tasks, while Foundry Tools can provide more specialized capabilities. The engineering decision is to compare the needed output contract, supported languages, privacy constraints, repeatability, and evaluation method rather than assume a single model should perform every step.
Suppose a service department wants summaries of messages arriving in several languages. The team should define what information must survive summarization, whether translation happens before or after analysis, how unsupported languages are detected, and which fields are mandatory in a structured output. An apparently valid JSON response can still be wrong. Test whether entities have been confused, negation has been lost, and sensitive data has been reproduced unnecessarily.
Speech adds another source of uncertainty. A voice assistant may convert speech to text, reason over the transcript, and speak a response; another pipeline may translate an utterance between languages. Transcription errors can change names, amounts, or intent, particularly in noisy recordings or mixed-language conversations. Preserve confidence indicators or explicit uncertainty where supported, obtain confirmation before consequential actions, and measure the latency added by audio processing. The exam guide describes speech as an agent modality, not only a standalone dictation feature.
Turn documents into grounded, structured information (10–15%)
Information extraction builds on retrieval but asks a more specific question: what trustworthy data can be obtained from a document or media collection, and how should its uncertainty be represented? An OCR stage identifies characters and layout; a complete extraction pipeline may also identify document type, locate fields, parse tables, reconcile repeated values, produce structured records, and retain links back to source evidence.
Imagine an accounts-payable workflow that receives a small collection of synthetic invoices and credit notes. A useful solution distinguishes invoice number from purchase order number, separates total due from tax and subtotal, and refuses to treat a missing supplier identifier as a successfully extracted value. A scanned credit note should not be silently converted into a positive payable amount. If an image is illegible, the system must return an explicit exception rather than inventing a plausible number.
Microsoft’s current blueprint names ingestion and indexing of documents, images, audio and video; semantic, hybrid and vector search; enrichment skills; RAG ingestion using OCR where appropriate; and Content Understanding analyzers that can produce structured or Markdown output for downstream reasoning. Connect each extracted field to the page, region, or source segment that supports it. Then test the downstream workflow: does a retrieval agent know which extracted representation it is using, and can an auditor trace a disputed value back to the original?
A practical evaluation set should contain documents with swapped columns, duplicated invoice numbers, blank fields, rotated scans, and conflicting revisions. Measure field-level accuracy and the cost of human exceptions, not only how often the system emits a syntactically valid record. Extraction quality depends as much on validation and source fidelity as it does on the model used for initial recognition.
One end-to-end preparation exercise
The five domains can be explored without pretending that every task belongs in one monolithic application. Build a small, entirely fictional service-request environment with fabricated customer identities and sanitized sample documents. Start with an architecture decision sheet: who can view each source, which model and tools are deployed, what costs and quotas matter, and which operations require approvals. Use Microsoft Foundry and Azure services appropriate to the documented task, but keep each integration independent enough to test.
Next, create a knowledge index containing two versions of a fictional service policy with different effective dates. Test keyword and vector retrieval against questions that require the correct version. Then build a constrained agent that answers only with retrieved evidence and proposes, rather than independently executes, a consequential account action. Add a deliberately failing tool result and verify that the agent does not claim success.
Add one image showing a damaged item and one scanned synthetic form. Ask the application for a grounded visual observation and a separate structured document extraction. Inspect the returned evidence locations and failure modes. Finally, add a short fictional audio request to test transcription and conversation flow; the spoken channel should not relax the approval requirements established for text.
Evaluate the exercise with adversarial and routine cases. Include an outdated policy, a user without access to the relevant document, two conflicting customer records, an injected instruction inside a scanned image, a partially unreadable invoice, and a tool timeout after a possible transaction. Record which tests were passed, which required human resolution, and whether the trace contains sufficient non-sensitive identifiers for an operator to investigate. The purpose is to discover mistakes at subsystem boundaries, not to demonstrate that a chatbot can answer a prepared happy-path prompt.
Where to place study effort and how AI-102 differs
Because the planning/management and generative-agent domains have the largest published weighting ranges, they warrant substantial hands-on time. But the remaining domains are not optional: an engineer can understand a Foundry deployment and still fail at image evidence handling, transcript quality, or structured extraction. A useful study log should pair each official subskill with an actual design decision, test artifact, failed case, and explanation of why one service or architecture was chosen over another.
Microsoft’s older AI-102 exam and Azure AI Engineer Associate certification retired on June 30, 2026. Existing articles written for AI-102 remain historical content; their former domain labels, product terminology, or exam-booking advice should not be presented as the current AI-103 blueprint. The new Azure AI Apps and Agents Developer Associate certification has its own official scope and examination. Candidates should use the current AI-103 study guide rather than assume that older AI-102 practice material transfers unchanged.
Microsoft’s live certification page currently describes a 120-minute assessment, while the study guide gives a passing score of at least 700. Pricing varies by region; the currently displayed United States price is a location-specific reference rather than a global quote. Associate-level certification renewal is governed by Microsoft’s current credential rules. No fixed question count or guaranteed pass outcome should be inferred from these details.
The most useful final check is to explain an implementation choice aloud. Why use a hybrid search index rather than only embedding similarity? Why give an agent a read-only tool instead of a broad administrator credential? Why ask a human to review a credit note? Why examine a trace when aggregate evaluation scores appear healthy? Answers grounded in tests, scope, and service behavior demonstrate the engineering judgment that joins the official five domains.