Verify the current Microsoft AI-103 credential

AI-103 is titled Developing AI Apps and Agents on Azure. It supports the Microsoft Certified: Azure AI Apps and Agents Developer Associate credential, which emphasizes developing and operating Azure AI solutions using Python and Microsoft Foundry. It is a different examination from the retired AI-102. Older Azure AI Engineer articles can still explain useful fundamentals, but their exam-registration advice, service screenshots, and topic weightings are not a substitute for today’s published blueprint. Confirm the credential and study guide directly in Microsoft’s current AI-103 study guide before purchasing a course or building a final revision plan.

The exam has five measured domains, with percentages representing ranges rather than an exact fixed number of questions. A planning checklist is useful only if it translates each published outcome into something you can explain, configure, troubleshoot, and justify. For example, knowing that retrieval-augmented generation exists is weaker than being able to explain why hybrid retrieval may be preferable to vectors alone, how access filters are applied, and what a grounded-answer evaluation should detect.

Plan and manage Azure AI solutions (25–30%)

This domain begins with choosing the right Foundry model and services for a workload. A small classification service, a multimodal support assistant, and an autonomous agent do not need the same model or control plane. Consider model capability, latency, data handling, deployment availability, capacity limits, price, and integration needs. Then decide where the application, search index, tools, and agent state belong. Plan identity, keyless access, network boundaries, CI/CD, observability and budget controls before a test environment turns into production infrastructure.

A useful lab is to create a Foundry project in an approved Azure environment, configure roles for a developer and a deployed workload identity, select a suitable model, deploy it, and record the endpoint and limits without storing keys in source code. Check what an operator can measure when a call fails. The details of model availability and provisioning change by subscription, region and deployment mode, so use the current portal and SDK documentation instead of memorizing a screenshot.

Consider a real selection problem: a helpdesk assistant must answer questions from versioned policy PDFs, but must never expose documents the caller cannot read. The model alone cannot enforce that requirement. The resource design needs a retrieval system carrying document-version and caller authorization metadata, a project identity allowed to query it, and an evaluation that includes deliberately unauthorized documents. Record whether an access-denied result is correctly withheld rather than summarized by a model.

For operational practice, write down the distinction between a model-capacity problem and an application logic problem. A 429 response warrants quota and retry analysis; a 403 warrants identity or policy inspection; an accurate answer supported by the wrong policy revision is a retrieval/index-governance failure. Treat these as three different diagnostic branches, with a log owner and a safe stopping condition for each.

Build generative applications and agents (30–35%)

The largest domain covers applications that consume models, retrieve organizational information, call tools, preserve suitable conversation state, and evaluate output. A chatbot with a search result pasted into a prompt is only the beginning. A production workflow must define what data is trusted, how citations are attached, how tools are authorized, which operations need approval, and how failed or repeated tool calls are handled. Study orchestration as an operational decision: when is one agent enough, when is a sequence of functions simpler, and when does multiple-agent coordination add value?

For practice, build a small support agent with one read-only retrieval tool and one simulated business-action tool. Require an approval step before the second tool executes. Give the system ambiguous, irrelevant and adversarial documents; measure answer grounding, unauthorized-action attempts, latency, tool failure and total cost. Pair those experiments with the specialist articles on tool-using agents and agent evaluation.

Build a ten-question evaluation set before polishing the prompt: four questions with one correct document, two with contradictory document versions, two with no authorized source, and two requests to change a business record. Grade citation correctness and abstention separately from fluency. The tool-action cases should return an approval request or a refusal, never an executed change based only on retrieved text.

A useful agent trace shows which retrieval result supported each answer, which tool schema was chosen, which authorization check ran, and what happened when a tool timed out. A successful response with an unaudited tool call is a failure in the safety objective, even when its wording sounds plausible.

Implement computer vision (10–15%)

The current computer-vision domain includes much more than identifying objects in a photo. It measures choosing and operating image or video generation, prompt- and mask-driven edits, multimodal understanding, visual question answering, captions, accessibility descriptions, and Content Understanding workflows. Keep generation separate from analysis: generating an image from a brief is not the same task as extracting evidence from a photograph or producing alt text that faithfully describes visible content. A good study plan tests both direction of data flow and the safety controls appropriate to each use.

For a lab, supply a small image set including scanned pages, crowded scenes, charts and images with embedded instructions. Ask a model to describe them, then compare claims against visible evidence. Review whether an assistant treats text printed in an image as an instruction rather than untrusted content. Record the degree of detail needed for accessible descriptions and prevent the system from inventing unseen context. Reliable computer vision and multimodal analysis depends on source-grounded descriptions and explicit uncertainty, especially when visible text could be mistaken for instructions.

Current Content Understanding capabilities cover document, image, audio and video analysis under the 2025-11-01 generally available API. The official Microsoft AI-103 skills outline still names “pro-mode” in its computer-vision objectives, but this is dated exam terminology, not a current lab setup instruction: Microsoft retired the former 2025-05-01-preview pro mode. Its agentic document-analysis mode is a separate 2026-06-01-preview capability, currently limited to document analyzers, one input file per request and field schemas without the extract method. For multimodal labs use a suitable current analyzer instead of attempting a pro-mode video test. For image Q&A, include a question whose answer is not visible, such as a serial number hidden behind a label; the correct behavior is to state that visibility limit.

Implement text analysis and speech (10–15%)

Text analysis includes extracting entities, topics, summaries and structured fields, classifying sentiment or sensitive content, and translating text in a form useful to a real application. Prompted JSON output still needs validation: fields can be absent, inconsistent or confidently wrong. Choose a model or Foundry Tool appropriate to the language, industry and confidence requirement; avoid treating a general sentiment label as a reliable decision about a person. Translation must preserve meaning, terminology and context, and a domain-sensitive workflow needs bilingual review of representative examples.

Speech work adds transcription, text-to-speech, speech translation, custom voices or speech models where supported, and audio input to agent reasoning. Distinguish recognition errors from reasoning errors: an agent cannot ground a decision in the right policy if the recorded account number was transcribed incorrectly. Lab with quiet and noisy clips, different accents, multiple speakers, interruptions and specialist vocabulary. Track recognition quality, latency, user corrections and whether the system clearly indicates uncertainty.

Implement information extraction (10–15%)

Information extraction joins multimodal ingestion with reliable downstream representations. Study retrieval pipelines that index documents, image content, audio and video where supported; configure chunking, OCR, enrichment, metadata, hybrid/vector/semantic search and agent knowledge tools. Documents are not just paragraphs. Tables, forms, diagrams, signatures, page references and cross-page records can lose meaning when converted into plain text, so an extraction strategy should retain structure and source identifiers wherever possible.

Build a pipeline that accepts sample invoices, a policy PDF and a short recorded meeting. Inspect extracted layout and fields before indexing, attach source/page references, and ask an agent a question whose correct answer requires the right record rather than generic knowledge. The relevant deeper guides are document understanding and retrieval quality in Azure RAG.

Use a practical, reproducible study environment

You do not need an expensive, always-running production environment to study. Use a controlled subscription, minimal roles, a cost budget, and a teardown checklist; check the quotas and availability of each model or Foundry tool before choosing a lab. Save a small repository with sanitized configuration templates, versioned prompts, sample documents and evaluation cases. Never commit subscription credentials or personal information. Where a service is not enabled for your region or tenant, document the feature’s architecture and test a supported substitute without claiming you exercised the unavailable service.

For each lab write four short notes: the desired result, the configuration and API choices, a negative test that should fail safely, and the observed behavior. Include operational evidence such as model deployment settings, access roles, search filters, tracing records and the evaluation rubric. This process turns tutorial completion into skill acquisition and makes it easier to revisit a topic if Microsoft changes an SDK or portal workflow.

Test readiness by decision rather than recall

A candidate ready for an applied question can identify which Azure layer owns a problem. If search returns the wrong passages, investigate ingestion and relevance before changing the generation prompt. If an agent uses an unintended tool, investigate authorization and tool policy before deploying a larger model. If an audio assistant misreads a name, separate transcription quality from generation quality. If an extraction report invents a missing table value, validate evidence and field-level confidence rather than trusting a clean JSON response.

Create an exam-day matrix using the five official domains. For each objective, mark whether you can explain it, operate it with documentation, troubleshoot a representative failure, and defend a design choice. Spend your remaining practice time on uncertain or high-risk capabilities rather than rereading introductory terminology. For the current certification, consult the Microsoft AI-103 exam page as a separate exam resource; continue to verify objectives and scheduling with Microsoft first-party documentation.

Finish with a troubleshooting table of your own rather than a collection of service names. Example rows should include unsupported model in the selected region, invalid project endpoint, insufficient role assignment, partial transcript, schema-valid but factually wrong extracted total, and an image carrying malicious instructions. For each, specify the Azure layer to inspect, the evidence to retain, and the failure you should not hide with an automatic retry.

Use Microsoft’s dated AI-103 skills outline as the final scope check. Model catalog entries, product preview availability and SDK behavior can move independently of the exam guide; a dated lab note should identify exactly which documentation version, deployed model and resource geography were tested.