Start with a gap assessment and safe lab setup

On day one, download the current Microsoft AI-103 skills outline and list the five measured domains. For each task mark one of three levels: can explain only, can perform with references, or can troubleshoot without a step-by-step tutorial. Do not give yourself full credit merely for recognizing a service name. Record experience with Python authentication, request handling, exceptions and serialization, because even a simple agent lab depends on reliable client code.

On day two, prepare a training subscription or approved sandbox with a cost budget and minimum permissions. Separate a deployment identity from the end-user identity, use environment-specific configuration rather than embedded API keys, and keep a cleanup list for model deployments, search indexes, test storage and logs. Check regional availability before planning a lab around a particular model. The initial goal is a working development path, not a high-cost or overly complex architecture.

Deliverable for days 1–2: a dated baseline grid with five rows, one per blueprint domain, plus an Azure resource inventory and a cost ceiling. For each objective, distinguish “can explain,” “can configure using documentation,” and “can diagnose a failed configuration.” The first two days are complete only when you can identify your subscription, project scope, region, budget notification and the identity used for the lab without copying secrets into a notebook.

Days 3–7: Foundry projects, deployment, identity and quotas

Create or inspect a Microsoft Foundry project, select a model appropriate for a simple text task and connect to it from a Python application using the supported SDK and authentication model. Note the difference between the project’s resource identity, a deployed model, the application identity and any storage or search resource. Test an unauthorized call and a malformed request; record how the SDK and service report those conditions. Then compare model capacity, rate limits, response latency and cost under small test workloads.

Finish the week by describing the deployment chain: development code, configuration, approval, deployment, monitoring and rollback. Consider how a CI/CD job obtains credentials, how model versions are controlled, and who may change a production endpoint. Read AI endpoint security and capacity planning for decisions that a demo with one successful request rarely reveals.

Daily outputs for days 3–7: On day 3, provision or inspect a Foundry project and save its verified endpoint format. On day 4, compare two supported model deployments against one latency/cost requirement. On day 5, call the selected deployment from a Python client using approved credentials. On day 6, deliberately test a principal with insufficient permission and explain the error. On day 7, record quotas, a rollback scenario and the resource teardown plan.

Do not count an unexecuted script as a passing lab. Save the actual outcome or mark it “not run”; in particular, a 401/403 response proves that a negative authorization scenario was exercised only if the expected principal and scope were documented. Microsoft’s Foundry SDK quickstart provides the current 2.x client pattern for day 5.

Days 8–12: Retrieval, grounding and evaluation

Create a small knowledge collection that mixes exact codes, plain-language questions, versioned policy documents and one intentionally obsolete page. Build a retrieval path with Azure AI Search, understanding how keyword, vector and hybrid retrieval can rank different results. Include metadata, document versions and access scopes. Ask a question whose answer is in only one version. If the assistant cites an outdated policy, investigate indexing freshness and result ranking instead of asking it to become more confident.

Create an evaluation set with expected supporting passages and a few unanswerable questions. Track whether retrieval found the correct item, whether the generator supported its claims, and whether the answer should have abstained. Compare at least two chunking or ranking choices; change one variable at a time. Record latency and cost so a quality improvement is not credited without its operational tradeoff.

Daily outputs for days 8–12: Day 8 produces a ten-document inventory with authorization and version metadata; day 9 produces searchable chunks with stable source IDs; day 10 compares keyword, vector and hybrid retrieval using five known-answer queries; day 11 measures answer grounding and refuses two unanswerable prompts; and day 12 records a failed retrieval caused by an obsolete source. The pass condition is not a polished answer: it is an identifiable supporting passage from the correct revision and an explicit abstention when evidence is absent.

Days 13–17: Agents, functions, approval and memory

Give a Foundry agent a narrow job description and one read-only knowledge tool. Define the function schema with types, required fields and error handling; reject invalid arguments before they reach a downstream API. Add a simulated action such as creating a support ticket, but require an explicit user approval step for the action. Test ambiguous instructions, denied permission, repeated calls and a stalled tool. An agent that responds well to a normal prompt can still fail its authorization and recovery requirements.

On the last two days of this block, compare memory within a session to durable knowledge and business state. Decide what should be retained, for how long and under whose authority. Trace the user turn through retrieval, tool invocation and final answer. A multi-agent design is not automatically superior; evaluate whether it clarifies roles or simply adds cost and failure paths. For tool-using agents, a schema error or missing approval should stop the action rather than yield a guessed tool result.

Daily outputs for days 13–17: Define a read-only tool contract on day 13; exercise valid and invalid arguments on day 14; add approval-gated simulated write operations on day 15; compare transient conversational context with an external durable record on day 16; and inspect an end-to-end trace on day 17. Keep all business changes simulated. A wrong amount, unapproved recipient, invalid enum or unavailable API must stop before a high-impact action is taken.

Days 18–21: Computer vision and responsible multimodal AI

Test image understanding using a photograph, a dense diagram, a chart and a screenshot containing text that should not be treated as instructions. Compare captions for fidelity, question answers against visible evidence, and alt text against the actual purpose of the image. Avoid pretending that one successful caption proves accessible descriptions are reliable for every user. Record which outputs need human review and which can be rejected automatically by a confidence or validation rule.

Contrast those analysis tasks with generation and editing: image generation from text, editing with a mask or reference, and the lifecycle of video-generation requests where supported. Note content filters, rights to input media, provenance, brand policies, and the difference between modifying an asset and identifying objects in one. The exam blueprint includes both media creation and multimodal comprehension, so your notes should separate each operation clearly.

On days 18–21, preserve a compact evidence sheet for four inputs: a product photograph, a dense chart, a screenshot containing malicious directions and a short recorded clip. For each, state what is visibly or audibly supported, what cannot be inferred, and which safety policy applies. A generation/editing lab should separately record model/version/region and whether a requested mask edit preserves the unmasked region. Preview video features must be labeled as such, not scored as universally available.

Days 22–25: Text analytics, translation and speech

Use a small set of emails and support messages to extract entities, topics, sentiment, summaries and a validated JSON schema. Add a counterexample such as sarcasm or a message combining praise with a complaint. Confirm that the pipeline surfaces uncertainty rather than turning a weak classifier into an automated employment, credit or health decision. Compare terminology preservation during translation; verify important legal or technical phrases with a competent human reviewer or approved translation glossary.

Then add recorded audio with at least two speakers, pauses and specialized names. Exercise speech-to-text, text-to-speech or spoken translation according to supported services. Track word recognition errors and downstream answer quality separately. A correct conversation response derived from a flawed transcript can still be dangerous if it changes a number, person or date. Document which speaker, language or output capabilities are actually supported in the chosen region and SDK version.

For days 22–25, use one anonymized message set with a mixed-sentiment example, one multilingual item, one invalid JSON response and one ambiguous speaker turn. Keep the expected extraction schema and translation terminology in the lab log. If a field is missing, the validator must flag it rather than invent a plausible value. Compare audio recognition with the approved transcript and note how errors would affect downstream tool arguments.

Days 26–28: Document, audio and video extraction

Ingest one digital PDF, one scanned form and one image-based table. Compare raw OCR text to a layout-aware Content Understanding representation. Check whether extracted fields, table rows, page references and confidence indicators remain tied to their sources. A table flattened into a sentence can lose column meaning, and an apparently clean invoice can still contain an incorrect currency, account number or total. Use validation rules and exception review before a result enters an accounting or case-management workflow.

Next use a short meeting recording and video clip. Identify which portions of the content require transcription, timestamped segments, descriptions of visible events, and cross-modal reasoning. Keep the source references available to retrieval and agent tools. Test with a question that requires both a spoken statement and a visual observation, then verify that the model did not silently combine events from different timestamps.

For days 26–28, compare one scanned form with its manually verified fields, one digital document with an embedded table, and one 20–30 second recording with two labeled events. Save page references for documents and timestamp ranges for media so another reviewer can confirm the evidence. Use an audio/video-capable analyzer from the current Content Understanding multimodal API rather than the retired 2025-05-01-preview pro mode. If a document task needs complex reasoning, agentic document analysis can be tested separately on 2026-06-01-preview with its one-file-per-request and no-extract-field restrictions; it is not an audio/video processing mode. Log the API version and analyzer chosen for each lab.

Days 29–30: Integrated scenario and final check

For a final practical exercise, build a small assistant that reads approved documents, answers with source references and proposes—but cannot execute without approval—a business action. Include one image or audio attachment, access controls, basic traces, an evaluation dataset and cost limits. Intentionally corrupt the index freshness, deny a tool permission and submit an irrelevant attachment. Note which layer fails and which signal makes the failure diagnosable. The exercise should be small enough to finish and remove within your lab budget.

Close by comparing your Microsoft AI-103 preparation against the official blueprint section by section; an integrated project may leave several objectives untouched. Identify one unanswered question for each domain, resolve it with current Microsoft documentation, and record an observed lab result. The Microsoft AI-103 exam page can orient your preparation, but exam scheduling and current product behavior should be verified with Microsoft. Readiness means knowing what to do when the happy path breaks.

The final handoff should contain a working diagram, a small evaluation table, the five-domain skill checklist, two explicit authorization denials, and an itemized cleanup note. If any lab required an unavailable preview model or lacked subscription permissions, label the gap and describe the substitute reasoning exercise. A candid unresolved gap is more useful than marking a service “tested” when no request was actually made.