Microsoft’s AI-901 is a fundamentals exam with an unusually practical center. It asks candidates to recognize AI workloads and responsible AI decisions, but it also expects them to understand how a small application is built with Microsoft Foundry. A candidate who can identify a vision use case yet cannot describe how an application sends an image to a deployed model has learned only part of the current syllabus.
The English exam objectives took effect on April 15, 2026. Microsoft AI-900 retired on June 30, 2026; it should not be used as the booking target or as the sole blueprint for current preparation. AI-901 is intended for people beginning AI solution development. You do not need to be a production machine-learning specialist, but basic Python, familiarity with Azure resources and an understanding of REST APIs, SDKs and CLIs make the implementation topics easier to practice.
This study plan uses four weeks as a practical planning example, not a Microsoft requirement or a guarantee of passing. The objective is to cover the entire current blueprint with a balance of concepts, small working experiments, interpretation of results and focused review. Someone who has never used Azure may reasonably need more time; someone who already builds simple Python applications may need less.
Understand the current AI-901 blueprint before studying
The official objectives assign 40–45% to identifying AI concepts and capabilities and 55–60% to implementing AI solutions with Microsoft Foundry. The weights do not state how many questions will appear in each area. Microsoft publishes a scaled passing standard of 700; scheduling details, delivery options and localized exam updates should be verified on the current exam page because they can change.
| Domain | Weight | What a prepared candidate should be able to do |
|---|---|---|
| Identify AI concepts and capabilities | 40–45% | Recognize responsible AI principles; distinguish AI workloads; choose model capabilities, configurations and deployment patterns; understand language, speech, vision, generation and extraction |
| Implement AI solutions using Microsoft Foundry | 55–60% | Use system/user prompts, deploy models, make simple SDK calls, build a chat client and single agent, and implement text, speech, vision and Content Understanding workloads |
The difference between these domains is practical. A concept question might ask whether sentiment analysis or classification fits a problem. An implementation question might ask which step a simple application needs to call the deployed capability, or why a request failed after moving from the Foundry portal into code. The AI workload selection material is a useful starting point, but implementation practice must follow it.
Do not divide the plan by assuming 45% of your hours should be conceptual and 55% hands-on. The right allocation depends on prior experience. A newcomer may need extra work to understand model outputs, while an experienced programmer may need extra work on responsible AI and the differences among text, speech, vision and extraction. Domain weights tell you what the exam values, not how your personal learning time should be divided.
Set up a small, safe practice environment
Choose an Azure subscription you are authorized to use and understand the cost implications before deploying resources. Create or use a Microsoft Foundry resource and project in a supported region, grant the least privilege needed for the lab, and select a supported model deployment appropriate for chat. The Foundry project endpoint is not necessarily the same as a classic Azure OpenAI endpoint or a tool-specific Speech endpoint. Copy the endpoint from the project you actually created, rather than from an old tutorial.
For Python, use a virtual environment and install the current Foundry 2.x project client together with Azure Identity. Microsoft documents azure-ai-projects 2.x for Foundry (new), while version 1.x belongs to the classic experience. This distinction matters because examples for one API generation cannot always be pasted into the other unchanged. Sign in with an approved identity, verify that it can use the intended project, and do not paste long-lived credentials into the article, a repository or a public notebook.
Use ordinary, non-sensitive sample data for all labs. A fictitious help-desk policy, short invoice, synthetic customer feedback, harmless photograph and short recorded prompt are sufficient. No production customer files, private employee records or bank details are needed. Record the model deployment, input, expected output, observed result and any error for each experiment. The aim is to produce a small portfolio of evidence that you understand the flow, not a large cloud environment.
A successful first test should have four observable pieces: a deployed resource, an authenticated request, an output that matches the selected capability, and a way to reproduce or explain the result. When one of these is absent, use the failure diagnostically. An authorization error is not the same as an unsupported model modality, and an incorrect generated answer is not the same as a failed network call.
Week one: AI models, workloads and responsible decisions
Begin with the conceptual domain. Make a small matrix whose columns are business need, available input, desired output, likely model or service capability and important risk. Use examples such as sentiment from feedback, entity extraction from an email, transcribing a conversation, describing a damaged parcel and generating a draft customer response. Include at least one task that does not require a generative model. The exercise should demonstrate that you can choose a capability because it fits the output, not because it is fashionable.
Review the difference between classification, regression, clustering, information extraction and generation. A classifier produces a label; a regressor estimates a number; an extractor should preserve exact fields; a generator produces content whose wording may vary. A single application can combine several of these. When it does, identify which component is responsible for correctness and how that correctness should be measured.
Next, study Microsoft’s responsible AI principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency and accountability. Instead of memorizing them in isolation, write one plausible failure case for each. A model that performs worse for one group raises a fairness question. A chatbot that exposes restricted case notes raises privacy and security questions. A system that gives a consequential answer with no explanation or owner raises transparency and accountability questions. The existing responsible AI examples can help you make these distinctions concrete.
Close the week with a simple model-selection exercise. Compare a text-only request, an image-understanding request and a structured extraction request. Explain which types of models or services can accept the input and what configuration parameters, latency, cost or location requirements might break a tie. Your weekly deliverable is not merely a set of notes: it is the ability to defend your selection against a realistic alternative.
Week two: prompts, model deployments and a chat client
Move into Microsoft Foundry. Deploy a supported chat-capable model and try a short system prompt and a separate user prompt. The system prompt might describe a customer-support helper that answers only from supplied policy facts and asks for clarification when uncertain. The user prompt might ask for a clear explanation of a return rule. Compare what happens when you change the user request, the supplied context and model configuration. Keep a small test set so you can recognize improvement and regression rather than judging one good-looking answer.
Understand that grounding is not the same as prompting. A system instruction says what the assistant should do; grounding provides information that may be needed to answer. If a policy changes yesterday, a clever prompt cannot reliably reconstruct the new facts. Supply an approved, versioned source and verify that a response actually uses it. The prompting and grounding material explains this separation in more depth.
Build a minimal Python chat client using the current Foundry project SDK and an approved identity. It should read a prompt, call the deployed model through the project’s supported API and print the returned text. Add one controlled error case: a wrong deployment name, missing permission or invalid input. Check the failure before changing code. The important skills are identifying the project endpoint, model deployment, authentication context, request and response. Avoid complicated user interfaces; a terminal program is adequate for this exam-level exercise.
By the end of the week you should explain why code that works in a portal can fail from an SDK. The portal session might use your interactive identity while a script uses a different credential. The endpoint may target a different project or the deployment name might not exist there. Inspect these boundaries first. Treat model quality, authentication and HTTP errors as separate concerns, and resist solving every error with a different prompt.
Week three: agents, language, speech and vision
Create a single prompt agent in Foundry. Give it a narrow role, such as answering public product questions, and test it in the portal. Then interact with it through a small client. A plain conversational exchange should work first; tool use can be introduced only when the application has a real task that needs it. This exercise clarifies the difference between model inference, conversation state, an agent definition and an action performed through a tool.
Think about what the agent is allowed to do. A read-only lookup needs a different permission boundary from a tool that changes customer data. For an exam lab, keep the tools harmless and describe what validation, authorization and human approval would be necessary if a similar workflow were moved into a real business system. The single-agent workflow topics are a foundation, but the hands-on task is to create, test and call an agent rather than merely define one.
Next, make one small text-analysis experiment. Use a few synthetic customer feedback entries to extract entities, identify a sentiment or produce a concise summary. Check the expected input/output against the task. If the result must be deterministic, evaluate whether a specialized analysis service is preferable to free-form generation. For speech, distinguish transcription from synthesis, and see how a spoken prompt can enter a multimodal model. Record whether the application returns text, audio or both.
End with vision. Send a benign image to a supported multimodal model and ask it to identify visible content. Then try an image-generation capability with a benign prompt. These are separate tasks: one interprets existing evidence while the other creates a new visual. Use a test image with known facts, and look for unsupported assertions about details that are not visible. If a use case involves an exact quantity from a form, flag it for the following week’s extraction work.
Week four: Content Understanding and mixed-format extraction
The current blueprint explicitly includes extracting information from documents, forms, images, audio and video through Azure Content Understanding. This is easy to under-study because older AI fundamentals material often placed OCR, text analytics and speech in separate conceptual chapters. Here the learner also needs to understand a small extraction application: submit content, wait for the analysis operation, inspect structured output and validate the result.
Start with a fictional invoice. Use an appropriate supported prebuilt analyzer and compare the returned invoice ID, date and amount with the original document. Be alert to table structure and missing fields; a fluent summary is not evidence that an exact amount was extracted correctly. Move to a non-document sample, such as an image, a short audio clip or a short video, and ask what additional structure matters: speaker labels, timestamps, frames, transcript or image evidence. The task is to make the data usable and trustworthy.
Microsoft’s generally available Content Understanding REST version in the current quickstart is 2025-11-01. Some newer features require a preview API, which should not be treated as the stable default. Understand that analysis can be asynchronous: a successful submission may return an operation URL rather than the final result. Follow the returned operation status until completion, then inspect the structured fields. Repeating the initial submission blindly can create duplicate work or charges.
Test one negative case deliberately. A rotated image, low-quality recording, stale document or missing required field should create a validation problem that your application can identify. Your weekly deliverable is a short record of what the service returned and whether you would trust it. That reasoning matters for real systems and is more defensible than simply memorizing analyzer names.
A readiness check built around decisions, not memorization
At the end of four weeks, construct a few mixed scenarios. For example, a company needs an agent to answer customer questions from policy documents while protecting private case data. What capability handles language generation? What supplies policy evidence? Who controls access? What should happen when a document is missing? Another scenario might require reading a receipt photo and validating the total before storing it. A vision description alone does not satisfy the exact-field requirement; select extraction and validation accordingly.
Review every question you missed by root cause. Did you misunderstand the workload? Choose a model that cannot handle the input? Confuse deployment with invocation? Assume a prompt can enforce permissions? Overlook asynchronous extraction or result validation? The answer to each points to a specific short experiment or concept review, not necessarily to more broad reading. Keep mistakes grouped by the official domain so you can see whether the conceptual or implementation side still needs work.
| Readiness signal | Practical self-test | What an unresolved gap looks like |
|---|---|---|
| Conceptual selection | Choose a capability and explain why it meets a scenario’s input and output | Picking a generative model for every problem |
| Responsible AI | Link a specific harm to an appropriate control and owner | Repeating principles without a testable mitigation |
| Foundry implementation | Deploy a model, send a request and inspect the output | Recognizing the portal but not the endpoint or identity flow |
| Agent basics | Test a single agent and describe which actions are permitted | Confusing conversation with unrestricted authority |
| Multimodal extraction | Analyze a sample, inspect returned fields and validate evidence | Trusting plausible output without checking exact facts |
Use Microsoft’s current practice assessment and exam sandbox for complementary purposes. Practice questions expose conceptual and procedural blind spots; the sandbox familiarizes you with how the exam interface behaves. Neither substitutes for hands-on competence, and neither guarantees a result. If your preferred exam language is localized, verify that its objective version aligns with the English update date rather than assuming the same transition occurred simultaneously.
What to do before booking AI-901
Return to the official exam page shortly before scheduling. Confirm availability, delivery details, accommodations, policy updates and the currently measured skills. Do not carry over AI-900 exam format assumptions; that exam is retired. If documentation shows a newer objective update than the one used in this plan, adjust the final review accordingly. Platform models and SDK details change too, so record the version you practiced and revisit the official example when a call stops working.
A good last-day review is a short design explanation, not another marathon through generic AI terms. Explain a Foundry chat request from input through model deployment and authenticated output. Explain the difference between an agent and a normal chat call. Explain how Content Understanding returns structured results from a document or audio sample. Finally, explain why responsible AI controls operate at multiple layers. If you can do those without relying on a memorized product-name list, you have built the kind of foundation AI-901 is designed to assess.
Continue exploring the technologies and certification concepts that matter most to you.