What AI-901 measures—and what changed from AI-900
The Microsoft AI-901 exam now represents the Microsoft Certified: Azure AI Fundamentals credential. It is an entry-level assessment, but “fundamentals” no longer means memorizing a list of cloud services without understanding how a small application uses them. The current Microsoft skills guide expects candidates to recognize responsible-AI problems, choose an appropriate type of model, and understand practical work with Microsoft Foundry. Its implementation objectives include prompts, a deployed model, a minimal chat client, a single agent, text and speech services, visual workloads, and Content Understanding. This breadth is the organizing principle for a useful study plan.
The former Microsoft AI-900 examination retired on June 30, 2026. That did not retire Azure AI Fundamentals as a certification. It changed the test candidates must take to earn it. Someone who studied AI-900 still has useful foundations in supervised learning, language processing, computer vision, responsible AI, and matching tasks to cloud capabilities. The mistake is treating an archived AI-900 objective list, question set, or interface walkthrough as an up-to-date AI-901 checklist. A historical guide remains useful for the concepts it explains, but eligibility, exam sections, services, and interfaces must be checked against the current issuer materials.
Microsoft’s published AI-901 study guide has two weighted domains: Identify AI concepts and capabilities, worth 40–45 percent, and Implement AI solutions by using Microsoft Foundry, worth 55–60 percent. Those are ranges, not an exact fixed distribution for every candidate. The guide also states that the English exam skills changed on April 15, 2026. Microsoft’s current AI-901 skills list is the authoritative blueprint. Because the implementation domain is larger, a preparation plan that ends with conceptual flash cards leaves a material part of the exam untouched.
Start with the small technical foundation the exam actually assumes
AI-901 does not require the architecture experience expected of an advanced production engineer. It does assume that a beginning AI developer can make sense of a few technical building blocks. Python syntax matters because a sample client may show a variable, a function call, a dictionary of arguments, or a response property. Cloud literacy matters because a deployed model is hosted within an Azure resource and accessed through an authenticated endpoint. You should know the roles of a project, deployment name, client, input, response, and permission, even if you cannot reproduce a sophisticated infrastructure design.
Practice reading a tiny program before trying to memorize any particular SDK’s transient method names. Find where a client is created, which credential is presented, which model deployment receives the request, how a system instruction differs from the user message, and where the answer is retrieved. Next, sketch the same interaction as a request and response: a user supplies input; the application authenticates; the service selects the deployed model; the application presents the generated output. This mental model travels across REST APIs, SDKs, and command-line tools. Microsoft notes that candidates should be familiar with all three, while actual available model choices and client APIs depend on the service version.
The most useful beginner lab is deliberately limited. Use a non-sensitive example, such as drafting a concise summary of a fictional incident report. Specify the desired audience and format, send the request to a supported deployed model, inspect the output, and change one input condition at a time. This teaches what a prompt does, where authentication belongs, and why model output must be checked against source evidence. Do not copy credentials into articles or logs. If you lack an Azure subscription, reason through the same stages using the official Foundry SDKs and endpoints; documentation study is not a claim that a live deployment was performed.
Learn to recognize the workload before naming the service
Begin the conceptual domain with the problem being solved rather than a catalog name. A support team wants the emotional tone of incoming feedback: that is sentiment analysis. A legal assistant needs named organizations and dates: that is entity extraction. A warehouse team wants to read invoice fields: that is structured document information extraction. A field technician needs spoken instructions converted into text: that is speech recognition. A photo-inspection application needs an explanation of an image: that is visual understanding. A design team needs a new illustration: that is image generation, which is different from classification or extraction.
A scenario can combine several workloads. Consider a customer-support intake workflow that receives a voice message, transcribes it, extracts a product identifier, determines whether the speaker requests a refund, and drafts a suggested response. Speech recognition, text analysis, information extraction, and generative AI are separate operations with separate failure risks. An agent becomes relevant only if the software must choose and invoke tools or follow a multi-step goal rather than generate a single response. For each operation, write down its input, expected output, suitable capability, and a test that would reveal a wrong answer.
Next consider the responsible-AI implications of the same workflow. Speech transcription might fail more frequently with certain accents; sentiment analysis can misread sarcasm; a generated response might promise a refund that company policy does not authorize; captured audio is sensitive customer data. Six Microsoft principles—fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability—become concrete review questions here. Who reviews refusals? Can the customer correct a transcript? Is the response identified as AI-generated? What information is retained? Responsible AI is not a separate vocabulary unit to forget after the first practice quiz.
Organize Foundry study around four connected actions
A productive implementation sequence is to understand four things: a model, a prompt, a client, and an agent. Start with a model because it has capabilities and operational constraints, including supported modalities, region availability, latency, deployment options, and configuration parameters. Explore why a text-only model cannot simply be assumed to accept an image, why an image-generation model has a different output contract, and why maximum output length or sampling settings can change the shape of a reply. Do not treat a brand or model family as universally available in every Azure region or deployment tier.
Add prompts next. A system instruction expresses ongoing behavior such as “Use only the supplied policy facts”; a user message supplies the actual question or content. A strong prompt specifies task, audience, permitted evidence, output shape, and what to do when evidence is missing. Compare a vague request, “Answer this customer,” with a bounded one, “Summarize the customer request in two sentences, identify any missing invoice number, and avoid promising an outcome.” Inspect how the output changes. Prompts influence a model but do not enforce permissions or guarantee truth. Sensitive actions need authorization checks in the application.
Then follow a lightweight chat client. It creates a client authenticated to a service, calls a deployment with input, handles a response, and presents it to the user. Learn how to recognize the deployment name and endpoint instead of assuming a hard-coded sample path applies forever. Microsoft currently distinguishes the modern Foundry project endpoint from the Azure OpenAI-compatible endpoint; the correct one depends on whether the application uses Foundry-specific agents and tools or only model-completion capabilities. Read version-matched examples before choosing an SDK, because classic and newer Foundry packages can expose different interfaces.
Finally, understand what changes when a single agent is introduced. A simple application can send one prompt and display one answer. An agent has instructions, a role or goal, possible tools, and a cycle in which it can select an action and use its result. A beginner should be able to describe creating and testing one agent in the Foundry portal, connecting a small client, and checking the behavior when a tool returns no useful data. This is not the same task as deploying a multi-agent orchestration platform. The advanced AI-103 agent architecture discussion extends these ideas for professional developer scenarios, while AI-901 focuses on recognizing and constructing the small working flow.
Give text, speech, vision, and extraction their own short experiments
The official practical domain is wider than chatbots. Set aside one small exercise for each remaining family. For text, take a fictional customer review and ask what a classification label, named entity list, sentiment score, and summary would look like. Distinguish a deterministic structured field from a fluent but unsupported narrative. For speech, compare turning audio into text with generating speech from written text. A spoken prompt sent to a multimodal model is also different from an application that explicitly chains speech transcription and a text model. Understand which part performs which transformation.
For vision, ask a model to describe a photo and separately ask an image-generation model to create an illustration. The first operation consumes image data and produces an interpretation; the second generates new visual content. A conventional vision solution might instead extract text from an image or identify object regions. Study input constraints, ambiguous images, and how false descriptions could create downstream mistakes.
For information extraction, compare an invoice PDF, a photograph of a receipt, a recording, and a video. Azure Content Understanding in Foundry Tools addresses structured information across document and multimodal sources; its analyzers and supported features vary by modality and service version. Check current Azure Content Understanding features in Microsoft’s documentation; an old preview-only walkthrough does not establish general availability.
Keep each exercise small enough to evaluate. A useful output record contains the input, task, chosen model or tool, output schema, one expected case, and one failure case. For a receipt parser, a failure might be a total inferred from a blurred image; for a speech system, it might be an inaudible proper noun; for an image generator, it might be a requested change that the model does not follow. These examples teach the distinction between successfully receiving an API response and reliably solving the user’s underlying problem.
Use decision questions to check readiness, not just vocabulary recall
A strong self-assessment does not ask only “What is OCR?” It presents a task and asks you to choose between OCR, image interpretation, document extraction, or image generation. It asks whether a response is a draft to be reviewed or an action that requires a human approval step. It asks which message supplies policy context and which supplies the user’s specific request, or why a deployment that works in a local test might return an authentication error from a different identity. These distinctions reveal actual skill; rehearsing a product-name list often does not.
Run a short review cycle after each domain. For every uncertain answer, mark whether the issue was conceptual vocabulary, service selection, an implementation step, or a safety/authorization decision. Revisit the corresponding issuer objective, reproduce a small reasoning example, and test again with changed input. Memorizing the correct letter of an answer without understanding the failure mechanism does little good when the exam changes its scenario. Use the official exam sandbox for interface familiarity and the available Microsoft practice assessment for a current-format rehearsal; neither is a guarantee of the questions on test day.
A candidate who can justify why a project uses an agent instead of a single model call, identify the model’s allowed input modality, distinguish a speech-to-text tool from text analysis, explain the roles of prompt and SDK client, and spot privacy and fairness risks has a usable foundation for AI-901. Continue into more specialized Microsoft AI-103 material only when deeper app engineering is the actual learning goal. Fundamentals preparation should build accurate small mental models first, not borrow unnecessary enterprise complexity to appear complete.
Check dates, availability, and learning evidence before booking
The Microsoft exam page is the right place to confirm current languages, exam status, scheduling, accessibility arrangements, and the present skills guide. At the date of this article, Microsoft listed AI-901 as current with no announced retirement, an exam passing score of 700, and a skills version effective April 15, 2026. These details are issuer-controlled and may change. Training documents mentioning different Foundry portals, SDK major versions, or model names should be evaluated by their publication dates and targeted service versions rather than silently combined into one imagined interface.
A final study record can be concise: date of the issuer guide reviewed, domain names and relative weight, each of the seven official objective groups, one independently reasoned scenario per group, links to current first-party technical documentation, and a list of gaps to revisit. The point is not to create a long checklist for its own sake. It is to be able to explain—and, where practical, safely demonstrate—the decisions behind an AI solution. The credential is a starting point for informed development, not evidence that every Foundry workload has been deployed or that a production system is ready to go live.