AI-901 sample questions — 25 answered and explained

Privacy and security includes making sure an AI system cannot be used to reveal private personal or organisational details.

Microsoft's guidance says developers must keep data secure and make sure the system itself cannot be used to reveal private personal or organisational information. Here prompts extract colleagues' salaries, so the assistant fails privacy and security. Reliability and safety is tempting because prompts are being used to misuse the system, but the content filters are built for harmful content categories; the harm here is the exposure of personal data.

1. Identify what leaked: personal salary data.
2. Recall that privacy and security covers what the system can be made to reveal, not just stored files.
3. Explain why the content filters stayed silent: salary figures are not a harmful-content category.
4. Choose privacy and security.

Exam tip: If an AI system can be coaxed into revealing personal data, privacy and security has failed.

Privacy and security: protect training data and prevent the model from exposing it.

The privacy and security principle covers both the data used to build an AI system and the system's outputs. Developers must keep training data secure and make sure the trained model cannot be used to reveal private personal or organisational details. The other options describe fairness, transparency and reliability and safety.

1. Recall the scope of privacy and security: data in and data out.
2. Match each option to a principle.
3. Choose the one about the model exposing personal data.

Exam tip: Privacy and security covers what a model could leak, not only where data is stored.

Inclusiveness: AI solutions should empower everyone and not exclude some users.

A voice-only kiosk excludes people who cannot hear its answers or speak their questions. Adding captions, typed input and speed control removes those barriers so the benefit is open to everyone. That is inclusiveness. Fairness is the near-twin, but it is about equal outcomes from the model, not equal ability to use the system.

1. Identify who was excluded: people with hearing or speech impairments.
2. See that the change adds ways to interact.
3. Map widening access to inclusiveness, not fairness.

Exam tip: Removing barriers so everyone can use the system: inclusiveness.

Inclusive design: involve diverse users so the solution does not exclude anyone.

Inclusiveness asks that AI solutions benefit everyone, including people with disabilities and people from different backgrounds. The most effective way to achieve that is to involve a diverse range of people in design and testing, so barriers are found and removed early. The other practices are valuable, but they serve fairness, transparency and reliability and safety.

1. Restate the principle: nobody should be excluded from using or benefiting from the app.
2. Ask which practice finds exclusion early.
3. Reject the practices that belong to fairness, transparency or reliability.
4. Choose involving diverse people in design and testing.

Exam tip: Inclusiveness is designed in by involving diverse users early.

Telling fairness (unequal quality of service between groups) apart from inclusiveness (people unable to use the system).

The two findings are different kinds of harm. Higher error rates for some accents mean a group gets lower-quality results from a service they can use, which is a fairness issue (Microsoft's Responsible AI Standard treats quality-of-service differences between groups as fairness). Having no non-speech option means some customers cannot use the service at all, which is inclusiveness. Mixing the two up is the common mistake.

1. Separate the two findings.
2. Accent error gap: a group receives worse results, so fairness.
3. No alternative to speech: some people are shut out, so inclusiveness.
4. Reject principles not involved: transparency, accountability, privacy.

Exam tip: Worse results for a group = fairness; can't use it at all = inclusiveness.

Transparency: make users aware that AI is used, how it works and its limitations.

Transparency means people should understand how an AI system works and what its limitations are, especially when it informs decisions about them. Disclosing the use of AI, describing the training data (without revealing confidential details) and stating known limitations are all transparency practices. Accountability is the tempting near-twin, but it is about people and organisations being answerable, not about explaining the system.

1. Identify the action: telling people about the AI system.
2. Note it covers use of AI, data and limitations.
3. Map explaining the system to transparency.

Exam tip: Disclose AI use, data and limitations: transparency.

Transparency for generative AI: disclose AI involvement and limitations so users can calibrate trust.

The problem is a misunderstanding: users don't know they are talking to AI, so they over-trust it. Transparency addresses that directly by making the AI's involvement and its limitations clear. Ownership, content filters and accessibility are worthwhile but address accountability, safety and inclusiveness, and none of them corrects the users' belief.

1. Diagnose the problem: users misunderstand what the system is.
2. Map misunderstanding to transparency.
3. Choose the change that discloses AI use and its limits.
4. Check the other options against their own principles.

Exam tip: When users over-trust AI because they don't know it is AI, the fix is disclosure.

Interpretability (global and local explanations) is a key part of transparency.

When AI informs decisions about people, transparency asks that those people can understand how the decision was made. Interpretability tools provide that: global explanations show which features drive the model overall, and local explanations show why one prediction came out as it did. Here the bank needs a local explanation for one applicant. Comparing approval rates across groups is a fairness assessment that addresses a different question, and accountability concerns who answers for the system, not how a decision is explained.

1. Identify the need: explain one specific decision.
2. Recall that explanations of model behaviour are interpretability.
3. Map interpretability to transparency.
4. Reject the group comparison, which tests fairness.

Exam tip: Why did the model decide this? That's interpretability, and it serves transparency.

Accountability: people and organizations are answerable for AI systems, supported by a governance framework.

Accountability holds that the people who design and deploy AI systems are answerable for how they operate. Organizations put that into practice with a governance framework, such as review boards that approve releases and named owners responsible for systems in production. Transparency and reliability may be checked within that process, but the measures themselves are accountability.

1. Identify the measures: an approval board and named owners.
2. Ask what they create: responsibility and governance.
3. Map that to accountability.

Exam tip: Governance and named owners: accountability.

Accountability: AI should not be the final authority on decisions that affect people's lives; humans keep meaningful control.

Microsoft's accountability principle says AI systems should not be the final authority on decisions that affect people's lives and that humans should keep meaningful control. Human review of rejections plus an appeal route to a person does exactly that. The other practices support transparency, fairness and reliability, but in each case the model would still decide alone.

1. Restate the requirement: people, not the model, have the final say.
2. Look for the option that adds human decision-making and recourse.
3. Reject options that improve the model or its documentation but leave it in sole control.

Exam tip: Accountability keeps humans as the final authority on consequential AI decisions.

Transparency (understanding the system) versus accountability (people answerable for it).

The two principles are often confused because both involve openness about AI. Transparency is about making the system understandable: disclosing AI use, explaining decisions and stating limitations. Accountability is about responsibility: people and organizations answer for how the system behaves, supported by governance and human oversight.

1. Recall that transparency is about understanding the system and its limits.
2. Recall that accountability is about people being responsible for it.
3. Reject statements that put responsibility on the model or describe other principles.

Exam tip: Transparency = understandable; accountability = answerable.

Deployment name vs model name vs endpoint.

When you call a Foundry deployment, the model argument is the deployment name, the value in the Name column of the project's deployed models. Many tutorials name the deployment after the model, which hides the difference; here the developer chose support-bot, so that is the value to pass. The resource and project names belong in the project endpoint, https://<resource>.services.ai.azure.com/api/projects/<project>.

1. Separate the three names: resource, project and deployment.
2. Resource and project names form the endpoint used to create the client.
3. The model argument identifies which deployment answers.
4. Pass the deployment name, not the catalog model name.

Exam tip: model= takes the deployment name you chose, not the catalog name.

Model playground compare mode.

The model playground's compare mode runs up to three models in parallel with synchronized input, so each receives the same prompt, system message and parameters and the responses stream side by side. The agents playground focuses on a single agent with tools, batch deployments process files asynchronously and evaluations score outputs against a dataset.

1. The need is interactive, no code, and side by side across models.
2. The model playground is where you try prompts against deployments.
3. Its compare mode handles up to three models with synced prompts.

Exam tip: Side-by-side model testing without code: model playground, compare mode.

Moving from the playground to code.

The model playground's Code tab provides sample code in several languages for the deployment you are testing, and an Open in VS Code for the Web button that imports the code sample and endpoint. Save as agent, Compare models and Tools are playground features for further prototyping, not for getting code.

1. The goal is code that already points at the tested deployment.
2. Find the playground feature that exports samples.
3. The Code tab shows them and can open them in VS Code for the Web.

Exam tip: Playground to app: use the Code tab.

Foundry SDK client library for Python.

The Foundry SDK for Python is the azure-ai-projects package. Code creates an AIProjectClient with the project endpoint and a credential from azure-identity (typically DefaultAzureCredential), then calls get_openai_client() to chat with models and agents. azure-identity supplies the credential but not the client, azure-ai-textanalytics is the Language service library, and azure-ai-inference is a separate, older inference client.

1. Identify which library represents a Foundry project.
2. azure-ai-projects provides AIProjectClient.
3. azure-identity only supplies the credential it needs.

Exam tip: Foundry SDK in Python = azure-ai-projects → AIProjectClient (+ azure-identity for auth).

Getting the OpenAI client from the project client.

In the Foundry SDK, AIProjectClient.get_openai_client() returns an authenticated OpenAI client for the project, which is then used for Responses and Conversations operations such as responses.create. The deployments, agents and connections operation groups manage or inspect project resources; none of them returns a client that generates text.

1. The next line calls responses.create, so the variable must be an OpenAI client.
2. The project client provides one through get_openai_client().
3. The other calls return deployment, agent or connection data instead.

Exam tip: Project client → get_openai_client() → responses.create.

Entra ID authentication and RBAC for the Foundry SDK.

The Foundry project client supports Microsoft Entra ID only. DefaultAzureCredential needs a signed-in identity, which on a developer machine typically comes from az login, and that identity needs a role on the Foundry resource or project, with Foundry User (previously named Azure AI User) the least-privilege role for developers. Passing an API key, changing endpoints or changing the model argument does not fix authentication.

1. The failure is about identity, not about the request content.
2. Authentication: give DefaultAzureCredential a signed-in identity (az login).
3. Authorization: grant that identity a Foundry role such as Foundry User.
4. Remember that the project client does not take API keys.

Exam tip: Foundry SDK auth = Entra ID token (az login / DefaultAzureCredential) + an RBAC role.

Multi-turn state with the Responses API.

Each responses.create call is independent unless you link it to earlier turns. The client can pass previous_response_id with the id of the last response (or use a conversation object) so the service supplies the earlier exchange as context. Reusing the deployment name links nothing, max_output_tokens only caps reply length, and store=False prevents the response from being stored for chaining.

1. Diagnose: the follow-up is answered without the earlier turn.
2. Recall that calls are independent unless state is linked.
3. Link the turns with previous_response_id or a conversation.
4. Reject settings that only affect model choice, length or storage.

Exam tip: No link, no memory: chain turns with previous_response_id or a conversation.

Responses API: instructions vs chained state.

Two facts decide this. First, chaining with previous_response_id (or using a conversation) keeps the conversation history on the service side, so the client does not resend it. Second, the instructions parameter applies only to the response it is sent with: it is not carried over when you chain with previous_response_id, and a conversation stores items, not instructions. So the system rules must be sent on each call. Sending them only on the first call loses them on later turns whichever chaining method is used, and resending the full history breaks the no-client-history requirement.

1. Requirement one: no client-side history, so chain turns on the service.
2. Requirement two: system rules on every turn.
3. Recall that instructions are not inherited through previous_response_id.
4. Combine: chain the turns and send instructions with each call.

Exam tip: Chaining keeps the history but not the instructions; send instructions every call.

What defines a prompt agent.

Foundry Agent Service prompt agents are defined through configuration: a model deployment, instructions that set behaviour, and optional tools such as file search or code interpreter. Foundry runs them with no code or infrastructure to manage. A container image describes a hosted agent, while fine-tuning and search-index settings belong to other workloads.

1. A prompt agent is configuration only.
2. Its parts are the model, the instructions and the tools.
3. Containers mean hosted agents; datasets mean fine-tuning.

Exam tip: Prompt agent = model + instructions + tools, run by Foundry.

Prompt agents: stored instructions, versions, runtime and state.

Moving from a raw model call to a prompt agent changes where the behaviour lives: the model, instructions and tools are stored in the agent definition in the project, so the client sends only the user input, and each saved change becomes a new agent version. The agent still needs a model, Foundry runs it without containers (those are for hosted agents), and multi-turn context still depends on passing a conversation or previous response id.

1. Ask what moves from the client into the agent: the instructions.
2. Recall that agent definitions are versioned when they change.
3. A model is still required, and Foundry runs prompt agents without containers.
4. Conversation state is still passed per call.

Exam tip: A prompt agent stores and versions the instructions; the app still passes the conversation.

Code interpreter for calculations and charts.

The code interpreter tool lets an agent write and run Python in a secure sandbox, which suits calculations, data transformation of uploaded files such as CSVs, and chart generation. File search and Azure AI Search retrieve text for grounding, and an OpenAPI tool calls an external API.

1. The task needs computation and charts over uploaded data.
2. Running code is what code interpreter does.
3. Retrieval tools and API tools do not execute code.

Exam tip: Calculate, transform, chart: code interpreter.

Matching agent tools to knowledge sources.

File search grounds an agent in documents you upload to it, and web search brings in current public information from the web. Together they cover the uploaded policies and this week's announcements. Code interpreter runs code, image generation produces images, and a function tool calls your own application's code.

1. Split the requirement into two knowledge sources.
2. Uploaded documents → file search.
3. Current public web content → web search.

Exam tip: Your documents: file search. Current public info: web search.

Function tools for app-side code.

A function tool gives the model a description of a function and its parameters; when the model decides to use it, the client application runs its own code and returns the result. That is how an agent reaches systems only your app can access. Code interpreter runs in an isolated sandbox, file search over an export is stale, and web search cannot reach internal systems.

1. The data is live and reachable only through the app's own code.
2. The model must be able to ask the app to run that code.
3. A function tool describes the function; the app executes it.
4. Sandboxed code, stale exports and web search all fail one requirement.

Exam tip: Code that only your app can run → function tool.

Testing agents in the agents playground.

The agents playground is where you prototype and test agents without code: configure instructions and tools, add knowledge, hold multi-turn conversations and review tracing and evaluation data for each response. Compare mode and the Code tab belong to the model playground, and evaluation runs score outputs against a dataset.

1. The subject is an agent, not a bare model.
2. The need is interactive, multi-turn, with tool visibility.
3. That is the agents playground, which includes tracing.

Exam tip: Test an agent interactively in the agents playground.