Azure AI Fundamentals (AI-901) — My Study Notes

These are my own condensed notes from studying for AI-901 (Azure AI Fundamentals) — Microsoft's 2026 refresh of AI-900, which folds implementation work into the unified Microsoft Foundry portal. I've organised them around the two domains Microsoft publishes for the exam rather than copying any single prep guide, and the examples are ones I came up with while trying to make the concepts stick for myself. Treat it as a revision aid, not an official syllabus.

1.1 Responsible AI principles

Microsoft groups responsible AI into six principles. The exam rarely asks you to define them — it gives you a scenario and expects you to name the principle it violates or satisfies.

Fairness

An AI system should produce similar outcomes for similar people, regardless of protected characteristics like gender, race, age, or disability.

• Data bias — the training set over- or under-represents a group.
• Algorithmic bias — the model amplifies a pattern that correlates with a protected characteristic even if that characteristic was never an explicit input.
• Mitigation — rebalance the training data, test performance per subgroup (not just overall accuracy), and use tools such as Fairlearn to measure and reduce disparity.

Example I use to remember it: a CV-screening model trained mostly on past hires from one university starts down-ranking equally qualified graduates from other schools. Nobody told it to discriminate by school — it inferred a proxy for something else.

Reliability and safety

The system should behave consistently under normal conditions and fail safely — not confidently — when it meets something it wasn't trained for.

• Robustness to noisy, incomplete, or adversarial input.
• Graceful degradation: returning "not confident enough" beats guessing.
• Azure angle: Azure AI Content Safety for filtering harmful output, plus monitoring/testing built into Azure Machine Learning pipelines.

Example: a shelf-scanning model in a warehouse that has only ever seen well-lit photos should say "unable to classify" under flickering fluorescent light — not silently misreport stock.

Privacy and security

Sensitive data must be minimised, protected, and used only with consent.

• Data minimisation — collect only what the task needs.
• Anonymisation / pseudonymisation — strip identifying details before training.
• Encryption at rest and in transit; Azure Key Vault for secrets, Private Link to keep traffic off the public internet.
• Two attack types worth recognising: model inversion (reconstructing training data from outputs) and membership inference (working out whether a specific record was in the training set).

Inclusiveness

The system should be usable by people regardless of ability, language, age, or access to modern hardware.

• Design for accessibility (screen readers, captions, alternative input) from the start rather than bolting it on.
• Consider the digital divide — not every user has a fast connection or a recent device.
• Azure angle: Azure AI Speech for accents/dialects, Azure AI Translator for language coverage, OCR for screen-reader-friendly text extraction.

Transparency

Users should know they're talking to an AI, roughly how it reached a decision, and where it's likely to be wrong.

• Global explainability — how the model behaves overall (e.g. "credit score is the heaviest-weighted factor").
• Local explainability — why this specific prediction came out the way it did.
• Simpler models (decision trees, linear regression) are naturally more interpretable than deep neural networks, which is a trade-off worth calling out when a scenario asks for an explainable system.

Accountability

A named human or team must own the outcome of an AI system — not just its code.

• Human-in-the-loop for consequential decisions.
• Governance — policies and review boards for AI risk.
• Auditability — logs that let you reconstruct what happened.
• Azure angle: Azure RBAC for ownership boundaries, Azure Monitor / Log Analytics for the audit trail.

1.2 AI model components and configuration

How generative models actually produce output

The pipeline, end to end:

1. Pre-training — the model learns grammar, facts, and patterns from a huge, mostly unlabeled corpus, usually via a next-token-prediction objective (self-supervised learning).
2. Fine-tuning (optional) — further training on a smaller, labelled, domain-specific set to specialise the model.
3. Inference — a user sends a prompt, it's broken into tokens (roughly ¾ of a word each), the model predicts the next token repeatedly, and the result is decoded back into text as the completion.

Terms worth locking in: parameters are the learned internal weights (capacity roughly scales with parameter count); a token is the unit the model actually bills and reasons over; inference is simply "running the trained model to get an answer."

Sampling controls how the model picks the next token:

Picking the right AI capability for a task

The exam likes to describe a business need and expect you to name the matching Azure capability. I find it easier to sort by what the task fundamentally does:

A trap the exam sets deliberately: not every "smart" task is generative. "Predict next month's revenue" is regression, not generation, even though it sounds futuristic.

Deployment options

Where a model runs changes its latency, cost model, and connectivity requirements.

Rule of thumb I use: "immediate" or "interactive" → real-time endpoint. "Overnight" or "thousands of files at once" → batch. "Factory floor," "no connectivity," or "can't leave the building" → edge. "We already run Kubernetes" → container.

Configuration parameters that shape a generative response

{
  "prompt": "Summarise this support ticket in one sentence.",
  "temperature": 0.2,
  "top_p": 0.9,
  "max_tokens": 60,
  "stop": ["\n\n"]
}

A low temperature plus a tight max_tokens is the classic setup for anything that needs to be consistent — data extraction, classification-by-prompt, or a customer-facing summary. Push temperature up only when you actually want variety, like brainstorming or creative copy.

1.3 AI workloads

Generative AI vs. agentic AI

Both can involve a language model, but they answer different questions:

The keyword to watch for is whether the scenario describes making something versus doing something autonomously, possibly across multiple steps or tools.

Text analysis techniques

Four techniques come up repeatedly, all under Azure AI Language:

A distinction that's easy to blur: keyword extraction returns descriptive phrases ("battery life," "checkout process"), entity detection returns named things with a category attached ("Contoso" → Organization). If the question wants proper nouns with a label, it's entities; if it wants themes, it's keywords.

Speech: recognition vs. synthesis

Both live under a single Azure AI Speech resource. A quick SSML example, since the exam likes to check you know what it's for:

<speak>
  <prosody rate="slow" pitch="+2st">Take a breath before we continue.</prosody>
  <break time="400ms"/>
  <emphasis level="strong">This part matters.</emphasis>
</speak>

Computer vision and image generation

Analysis (image/video → information):

The Vision-vs-Face distinction above is a favourite exam trap: "detect that someone is smiling" is Vision; "confirm this is employee #4471" is the Face service, and only the Face service carries the consent/privacy baggage that comes with identifying a specific person.

Generation (text/image → new image): Azure OpenAI's image models cover text-to-image generation, inpainting (editing part of an image with a mask and a prompt), and generating variations of an existing image, with control over resolution and quality tier.

Extracting information, whatever the source

The pattern that ties Domain 1.3 together: identify the modality first, then pick the service.

A two-step pattern shows up a lot: to get sentiment out of a phone call, you transcribe first (Speech), then run the transcript through Language. The exam sometimes describes this whole chain and expects you to name both services in order.

2.1 Generative AI apps and agents in Microsoft Foundry

System prompts vs. user prompts

Things that consistently make a prompt better, in the order I check them: be specific rather than vague; break a multi-part task into explicit steps; give the model a role ("you are a strict code reviewer"); state the output format you want (JSON, a table, three bullet points, a word limit); and, for anything pattern-based, show one or two examples inside the user prompt (few-shot).

Deploying a model and testing it in the Foundry portal

Key vocabulary: the model catalog is where you pick a foundation model (GPT, Llama, Phi, and others); a deployment is a named, configured instance of that model; the endpoint is the REST URL you call; a token is the billing/limit unit (roughly 4 characters or ¾ of a word).

Flow: open your Foundry project → Model catalog → pick a model → Deploy as a real-time endpoint → give it a deployment name, choose standard (pay-as-you-go) or provisioned (reserved capacity) throughput → wait for it to come online → test it in the Chat playground, where you can edit the system message, type a user message, and tune temperature/top-p/max tokens live before writing a single line of code.

Standard billing is per-1,000-tokens with variable latency — good for development. Provisioned billing reserves hourly capacity for consistent low latency — better once traffic is predictable and production-grade.

A minimal chat client with the Foundry SDK

Once a deployment exists, calling it from code follows the same shape every time: authenticate, build a client pointed at your deployment, assemble a message list, call complete, read the response.

from azure.ai.inference import ChatCompletionsClient
from azure.ai.inference.models import SystemMessage, UserMessage
from azure.core.credentials import AzureKeyCredential
 
client = ChatCompletionsClient(
    endpoint="https://<your-project>.cognitiveservices.azure.com/",
    credential=AzureKeyCredential("<api-key>"),
    deployment="<deployment-name>",
)
 
messages = [
    SystemMessage(content="You are a terse recipe assistant. Reply in under 40 words."),
    UserMessage(content="What can I make with eggs, spinach, and feta?"),
]
 
response = client.complete(messages=messages)
print(response.choices[0].message.content)

For a multi-turn client, append each AssistantMessage back onto the messages list before the next call — the API itself is stateless, so you are the one carrying the conversation history forward.

Single-agent solutions

An agent is a model plus tools, optional grounding data, and an orchestration loop that decides which tool to call and when — the thing that turns "answers from training data" into "can actually go do something."

Building one in the Foundry portal: create the agent, give it a name/model/system prompt, add tools (Bing search for live web data, Azure Functions or a REST call for custom logic, a code interpreter for calculations, or file/data grounding to answer from your own documents), optionally add knowledge (upload files or connect a data source so it stops guessing), decide whether tool calls need human confirmation or can run automatically, then test it in the Agent playground, which shows the reasoning/tool-call trace so you can see why it did what it did.

A minimal client for an agent

Talking to an agent from code introduces two ideas a plain chat client doesn't need: a thread (the conversation session) and a run (one execution of the agent against that thread).

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import MessageTextContent
from azure.core.credentials import AzureKeyCredential
import time
 
project = AIProjectClient.from_connection_string(
    credential=AzureKeyCredential("<api-key>"),
    conn_str="<project-connection-string>",
)
 
agent = project.agents.get_agent("<agent-id>")
thread = project.agents.create_thread()
 
project.agents.create_message(thread_id=thread.id, role="user",
                               content="What's the latest release version of Azure AI Foundry?")
 
run = project.agents.create_run(thread_id=thread.id, agent_id=agent.id)
 
while run.status in ("queued", "in_progress", "requires_action"):
    time.sleep(1)
    run = project.agents.get_run(thread.id, run.id)
    if run.status == "requires_action":
        # the agent is waiting on a tool result — supply it via submit_tool_outputs
        pass
 
for msg in project.agents.list_messages(thread_id=thread.id).data:
    if msg.role == "assistant":
        for part in msg.content:
            if isinstance(part, MessageTextContent):
                print(part.text.value)

Run statuses worth memorising: queued/in_progress mean keep polling; requires_action means the agent is stuck waiting on a tool's output and you must call submit_tool_outputs; completed means read the messages; failed/cancelled mean stop and check what went wrong.

2.2 Text and speech solutions in Foundry

A lightweight text-analysis app

The same ChatCompletionsClient from 2.1 can double as a text-analysis tool if the system prompt tells it to: put the extraction instruction in the system message, the raw text in the user message, and (if you need structured output) ask for JSON explicitly.

response = client.complete(messages=[
    {"role": "system", "content": "Extract entities and overall sentiment. Reply as JSON with keys 'entities' and 'sentiment'."},
    {"role": "user", "content": "Contoso shipped the update a week late, but support was excellent."},
])

Responding to spoken prompts with a multimodal model

A multimodal deployment (for example a Phi-4-multimodal style model) can accept an audio clip inline alongside text, so the same chat-completion call that handles text can also transcribe and answer a spoken question in one round trip:

from azure.ai.inference.models import UserMessage, TextContentItem, AudioContentItem, InputAudio
 
response = client.complete(messages=[
    {"role": "system", "content": "Answer the spoken question in one short sentence."},
    UserMessage(content=[
        TextContentItem(text="Here's the question as audio:"),
        AudioContentItem(input_audio=InputAudio.load(audio_file="question.wav")),
    ]),
])

Building with the Azure AI Speech SDK directly

For a dedicated "listen and speak" loop — rather than sending audio into a chat model — the Speech SDK handles both directions:

import azure.cognitiveservices.speech as speechsdk
 
recognizer = speechsdk.SpeechRecognizer(speech_config=speech_config)
heard = recognizer.recognize_once().text
 
# ...send `heard` to a language model, get back `reply`...
 
synthesizer = speechsdk.SpeechSynthesizer(speech_config=speech_config)
synthesizer.speak_text_async(reply).get()

The end-to-end shape for a voice assistant is always: capture → recognise (STT) → process with a language model → synthesise (TTS) → play back.

2.3 Vision and image generation in Foundry

Interpreting images

Just like audio, an image can ride inside a chat message as an ImageContentItem, which unlocks captioning, visual Q&A ("what colour is the packaging?"), counting, and reading on-image text in a single call:

from azure.ai.inference.models import UserMessage, TextContentItem, ImageContentItem, ImageUrl
 
response = client.complete(messages=[
    {"role": "system", "content": "Describe what's happening in the image in one sentence."},
    UserMessage(content=[
        TextContentItem(text="Describe this:"),
        ImageContentItem(image_url=ImageUrl.load(image_file="warehouse.jpg")),
    ]),
])

Generating new images

Deploy an image-generation model from the catalog, send a descriptive text prompt (and, for edits, an existing image plus a mask), and get back a generated image as a URL or binary payload. Typical uses: mockups, concept art, marketing variants, and masked edits ("change only the background to a studio backdrop").

Putting it together in a small app

The architecture is consistent whether you're interpreting or generating: a simple frontend collects an image and a question (or a prompt), the backend forwards it to the deployed multimodal or image-generation model in Foundry, and the response — text or a new image — gets displayed. Swapping text input for image input barely changes the client code; the SDK carries the extra content type for you.

2.4 Information extraction with Azure Content Understanding

How it differs from Document Intelligence

Every field extracted by Content Understanding can be produced three ways: extract (pull an exact value), classify (assign it to a predefined category), or generate (produce a new summary/insight that isn't literally present in the source).

Documents and forms

Beyond raw text, it captures selection marks (checkboxes), barcodes, mathematical formulas, tables (including multi-page and spanning cells), and hierarchical sections. Prebuilt analyzers cover general reading/layout plus domain-specific document types — financial (invoices, statements), identity (passports, licences), tax forms, mortgage/lending paperwork, procurement contracts, and utility bills — so you often don't need to design a custom schema at all.

Images

The same service handles unstructured photos, not just scanned forms: OCR on signage or packaging, object and people detection, logo/landmark recognition, and parsing charts/graphs into structured data. The service auto-detects whether it's looking at a clean document layout or a natural scene and adjusts its preprocessing (deskewing, contrast correction) accordingly.

Audio and video

Every extracted fact carries temporal grounding — a timestamp range and speaker label — which is what makes the output auditable rather than a black box:

{
  "field": "ActionItem",
  "value": "Send the revised proposal by Friday",
  "grounding": { "startTime": "00:12:04", "endTime": "00:12:11", "speaker": "Speaker A", "confidence": 0.91 }
}

Practical limits worth knowing exist for both — rough caps on file size and duration, and video processing is batch rather than real-time because sampling and analysing frames simply takes longer than reading an audio waveform.

Cross-cutting trigger words

The fastest way I've found to move through scenario questions: scan for one of these words first, then pick the service.