Microsoft AI-900 to AI-901 Azure AI Fundamentals Practical Preparation: Scenarios, Exercises, and Skills for the Current Exam

 

Microsoft retired AI-900 on June 30, 2026. Candidates preparing now for Microsoft Certified: Azure AI Fundamentals need to target AI-901, the current exam, rather than treating older AI-900 study plans as complete preparation. Much of the conceptual foundation still transfers—responsible AI, workload recognition, text, speech, vision, and generative AI—but the current blueprint changes the practical standard. Microsoft now allocates 55–60% of the exam to implementing AI solutions by using Microsoft Foundry and explicitly expects foundational Python skills and familiarity with Azure resources.

That makes hands-on rehearsal unusually important for a fundamentals credential. You do not need to build production-scale AI systems, but you should be able to deploy and interact with models, write effective prompts, create small SDK clients, test a single agent, work with text and speech, use multimodal and image-generation capabilities, and perform information extraction with Content Understanding. The goal of the exercises below is to create evidence that you can do those things rather than merely recognize their names.

Keep every exercise small. The learning objective is the AI capability and the reasoning around it, not building elaborate user interfaces or cloud architectures. For each lab, write down the requirement, your chosen capability, one responsible-AI concern, the observed result, and one failure you deliberately introduced or investigated.

Exercise 1: build a clean Microsoft Foundry orientation map

Before deploying anything, create a one-page map of the environment you are using. Identify the relevant Azure resource or project context, where models are selected or deployed, where you can test interactions, how credentials or access are handled, and where an application will obtain the information it needs to connect.

Then explain the map without the portal open. The purpose is to replace click-path memorization with a resource model. Portal layouts change; the relationship between a model deployment and the application that calls it is the durable idea.

Success criteria: you can answer “what resource am I using, what did I deploy, how does my client refer to it, and what permissions are required?” without relying on screenshots.

Exercise 2: deploy a model and run a controlled interaction

Choose a model available to your practice environment that fits a simple text-generation task. Deploy it through the supported Foundry workflow and send a few prompts through the testing experience.

Do not stop after the first successful response. Change one model or generation setting that is exposed in your environment and observe how behavior changes. Keep the prompt constant so you can attribute the difference to the setting rather than to multiple variables.

Write down what the setting influences, what it does not guarantee, and why a production team would test it rather than assume one value is universally best. This turns “model configuration” into an engineering trade-off instead of a vocabulary item.

Exercise 3: compare a weak prompt with a structured prompt

Start with a vague request such as, “Summarize this customer message.” Record the output. Then improve the prompt by adding audience, goal, constraints, and a required output structure. For example, ask for a short summary, detected issue category, urgency indicator, and one recommended next step.

Next, separate persistent behavior into a system instruction and the immediate task into a user prompt. Test whether the model follows the distinction consistently.

The objective is not to discover a magic phrase. It is to understand how clearer context, constraints, and output structure make results easier to evaluate. Record one case where the model still produces an undesirable answer and explain why application validation or human review may be needed.

Exercise 4: responsible AI threat review of your prompt application

Take the small prompt application from the previous exercise and review it under fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability.

If it processes customer messages, ask whether those messages may contain personal data. Could generated urgency labels disadvantage certain users? What happens if a harmful message is missed? Should the user be told that an AI system generated the classification? Who owns the outcome if the model is wrong?

For each principle, write one concrete consideration and one mitigation. This prevents responsible AI from becoming an isolated theory chapter. The strongest preparation connects the principle to the same implementations you are building.

Exercise 5: choose models by capability rather than popularity

Create five short requirements: text summarization, visual question answering, image generation, speech transcription, and document-field extraction. For each requirement, identify the capability class needed before looking at a model catalog.

Then inspect available options and note why a candidate model fits the modality and task. Add one constraint—latency, cost, multimodal input, or deployment availability—and see whether your choice changes.

Success criteria: you can explain why a model is appropriate without saying only that it is “more powerful.” Model selection should be tied to the workload.

Exercise 6: build a minimal Python chat client

Create a small Python file that uses the supported Foundry SDK or current client pattern for your environment. Keep the program intentionally simple: initialize the client, send a system instruction and a user message, receive the response, and print the useful output.

Then rebuild it from a blank file without copying the entire sample. You may check documentation for exact APIs; the point is that you understand the structure well enough to recreate it.

Add one controlled enhancement, such as accepting terminal input, formatting the response, or applying a consistent system instruction. If you cannot explain imports, configuration, environment variables, basic data structures, or response handling, record that as a Python prerequisite gap rather than an AI gap.

Exercise 7: troubleshoot a broken client deliberately

Break one part of the chat client: use the wrong deployment reference, remove a required configuration value, supply invalid access information in a safe practice environment, or make another reversible mistake. Observe the error and trace it to the layer that failed.

The learning objective is diagnostic classification. Was the problem authentication, deployment identification, network/resource access, request formatting, or application code? A candidate who has seen simple failures is less likely to treat every implementation problem as “the model is broken.”

Restore the client and document the shortest evidence that confirmed the fix.

Exercise 8: identify text-analysis tasks from outputs

Prepare a small collection of customer comments, support tickets, or product reviews. For each sample, decide whether you need sentiment, keyword/key-phrase extraction, entity detection, summarization, or a combination.

Before running any capability, write the expected *type* of output. Sentiment should describe opinion or polarity, entity detection should identify named entities or entity types, keyword extraction should highlight salient terms, and summarization should condense content.

Run a lightweight implementation using the relevant tools available in your current Foundry-oriented environment. Compare predicted and actual outputs. Record ambiguous examples where a human might interpret the text differently.

Exercise 9: build a text-analysis mini application

Turn the previous exercise into a small application. It can be a command-line tool: accept a block of text, perform the selected analysis, and present the result clearly.

Add a simple decision rule only if it helps illustrate the workflow. For example, if sentiment is strongly negative, display a recommendation to route the item for human review. Make clear that the rule is application logic, not a fact produced by the AI service.

Success criteria: you can describe input, AI processing, output, application logic, and error handling as separate stages.

Exercise 10: rehearse speech recognition and speech synthesis as separate directions

Create a two-column note: speech recognition converts spoken audio to text or another machine-usable representation; speech synthesis converts text into spoken audio. Then use Azure Speech in Foundry Tools or the current supported practice workflow to exercise both directions.

Speak a short prompt and inspect the recognized text. Change background conditions or pronunciation slightly and notice that recognition quality can vary. Then synthesize a spoken response from text and compare voice/output behavior where options are available.

Do not collapse the two operations into “speech AI.” Exam scenarios often become easy when you identify the direction of transformation.

Exercise 11: respond to a spoken prompt with a deployed multimodal model

Build a minimal chain in which spoken input becomes a prompt to a deployed model and the application produces a response. If your practice setup supports direct multimodal handling, use the current documented approach; otherwise keep the conceptual stages explicit.

Trace the pipeline: capture or receive audio, interpret the spoken content, send the relevant input to the model, receive generated output, and optionally synthesize speech for the reply.

Record where errors can occur. A speech-recognition mistake is different from a model-reasoning mistake, and both are different from a synthesis failure. This layered view is useful in both implementation and exam questions.

Exercise 12: visual question answering with a multimodal model

Select a non-sensitive image that contains enough detail to ask meaningful questions. Use a deployed multimodal model and provide both the visual input and a text prompt.

Ask one factual question directly supported by the image and one question that tempts the model to infer something not visible. Compare the responses. The second test is important because it teaches you to distinguish visual interpretation from unsupported inference.

Then change the prompt to require the model to state uncertainty or restrict itself to observable evidence. Evaluate whether the output improves. Connect the result to reliability, safety, and transparency.

Exercise 13: build a lightweight vision client

Move beyond the portal and create a minimal application that sends visual input plus a question to a supported model and processes the returned answer. Again, keep the user interface trivial.

Your readiness proof is not the number of code lines. It is that you can explain how the image is supplied, how the request indicates the task, what the model returns, and what the application should do if the image is missing, unsupported, too large, or ambiguous.

Save one successful example and one failed example in your study notes.

Exercise 14: generate an image from a controlled prompt

Use an available image-generation capability to create a visual output from a prompt. Start with a broad prompt, then refine composition, subject, context, or style requirements in a policy-compliant way.

Evaluate the result against explicit criteria rather than “I like it.” Did it include the required objects? Did it follow the composition? Are there visual artifacts or unsupported details? How would a business application detect or review unacceptable output?

The exam objective is capability awareness and implementation, not artistic expertise. Focus on the input-output pattern and responsible use.

Exercise 15: compare visual understanding with image generation

Put two screenshots or notes side by side. In the first, the application receives an image and returns understanding. In the second, it receives a prompt and creates an image.

Write three scenarios for each direction. For visual understanding: identify objects, interpret a diagram, or describe visible damage. For generation: create a marketing concept image, produce a draft illustration, or generate a visual variation.

If you can distinguish the direction instantly, you are less likely to choose a generation capability for an analysis requirement or vice versa.

Exercise 16: create and test a single-agent solution

In Microsoft Foundry, create a narrow single-agent exercise. Give the agent a clear role and instructions. If your environment supports tools or knowledge connections suitable for a safe lab, add only what is necessary to demonstrate the difference between a direct chat response and an agent-oriented interaction.

Test at least five prompts: a normal task, an ambiguous task, an out-of-scope task, a prompt that conflicts with instructions, and a request that would require a capability the agent does not have.

Record what the agent does well and where instructions need refinement. The objective is to understand agent behavior and boundaries, not to create a fully autonomous system.

Exercise 17: build a lightweight agent client

Use the supported SDK or current client pattern to interact with your practice agent from a minimal Python application. Send a task, retrieve the result, and display it.

Then explain the difference between calling a general model deployment and interacting with the configured agent. What persistent instructions or resources does the agent bring? What extra governance concern appears if an agent can use tools or take actions?

A Level 3 fundamentals skill means you can make the small client work and explain the conceptual distinction.

Exercise 18: test agent boundaries and accountability

An agent becomes more operationally significant when it can take actions. Even if your lab agent cannot perform consequential actions, simulate the governance questions.

Who approves tool access? Which actions should require human confirmation? What logs or traces would help investigate behavior? How should the application handle an uncertain model response? Who owns a bad outcome?

Map these questions to privacy and security, reliability and safety, transparency, and accountability. This is how responsible AI connects to agent implementation rather than living in a separate checklist.

Exercise 19: extract structured information from a form or document

Choose a synthetic or non-sensitive form such as an invoice, application, receipt, or simple contract. Use Azure Content Understanding in Foundry Tools according to the current supported workflow to extract a set of fields.

Before running the tool, define what “correct” output means: field names, values, types, and how missing information should appear. After extraction, compare output against the source. Note any field that is absent, misread, or ambiguous.

This exercise teaches the difference between free-form summarization and structured information extraction. The downstream application needs predictable fields, not merely a fluent paragraph.

Exercise 20: extract information from an image

Use a photo or screenshot containing structured information such as a label, equipment plate, menu, or sign. Define a small extraction goal and run the appropriate Content Understanding workflow.

Then alter the input quality: crop the image, reduce clarity, rotate it, or choose a busier background. Observe how input quality affects output. This creates practical intuition about why AI extraction still requires validation and why a successful demo is not a guarantee for every production input.

Exercise 21: extract information from audio

Use a short, non-sensitive audio clip such as a mock support call. Define fields to extract: caller intent, product name, reported issue, requested action, or another simple schema.

Run the current information-extraction workflow and compare the structured result with the audio. If the clip contains background noise or ambiguous wording, note whether errors appear in transcription, interpretation, or field extraction.

The exercise helps you recognize information extraction as a goal that can operate across modalities, not as a document-only feature.

Exercise 22: extract information from video

Use a brief practice video with clearly observable events or spoken content. Define a small extraction requirement before processing it. For example, identify an event type, a stated identifier, and a timestamped observation where the supported workflow exposes relevant information.

Keep the video short. The point is to understand that Content Understanding can work with video as an information source and that the desired output must be defined and validated.

Record what information was supported by the media and what would have required unsafe inference. This strengthens both capability awareness and responsible-AI judgment.

Exercise 23: build a lightweight information-extraction client

Once the portal/tool workflow is familiar, build the smallest application that submits supported content and consumes structured extraction results. Parse or display a few fields and handle the possibility that a value is missing.

Do not spend the lab building a database or front end. Focus on the application contract: input, request, structured output, validation, and error handling.

Success criteria: you can explain how unstructured content becomes structured data and why the application must not assume every field is always correct.

Exercise 24: classify six workloads before choosing technology

Write six business prompts without product names:

1. detect sentiment in thousands of survey comments;
2. answer questions about an uploaded photograph;
3. generate a new product concept image;
4. transcribe a spoken instruction;
5. extract invoice number and total into fields;
6. use tools to complete a multi-step support task.

Classify them as text analysis, multimodal vision, image generation, speech recognition, information extraction, and agentic AI before thinking about services. Then choose the relevant Foundry-oriented capability.

Repeat the drill with different industries. If classification remains stable when the business vocabulary changes, your understanding is based on workload rather than memorized examples.

Exercise 25: create a responsible-AI review card for every lab

For each practical exercise, add a small six-row card: fairness; reliability and safety; privacy and security; inclusiveness; transparency; accountability. You do not need an elaborate risk report. Write “material / not material yet” plus one sentence of reasoning.

This habit reveals that principles vary by context. Fairness may be central in a hiring model and less central in a simple image-resizing tool, while privacy may dominate a medical-document extraction workflow. Reliability matters almost everywhere but the consequence of error changes.

The goal is scenario judgment, not claiming every risk is identical.

Exercise 26: compare legacy AI-900 knowledge with current AI-901 evidence

Make two columns. In the first, list transferable conceptual areas you learned from AI-900-era material: responsible AI, common AI workloads, text, speech, vision, and generative AI concepts. In the second, list current implementation evidence required by AI-901: Foundry model deployment, prompts, chat client, agent, agent client, text/speech app, multimodal vision, image generation, Content Understanding, and a lightweight extraction application.

Any concept with no corresponding current implementation experience should become a study priority where the blueprint expects implementation. This prevents a familiar old course from creating false readiness.

Do not discard all AI-900 study material. Use it for transferable foundations while clearly labeling it legacy. The AI-901 readiness matrix provides a structured way to score that transition.

Exercise 27: perform a no-notes rebuild day

Choose three small implementations you have already completed: a chat client, an agent interaction, and an information-extraction workflow. Rebuild them with no step-by-step tutorial open. Documentation for exact current APIs is acceptable after you first identify what you need, but avoid copying a complete sample.

Track where you stall. If you forget syntax but understand the architecture, that is a coding-fluency gap. If you do not know which capability to choose, that is a workload-selection gap. If you can make the client work but cannot explain privacy or reliability concerns, that is a responsible-use gap.

The no-notes day is diagnostic, not punitive. It tells you which knowledge has become usable.

Exercise 28: practice failure analysis rather than only happy paths

Every successful lab should be followed by one deliberate failure. Use an invalid deployment reference, an unsupported input, missing field, ambiguous prompt, poor-quality image, noisy audio, or contradictory agent request. Keep failures safe and reversible.

For each failure, identify the layer: configuration, access, input quality, model capability, prompt design, application code, or validation. Then make the smallest correction that addresses that layer.

AI-901 is a fundamentals exam, so deep production troubleshooting is not the goal. The benefit is learning that an AI solution is a pipeline and that not every failure originates in the model.

Exercise 29: run mixed scenario practice after hands-on work

Once you have implementation evidence, use scenario questions to force selection under uncertainty. Azure AI Fundamentals practice questions can still help reinforce legacy concepts when used carefully, but AI-900 is retired and older question scope must not be mistaken for complete AI-901 coverage.

For every practice question, state whether the tested knowledge is transferable legacy material or current AI-901 implementation scope. If a question only asks for an old conceptual distinction, follow it with a practical prompt: “How would I implement the current equivalent in Foundry?”

Practice-test value comes from diagnosis, not memorizing answer positions. Explain why the best answer fits and why the closest distractor fails.

A practical four-week sequence

In week one, repair foundations. Review responsible AI, model behavior, workload types, and basic Python/Azure skills. Complete exercises 1–7 so model deployment and a small client become familiar.

In week two, focus on text, speech, prompts, and multimodal interactions. Complete exercises 8–15. Finish the week by explaining the direction of every workload from input to output without notes.

In week three, focus on agentic AI and information extraction. Complete exercises 16–23. Spend extra time on Content Understanding because the current blueprint explicitly includes extracting information from documents/forms, images, audio, and video.

In week four, integrate. Complete exercises 24–29, run mixed diagnostics, revisit weak rows in the readiness matrix, and rebuild a few implementations from scratch. Do not use the final week to collect more passive resources; use it to turn weak evidence into strong evidence.

Add a verbal verification step after every hands-on exercise

A practical lab is not finished when the screen shows a successful result. Close the instructions and explain the workflow aloud in your own words. State the business requirement, the AI capability you chose, the Azure or Foundry resource involved, the input you supplied, the output you expected, and the responsible-AI or security concern that still needs review. Then name one plausible failure and the first place you would investigate it.

This step exposes a common weakness in guided labs: the learner can reproduce clicks but cannot reconstruct the decision. For example, after a multimodal exercise, you should be able to explain why the scenario requires visual understanding rather than image generation, how the image and text prompt reach the model, what kind of unsupported inference you tested for, and how you would validate the response before using it in a business process. After an agent exercise, explain the difference between the model’s reasoning and any tool action the agent is allowed to invoke. If the explanation becomes vague, repeat the exercise with fewer instructions until the reasoning is yours.

What “practical enough” looks like for a fundamentals exam

You do not need production CI/CD, large-scale observability, advanced networking, custom model training, or enterprise application architecture to prove AI-901 fundamentals. You do need to understand enough code and Azure resource context to work with the supported tools and SDKs.

A practical candidate can deploy a model, test prompts, build a very small client, create and test a single agent, process text/speech/visual inputs, generate an image, extract structured information, and explain responsible-AI considerations. The implementations can be tiny because depth comes from understanding each stage, not from project size.

If you spend hours styling a web page around a five-line model call, the lab has drifted away from the exam objective.

Final practical readiness checklist

Before final review, confirm that you have current evidence for each of these actions: deploy and interact with a Foundry model; create effective system and user prompts; build a lightweight chat client; create and test a single agent; call an agent from a lightweight client; build or exercise text analysis; respond to spoken input and use speech capabilities; interpret visual input with a multimodal model; generate a visual output; build a lightweight vision workflow; extract information from a document or form, image, audio, and video; and consume extraction results in a small application.

Then confirm that you can explain responsible AI across those implementations and that foundational Python/Azure concepts do not block you.

The transition from AI-900 to AI-901 is not a reason to restart from zero. It is a reason to separate transferable fundamentals from newly emphasized implementation skills. Keep the useful concepts, retire stale exam assumptions, and build enough small Foundry exercises that the current blueprint feels like a set of familiar workflows rather than a list of product names.

Use a final integrated capstone instead of another isolated lab

For the last practical session, combine several objectives into one deliberately small application. A user supplies a short text or spoken request plus an optional image. The application identifies the input type, sends an appropriate prompt to a deployed model, returns a concise answer, and records a simple structured result. Add one narrow agent task only if the requirement genuinely benefits from agent behavior. The capstone does not need to use every service at once; its value is showing that you can choose capabilities intentionally and explain the boundaries between them.

Before running it, write the responsible-AI checklist: what data is sensitive, what output requires validation, what limitations should be communicated, and who is accountable for any action. After running it, introduce one failure such as an ambiguous image or incomplete field and explain whether the correction belongs in the input, prompt, capability choice, application logic, or validation layer.

If you can build and explain that capstone without turning it into a copy-and-paste exercise, you have evidence that the individual Foundry skills are becoming an integrated mental model. That is a much stronger final signal than completing another tutorial whose steps you can follow but not reproduce.

Finally, rehearse explaining each capability in plain language to another person. If you can describe the business requirement, chosen AI workload, implementation path, validation step, and responsible-use concern without relying on product slogans, your practical knowledge is organized well enough to transfer to unfamiliar exam scenarios.