Microsoft AI-103 Developing AI Apps and Agents on Azure Complete Guide: Skills, Domains, and a Practical Preparation Roadmap

 

Microsoft AI-103 measures whether you can build, manage, and operate modern AI applications and agents on Azure using Microsoft Foundry and related Azure AI services. It is not a replacement label for an older AI certification with the same content. The current blueprint reflects the way AI engineering has changed: model selection is only one part of the job; candidates are expected to understand generative applications, agentic workflows, retrieval, tools, evaluation, safety, monitoring, identity, computer vision, language processing, and information extraction as parts of deployable systems.

That scope makes AI-103 broad. A candidate who knows prompt engineering but has little Azure operational knowledge can struggle. So can a strong Azure developer who has not built retrieval and agent workflows. The exam rewards the ability to connect code, models, data, security, and production operations into one coherent solution.

As of September 2026, the active AI-103 study guide measures skills as of April 16, 2026. Microsoft describes the target candidate as an Azure AI engineer who builds, manages, and deploys agents and AI solutions using Microsoft Foundry and expects experience developing applications with Python. The current domains are: planning and managing an Azure AI solution, 25–30%; implementing generative AI and agentic solutions, 30–35%; implementing computer vision, 10–15%; implementing text analysis, 10–15%; and implementing information extraction, 10–15%.

Use the AI-103 exam as the central exam page for this cluster. The broader AI developer certification helps place AI-103 in the credential path, while the Microsoft certification hub provides vendor-level context.

What AI-103 is really testing

The easiest way to misunderstand AI-103 is to treat its domains as five disconnected product categories. In a real solution, they overlap.

Imagine a claims-processing application. It ingests PDFs and photographs, extracts structured fields, analyzes free-text notes, uses retrieval to find relevant policy language, lets an agent call a claims API, and generates an explanation for an adjuster. That one solution touches information extraction, computer vision, text analysis, generative AI, agents, retrieval, security, evaluation, and monitoring.

The exam therefore rewards systems thinking. You should be able to answer questions such as:

• Which service or model is appropriate for this task?
• How should the application authenticate to that service?
• What retrieval/indexing pattern fits the data?
• When should the workflow use deterministic code rather than a model?
• How should an agent expose tools safely?
• How will the team evaluate answer quality before deployment?
• How will production monitoring detect drift, poor grounding, latency, or safety failures?
• How will the application scale without uncontrolled cost?

Those are engineering questions, not product-trivia questions.

Domain 1: Plan and manage an Azure AI solution

This domain carries 25–30% of the exam, but its influence is larger than the percentage suggests because management and architecture concerns appear in scenarios throughout the other domains.

Choose the right model and service

The current Azure AI ecosystem offers multiple model classes and services. The exam can test whether you select a model based on workload requirements rather than prestige.

A good model-selection process considers:

• task type: generation, reasoning, extraction, classification, multimodal understanding;
• input and output modality;
• quality requirements;
• latency target;
• cost sensitivity;
• context needs;
• deployment/region availability;
• safety and compliance constraints;
• whether a specialized Azure AI service would be more predictable than a general model.

If a task is structured OCR and form extraction, a document-oriented extraction service can be a better design than asking a general model to reconstruct fields from images. If the task requires flexible reasoning across text and images, a multimodal generative model may be justified.

The important exam skill is not memorizing a single “best model.” It is mapping requirements to capabilities and trade-offs.

Plan retrieval and indexing

Retrieval-augmented generation is a central pattern because enterprise AI rarely relies only on model training data. Candidates should understand the architecture of retrieval:

1. ingest content;
2. clean or chunk it appropriately;
3. enrich it with useful metadata;
4. create searchable/vector representations;
5. retrieve relevant evidence;
6. provide evidence to the generative component;
7. evaluate whether retrieval and generation are both working.

Semantic, vector, keyword, and hybrid retrieval are not interchangeable labels. Different information needs can favor different combinations. Exact identifiers, for example, can benefit from lexical matching, while conceptual similarity benefits from vector search. Hybrid approaches can improve robustness by combining signals.

Metadata is also part of retrieval quality. Region, product, date, tenant, document type, and security classification can be more important than embedding similarity alone.

Plan memory, tools, and knowledge for agents

An agent can use conversation context, durable memory, knowledge retrieval, and tools. These solve different problems.

Conversation context helps maintain a coherent interaction. Knowledge retrieval supplies external evidence. Tools let the agent read or change external systems. Durable memory can preserve selected information across interactions when the application design allows it.

Do not use memory as a substitute for a system of record. If an agent needs the current order status, call the order service. If it needs an approved policy, retrieve from the authoritative policy source. The model should orchestrate access, not become the authoritative database.

Design Azure infrastructure

AI workloads still need normal cloud architecture: resources, regions, identities, networking, endpoints, scaling, quotas, observability, deployment pipelines, and cost controls.

You should know why private networking can matter, how managed identity reduces secret handling, why Azure role-based access control needs least-privilege design, and why model or service quotas can become production bottlenecks.

A prototype that works from a developer laptop with a local key is not yet production architecture.

Plan deployment and CI/CD

Modern AI applications contain more than source code. Releases can include:

• prompts/instructions;
• agent definitions;
• tool schemas;
• model deployment references;
• retrieval/index configuration;
• safety settings;
• evaluation datasets and thresholds;
• infrastructure templates;
• application code.

Those artifacts need versioning and controlled promotion. A change to a prompt can change tool behavior even when application code is unchanged. A model update can change output quality. Evaluation gates should therefore be part of deployment rather than an informal prelaunch activity.

Manage scaling, quotas, rate limits, and cost

Generative AI systems can hit resource limits in ways conventional web apps do not. Rate limits, token throughput, concurrent requests, indexing throughput, and downstream tool limits all matter.

A good solution can use:

• backoff and retry for transient failures;
• queues for asynchronous work;
• request shaping and batching where appropriate;
• caching for stable results;
• model routing;
• workload prioritization;
• cost/usage telemetry.

Retries need care. Retrying a read is different from retrying a tool that charges a card or creates a ticket. Write operations should be designed for idempotency or explicit duplicate prevention.

Monitor quality, safety, and operations

AI monitoring extends beyond CPU and HTTP status codes. Useful production signals include:

• latency;
• token usage;
• tool-call success rate;
• retrieval quality;
• grounding quality;
• answer-quality metrics;
• safety-filter events;
• refusals;
• user corrections;
• model or data drift;
• cost per outcome.

Tracing becomes especially important in agentic applications where a single request may trigger several model calls and tools.

Security is part of every AI-103 domain

The current blueprint expects candidates to understand managed identity, private access, keyless credentials, RBAC, safety filters, guardrails, auditing, and agent oversight.

Prefer workload identity over embedded secrets

Managed identity and Microsoft Entra-based authentication help reduce credential sprawl. Applications should receive only the roles they require. A model or agent does not need broad subscription rights merely because it needs to query one index and invoke one function.

Keep authentication and authorization distinct

Authentication answers who is calling. Authorization answers what they may do. In agentic applications, the distinction must survive every hop.

A user may be authenticated to the front end, but a backend tool called with a powerful service identity could still expose data the user should not see. A secure design either preserves user context where appropriate or re-enforces authorization inside the tool/service layer.

Protect tool use

Tool calls are a high-impact attack surface because generated reasoning can lead to real actions. Defensive design includes:

• narrow tools;
• typed parameters;
• input validation;
• least-privilege identities;
• confirmation or approval for high-risk actions;
• transaction limits;
• audit logs;
• output validation before downstream use.

A system prompt saying “never perform unsafe actions” is not an authorization mechanism.

Evaluate adversarial behavior

Safety testing should include prompt manipulation, attempts to extract restricted data, attempts to trigger inappropriate tools, ambiguous instructions, harmful content, and weak grounding.

The goal is to prove that technical controls—not only model behavior—protect the system.

Domain 2: Implement generative AI and agentic solutions

This is the largest domain at 30–35%. It combines model application development with agent engineering.

Build generative applications

A generative application usually includes more than a single completion call. You need to manage instructions, user input, context, output format, model parameters, tool/retrieval context, errors, and evaluation.

Model parameters influence behavior. Temperature-like controls affect variation; output length controls affect cost and usability; reasoning/model choices affect latency and quality. But parameters cannot fix poor information architecture.

If answers are incorrect because retrieval returns obsolete content, lowering temperature will not solve the problem.

Implement RAG correctly

Candidates should understand the complete RAG pipeline, not only the final prompt.

A strong RAG implementation considers:

• document ingestion;
• text extraction;
• chunking;
• embeddings;
• index design;
• metadata;
• query construction;
• retrieval mode;
• reranking;
• source filtering;
• prompt grounding;
• answer evaluation.

A common failure mode is retrieving semantically similar but non-authoritative evidence. Another is splitting content so the crucial rule and its exception land in separate chunks. RAG quality is partly a data-engineering problem.

Build workflows and multistep pipelines

Not every generative application should be an autonomous agent. A deterministic workflow can be better when the process order is known.

For example:

1. extract text from a contract;
2. classify contract type;
3. retrieve the matching policy;
4. ask a model to identify differences;
5. send the result for human review.

This is a multistep AI workflow, but it does not require the model to decide every next step. Deterministic orchestration makes behavior easier to test when the sequence is stable.

Design agents with clear roles and goals

An agent needs a defined purpose and authority. “Help the user” is too broad for production.

A useful agent specification includes:

• role;
• goal;
• allowed knowledge;
• allowed tools;
• constraints;
• escalation rules;
• expected output;
• success criteria.

The system should also track conversations and state appropriately so the agent can operate coherently without treating uncontrolled conversation text as trusted business data.

Use retrieval, function calling, and tools

Agents become useful when they can interact with systems. Tool definitions should be model-friendly and operationally safe.

Good tool schemas use clear names, concise descriptions, typed parameters, meaningful validation, and predictable errors. Split risky operations from harmless reads. Avoid a single “do anything” tool.

Function calling is not just a coding pattern; it is a boundary where generated intent becomes executable action.

Implement memory carefully

Memory can improve continuity, but it introduces privacy, relevance, and correctness questions. Decide what should be remembered, for how long, and whether the user can correct/delete it.

For task state, prefer durable systems of record. For example, an agent coordinating an approval should not infer that approval occurred because the user previously said “approved.” Check the authoritative workflow.

Build multi-agent solutions only when justified

Multi-agent orchestration can separate responsibilities, but it also adds latency, cost, error propagation, and operational complexity.

Use multiple agents when separation creates real value, such as:

• independent expertise or tool sets;
• independent security boundaries;
• parallelizable tasks;
• clear producer/consumer contracts;
• separate ownership or evaluation needs.

Avoid multiple agents merely to make the architecture look sophisticated.

Autonomous versus semi-autonomous workflows

Autonomy should be bounded by risk. A low-risk task can operate without approval inside a strict policy envelope. A high-impact action should require confirmation or human review.

Define:

• what can happen automatically;
• maximum allowed parameters;
• what requires approval;
• what requires escalation;
• rollback or recovery behavior;
• audit requirements.

This is a recurring exam concept because agentic AI becomes a security and business-process issue once it can act.

Evaluate agent behavior

Evaluation should include more than response quality. For agents, test:

• correct tool selection;
• correct tool parameters;
• correct sequencing;
• ability to stop/escalate;
• grounded reasoning;
• resistance to prompt manipulation;
• handling of tool failures;
• duplicate-action prevention;
• latency and cost.

An agent that writes excellent prose but calls the wrong tool is a failed system.

Trace and troubleshoot agents

Use tracing to understand what happened across model calls, retrieval, tools, and workflows. When an agent fails, ask which stage produced the incorrect state.

Common failure categories include:

• misunderstood user intent;
• weak retrieval;
• incorrect model choice;
• bad instructions;
• ambiguous tool description;
• authorization failure;
• tool timeout;
• downstream schema change;
• unsafe retry;
• insufficient evaluation coverage.

Troubleshooting from the final output alone is often impossible.

Current Foundry architecture matters

AI-103 preparation should reflect the current Microsoft Foundry platform rather than older tutorials. By September 2026, the Azure OpenAI Assistants API has retired, and current agent patterns use Microsoft Foundry Agent Service and Responses API-based approaches.

For exam preparation, the key lesson is lifecycle awareness. Know the current strategic pattern and be cautious with old examples that use deprecated packages or classic agent infrastructure.

This is not mainly about memorizing retirement dates. It is about building solutions that follow current platform architecture.

Domain 3: Implement computer vision solutions

Computer vision represents 10–15%. Even if your main interest is generative AI, ignoring this domain is risky.

Understand image analysis versus generative vision

Computer vision tasks can include:

• image classification;
• object detection;
• OCR/text extraction;
• image description;
• multimodal question answering;
• image generation/editing.

Choose the capability based on the requirement. If the task is to extract text from a document image, use a suitable extraction/OCR approach rather than assuming a generative model is always best. If the task requires reasoning across image content and text instructions, multimodal generative AI may be appropriate.

Build vision workflows with confidence and validation

Vision systems can be wrong in ways that are difficult to detect automatically. For high-impact processes, design validation.

Example: an agent inspects equipment photos and suggests maintenance actions. The architecture can use a vision-capable model to identify visible symptoms, but a safety-critical recommendation should be grounded in approved maintenance procedures and may require technician confirmation.

Consider image data quality

Image resolution, orientation, lighting, cropping, occlusion, and source consistency affect results. A robust solution validates input and can request another image when necessary.

A model cannot recover information that is not visible.

Domain 4: Implement text analysis solutions

Text analysis also represents 10–15%. It includes classic language tasks as well as model-based approaches.

Classification and extraction

Use text analysis to identify categories, entities, key phrases, intent, or other structured signals. A general LLM can perform many of these tasks, but specialized services or constrained structured outputs can be more predictable at scale.

The architecture choice depends on flexibility, cost, latency, explainability, and required languages.

Sentiment, tone, and safety

Sentiment is not the same as intent. A frustrated customer can still be making a routine request. Avoid building business rules from a single probabilistic score without validation.

Safety analysis can help detect harmful or sensitive content, but production controls should also include access rules, filters, and workflow policies.

Translation and speech

Multilingual solutions may need translation, speech-to-text, text-to-speech, or direct multilingual model behavior. Consider whether preserving terminology, timestamps, speaker identity, or domain vocabulary matters.

For regulated or technical content, evaluation with representative domain language is essential.

Domain 5: Implement information extraction solutions

Information extraction is 10–15% and increasingly important because AI applications need structured, searchable data from documents, images, audio, and video.

Ingest and structure content

A typical pipeline can ingest files, extract text or structure, enrich metadata, split content, and index it for retrieval or downstream processing.

The design should preserve important relationships. A table row separated from its header can lose meaning. A contract clause separated from its exception can produce misleading retrieval.

OCR and document understanding

OCR extracts visible text; document understanding can add structure such as fields, tables, layout, and document type. Choose the appropriate level of extraction based on the use case.

If the downstream application only needs searchable text, a full custom field extraction pipeline may be unnecessary. If the application must populate a financial system, structured extraction and validation are critical.

Semantic, vector, and hybrid search

Know the difference at a conceptual level.

Keyword/lexical search is strong when exact words or identifiers matter. Vector search uses semantic similarity. Semantic ranking and hybrid designs can combine signals.

For many enterprise applications, hybrid retrieval is effective because users mix exact terms with natural-language concepts.

Content enrichment

Extraction pipelines can enrich data with categories, entities, language, summaries, or other metadata. Enrichment should serve a retrieval or business requirement; adding every possible enrichment creates cost and complexity without necessarily improving results.

Content Understanding and multimodal extraction

Current Azure AI capabilities can process mixed formats and produce structured or markdown-like representations that are useful for downstream reasoning and retrieval. The architectural question remains the same: which representation preserves the information required by the application?

How the five domains come together: a reference architecture

Consider an enterprise knowledge-and-action assistant for a maintenance organization.

Users submit text questions, PDFs, and equipment photos. The assistant must find manuals, diagnose common faults, create work orders, and escalate safety-critical issues.

A possible architecture includes:

• a secured application/channel;
• a multimodal model for text/image understanding;
• an extraction pipeline for manuals and documents;
• a hybrid/vector index for retrieval;
• an agent with narrow tools for inventory and work orders;
• managed identity for runtime access;
• deterministic rules for safety escalation;
• evaluation datasets for retrieval and agent behavior;
• tracing for model/tool workflows;
• CI/CD for application, prompt, agent, and infrastructure changes.

Every exam domain appears in this one solution. Practice thinking this way.

The best hands-on preparation is small but complete

You do not need to build a massive application to prepare well. Build several small systems that each demonstrate an end-to-end concern.

Project 1: grounded Q&A

Create a small corpus, index it, retrieve evidence, generate grounded answers, and evaluate incorrect/weak retrieval cases.

Learn where failures occur.

Project 2: tool-using agent

Build an agent with a read tool and a write tool. Use narrow schemas. Add confirmation or policy checks to the write path. Trace calls and handle errors.

Learn that tool safety is part of application design.

Project 3: multimodal extraction

Process images or documents, extract useful structure, validate results, and store/index the output.

Learn when specialized extraction is preferable to free-form generation.

Project 4: production controls

Take one earlier project and add managed identity, role assignments, environment configuration, monitoring, evaluation, and a deployment pipeline.

Learn how much engineering exists beyond the model call.

These four projects cover more useful ground than dozens of disconnected tutorials.

Build preparation around dependency order

Phase 1: establish Azure and AI foundations

Before deep exam study, make sure you can explain:

• Azure resources and regions;
• Microsoft Entra identity and managed identity;
• RBAC;
• networking/private access concepts;
• SDK/application authentication;
• REST/API fundamentals;
• Python application structure;
• generative model basics;
• embeddings and vector similarity.

If these are weak, advanced agent material becomes harder than necessary.

Phase 2: build the Foundry mental model

Learn how current Foundry projects, models, agents, tools, evaluations, and observability fit together.

Focus on architecture rather than portal memorization.

Be able to trace a request from user -> application -> model/agent -> retrieval/tool -> result -> telemetry.

Phase 3: master retrieval and information extraction

Build at least one real retrieval pipeline. Include metadata and deliberately difficult documents.

Test stale content, ambiguous content, exact identifiers, and permission boundaries.

Phase 4: build agents and tools

Implement tool calling, conversation/state handling, error paths, and controlled writes.

Experiment with when a deterministic workflow is better than autonomous orchestration.

Phase 5: cover vision and language services

Do not leave the 10–15% domains until the night before the exam. Build small exercises for images, OCR, text classification, language processing, and extraction.

Phase 6: operationalize one solution

Add security, monitoring, evaluation, cost awareness, CI/CD, and failure handling to an earlier project.

This phase turns development knowledge into AI engineering knowledge.

Phase 7: practice scenario reasoning

Use questions to identify architecture errors, not simply to generate a percentage. For every miss, classify the failure: product knowledge, requirement reading, security, retrieval, tool design, evaluation, or operations.

Then repair the underlying mental model.

Common AI-103 preparation mistakes

Studying only generative AI

Generative AI is the largest domain, but it is not the entire exam. Vision, language, and extraction together represent a substantial portion.

Ignoring Azure security

AI applications still run inside an enterprise cloud. Identity, RBAC, private connectivity, and auditing matter.

Memorizing SDK syntax

Syntax changes. Understand the architecture and common coding patterns, but do not treat the exam as a recall test of method names.

Learning RAG only from happy-path demos

Real retrieval fails because of stale sources, bad chunking, weak metadata, ambiguous queries, or authorization mistakes. Test failure cases.

Treating agents as chatbots

An agent is important because it can plan/orchestrate tools and workflows. Study tool contracts, permissions, state, evaluation, and failure handling.

Ignoring current platform changes

AI platform guidance changes quickly. Use current Foundry patterns and avoid basing preparation on retired Assistants API architecture.

Focusing on wordy theory without building anything

AI-103 is an engineering exam. Hands-on work reveals problems that documentation summaries do not: authentication failures, malformed tool schemas, bad retrieval, quota limits, and trace complexity.

Readiness signals

You are approaching readiness when you can do the following without relying on a memorized answer key:

• choose an Azure AI service/model for a stated workload and justify the trade-offs;
• design a RAG pipeline and explain how metadata, chunking, and retrieval affect quality;
• implement or describe a tool-using agent with secure boundaries;
• distinguish agent memory from retrieval and system-of-record state;
• explain managed identity/RBAC across an application flow;
• design evaluation for generation, retrieval, and agent tools;
• troubleshoot a failing AI workflow using traces and component-level hypotheses;
• choose between deterministic orchestration and autonomous behavior;
• explain when to use specialized vision/language/extraction services versus a general model;
• design a deployment and monitoring approach for production.

If you can answer those questions only in abstract terms, add hands-on work. If you can apply them to unfamiliar scenarios, you are operating closer to the level AI-103 expects.

Exam-day reasoning framework

For a scenario question, use this sequence:

1. Identify the workload: generation, agent, retrieval, vision, language, extraction, or operations.
2. Identify the decisive constraint: security, accuracy, latency, cost, modality, scale, or lifecycle.
3. Identify the authoritative data/state source.
4. Identify the identity and permission boundary.
5. Decide whether the process is deterministic or agent-directed.
6. Eliminate options that violate a stated constraint.
7. Prefer the simplest design that satisfies the requirement and can be operated safely.

This prevents feature recognition from replacing engineering judgment.

What makes AI-103 valuable as a study target

AI-103 forces candidates to move beyond model demos. The blueprint connects the skills required to make AI usable inside real Azure applications: data ingestion, retrieval, models, agents, tools, identity, safety, evaluation, deployment, monitoring, and multiple AI modalities.

That breadth is also what makes preparation demanding. Do not respond by memorizing more isolated facts. Build a small number of strong mental models and use hands-on work to connect them.

If you can look at an unfamiliar business requirement and reason from data and identity through model/agent behavior to deployment and operations, you are developing the capability the exam is designed to measure. That is the standard to use when deciding whether your preparation is complete.

Operational failure patterns every AI-103 candidate should recognize

A final preparation check should include failure analysis, because production AI systems rarely fail in only one place. The same user-visible symptom can originate from retrieval, identity, model behavior, tool execution, quotas, or orchestration.

If a grounded assistant starts returning outdated answers, do not immediately tune the model. Check ingestion freshness, index status, filters, chunking, source precedence, and retrieval traces first. If an agent suddenly loses access to a tool, separate authentication failure from authorization failure, endpoint/network reachability, tool-schema mismatch, and downstream service errors. If latency rises, inspect retrieval time, model latency, tool calls, retries, token volume, and orchestration depth rather than treating the entire request as one opaque duration.

Cost problems should be decomposed the same way. High spend can come from excessive context, unnecessary model calls, repeated retrieval, overly long outputs, uncontrolled retry loops, or using a costly model where a smaller model or deterministic step would suffice. The correct response is an architectural diagnosis, not a blanket instruction to “use a cheaper model.”

Build at least one exercise where you intentionally break a working solution and use logs, traces, metrics, and component-level hypotheses to isolate the cause. That practice ties together monitoring, evaluation, retrieval, agents, security, and cost management. It also develops the troubleshooting mindset that distinguishes an Azure AI engineer from someone who only knows how to assemble a successful demo.