Microsoft’s AI-103 exam is the current role-based assessment for the Microsoft Certified: Azure AI Apps and Agents Developer Associate credential. It is aimed at Azure AI engineers who build, manage, and deploy AI applications and agents with Microsoft Foundry, rather than at candidates who only need conceptual familiarity with artificial intelligence. The official audience profile expects Python development experience together with working knowledge of general AI, generative AI, and Azure services.
The most useful way to read the blueprint is as a description of an end-to-end engineering role. Candidates are not being tested only on model calls. They are expected to choose services, configure infrastructure, build retrieval and agent workflows, implement multimodal solutions, secure and monitor systems, and extract information from real content. The AI-103 exam therefore sits at the point where application development, AI design, cloud operations, and responsible deployment meet.
The current published weighting also changes how preparation should be allocated. Planning and managing an Azure AI solution represents 25–30% of the exam, while generative AI and agentic solutions account for 30–35%. Computer vision, text analysis, and information extraction each contribute 10–15%. Those percentages make one point clear: generative and agentic work is central, but a candidate cannot treat the remaining domains as peripheral because the scenarios often combine them.
Planning and managing an Azure AI solution is an architecture domain
The first major domain asks candidates to choose appropriate Microsoft Foundry services, models, retrieval methods, deployment approaches, and integration patterns. This requires more than knowing which product exists. A strong answer depends on workload characteristics: whether the task needs a large or small language model, whether inputs are multimodal, how grounding should work, what latency and cost constraints exist, and whether an agent needs memory, tools, or a knowledge source.
The same section includes infrastructure decisions. Candidates should be able to reason about model and agent deployments, Azure resources around an AI application, and the way Foundry projects connect to software delivery processes. The blueprint explicitly includes continuous integration and continuous deployment, so candidates who have only used notebook-style prototypes need to understand why a production AI application must move through repeatable build, test, configuration, and release stages. A broader explanation of CI/CD pipelines is useful here because AI code still has to behave like maintainable software.
Planning also includes cost and capacity. Quotas, scaling, rate limits, and model cost footprints are part of operational design. An architecture that works for a small demonstration may fail under concurrency, exceed throughput limits, or become uneconomical when a workflow chains several model calls. Exam scenarios can therefore reward a solution that is deliberately simpler, cheaper, or easier to operate rather than one that uses the most sophisticated model or the largest number of services.
Security, monitoring, and responsible AI are built into the platform decisions
AI-103 treats management as more than deployment. The official objectives include monitoring model performance, drift, safety events, grounding quality, ingestion quality, search-index health, and relevance. Candidates should understand observability as a way to explain system behavior after release. If a grounded assistant suddenly becomes less accurate, the problem may be the model, the retrieval layer, a stale index, changed source content, or a prompt update. Monitoring needs to help separate those possibilities.
Security appears in the same domain because model access, application identity, network exposure, and tool permissions all affect risk. Managed identity, private networking, keyless credentials, and role policies are specifically called out. This should push preparation beyond the habit of storing keys in local configuration files. Azure applications are expected to authenticate in a way that can be controlled, rotated, audited, and limited according to the workload’s actual permissions.
Responsible AI is similarly operational. The objectives include safety filters, guardrails, risk detection, content moderation, evaluators, trace logging, provenance metadata, approval workflows, and constraints on agent behavior. Candidates should be able to distinguish between controls that prevent unsafe output, controls that detect quality problems, and controls that restrict what an agent is allowed to do. The exam is likely to frame these as design choices rather than ask for abstract definitions alone.
Generative AI and agentic solutions carry the largest share of the exam
The 30–35% generative and agentic domain is where AI-103 differs most strongly from older Azure AI preparation. Candidates need to know how to deploy and consume different model types, implement retrieval-augmented generation, design tool-augmented workflows, evaluate application quality, and connect applications to Foundry projects. The emphasis is on building useful systems around models rather than simply sending a prompt and returning a response.
RAG deserves particular attention because it connects search, indexing, grounding, evaluation, and application behavior. A candidate should understand why an organization retrieves relevant enterprise content instead of trying to place all knowledge in a system prompt, how document chunking and indexing affect retrieval, and why a generated answer is only as trustworthy as the evidence returned to the model. Hybrid and vector-based retrieval also reappear in the information-extraction domain, so this is a cross-cutting skill rather than a single objective.
The same section introduces agent design in a concrete way. Candidates should understand roles, goals, conversation tracking, tool schemas, function calling, memory, knowledge stores, search, custom functions, and multi-agent orchestration. They also need to recognize when an autonomous workflow needs safeguards or human approval. A technically capable agent is not automatically a well-designed agent; operational control is part of the solution.
Optimization means measuring behavior, not merely rewriting prompts
Prompt engineering remains in scope, but AI-103 places it inside a wider optimization process. Candidates should know how model parameters, prompt structure, examples, and instructions affect generation. They should also understand that improvement requires evidence. If a new prompt is claimed to reduce fabrication or improve relevance, the application needs evaluation data that can show whether the change actually worked across representative inputs.
The blueprint goes further by including tracing, token analytics, safety signals, and latency breakdowns. These are operational measurements. A slow agent may be spending time in retrieval, waiting on a tool, making too many model calls, or choosing a model that is larger than the task requires. Token analytics can expose oversized context or inefficient conversation history. Traces can reveal where a multistep workflow repeatedly fails.
This is also where candidates should understand orchestration. A production system may combine multiple models, rules, deterministic code, tools, and approval steps. The goal is not to replace every software decision with an LLM. In many cases the strongest architecture uses the model only where probabilistic reasoning adds value and uses ordinary application logic for validation, routing, calculation, or hard business rules.
Computer vision now includes generation as well as understanding
The computer-vision domain represents 10–15% and includes both generative and analytical work. Candidates may need to reason about generating images or video from prompts and reference media, editing generated media, using inpainting or mask-based controls, and choosing platform controls that fit a requested outcome. This is broader than the older idea of computer vision as classification and object detection alone.
Multimodal understanding is equally important. The objectives include analyzing visual context, generating captions, answering questions grounded in visual evidence, producing accessibility descriptions, extracting visual characteristics, processing video segments, and identifying objects or regions. Microsoft Content Understanding appears in this area because unstructured visual information can become structured content that other parts of an application can use.
Responsible AI remains present here. Candidates should recognize the need to classify unsafe visual content, mitigate indirect prompt injection carried inside images, and enforce visual policy rules. A multimodal application therefore has attack surfaces and policy requirements that a text-only prototype may not reveal.
Text analysis combines language tasks with speech and generative models
The text-analysis domain also contributes 10–15%. Rather than treating natural language processing as a list of isolated APIs, the objectives emphasize solutions that extract entities, topics, summaries, and structured JSON by using generative prompting and Foundry Tools. The candidate needs to think about the required output and then choose a method that is reliable enough for the downstream application.
Sentiment, tone, safety issues, and sensitive content remain relevant, as does translation. Speech is included in this domain too: speech-to-text, text-to-speech, custom speech models, multimodal reasoning from audio, and spoken-language translation can all become part of an agentic interaction. That makes voice applications a system-design problem involving audio input, language reasoning, application state, and synthesized output.
For exam preparation, it is more effective to compare use cases than to memorize service names in isolation. Ask what form the input takes, what the application must produce, how much structure is required, whether the response must be grounded, and whether the result is used by a person or by another software component. Those details usually point toward the correct implementation pattern.
Information extraction connects documents, search, OCR, and RAG
The final 10–15% domain focuses on turning unstructured content into information that AI systems can retrieve and reason over. Candidates should understand ingestion and indexing for documents, images, audio, and video; semantic, hybrid, and vector search; enrichment; OCR; and the role of retrieval pipelines in agent tools and grounded applications.
Document extraction is not just about reading visible text. The blueprint includes layout analysis, field extraction, multimodal pipelines, and Content Understanding analyzers that can produce structured or Markdown representations for downstream reasoning. That matters when a solution works with invoices, forms, reports, contracts, presentations, scans, or mixed-media files where meaning depends on location and structure as well as words.
This domain is tightly connected to generative AI. A RAG system needs good source representations and a healthy search index before the model ever sees a query. Weak extraction, bad chunking, incomplete metadata, or irrelevant retrieval can create apparent “model problems” that are actually data-pipeline problems. Candidates should learn to diagnose the full chain.
AI-103 is the successor to AI-102, but it should be studied as a new role profile
Microsoft retired AI-102 and the Azure AI Engineer Associate certification on June 30, 2026, replacing that path with AI-103 and Azure AI Apps and Agents Developer Associate. The historical AI-102 exam remains useful for understanding where the Azure AI role came from, but candidates should not use its blueprint as the current AI-103 syllabus. The newer exam places much stronger emphasis on Foundry, generative systems, agents, modern retrieval, multimodal generation, evaluation, and operational guardrails.
That transition also explains why a candidate with older Azure AI experience may still need targeted study. Previous knowledge of language, vision, speech, and search remains valuable, but the engineering center of gravity has moved. Agent orchestration, retrieval quality, model evaluation, content understanding, and secure Foundry-based deployment now deserve explicit practice.
Anyone following the wider Microsoft certification portfolio should treat AI-103 as an intermediate, developer-oriented Azure AI credential. It is not a fundamentals exam, and it is not a pure machine-learning operations exam. Its identity is application engineering: build an AI solution, connect it to real information and tools, deploy it responsibly, and keep it observable enough to improve after it reaches users.
Use the blueprint to organize practice around complete systems
A strong study plan should mirror the way the domains interact. Start with a small Foundry project and an application that calls a model. Add grounding through search, then give the application a tool. Add evaluation data and traces. Secure the connection with managed identity or an equivalent production pattern. Put the project through a basic deployment pipeline. Then extend it with a multimodal or information-extraction scenario.
That sequence forces candidates to see the same concepts from several blueprint perspectives. Retrieval is both an application feature and an operational dependency. Agents are both a reasoning pattern and a security problem. CI/CD is both software delivery and a way to control AI changes. Evaluation is both a quality technique and an observability requirement.
AI-103 is therefore best understood as an exam about building AI systems that survive contact with production. Candidates who learn the individual services but never connect them may know the vocabulary while missing the engineering judgment the scenarios are designed to test. The blueprint becomes much easier to retain when each objective is attached to a working application and a concrete decision.