A small chat client is the most useful Foundry starting point
Microsoft’s AI-901 implementation domain expects beginners to create effective prompts, interact with a deployed model in the Foundry portal, and understand a lightweight chat client using the Foundry SDK. This is a different objective from building a high-availability agent platform.
The essential flow is simple: a person submits a request; an authenticated application sends it to the correct project and model deployment; the service produces a response; and the application presents or checks that response. If you can trace those boundaries, the code and portal screens become easier to understand.
A fictional service-desk assistant is a useful example. Its sole task is to summarize a short, non-sensitive incident description and identify the next clarifying question. It must not claim that an incident was repaired, reveal secret data, or call external tools.
The prompt can specify the output structure, and the client can display the generated text with a note that a human should verify it. Because the scenario is deliberately limited, it is possible to compare model outputs without inventing an enterprise system or claiming a real Azure tenant was configured.
The current Microsoft AI-901 skills measured list asks for both portal and client understanding. A portal playground is good for exploring the model and prompt behavior; a small application shows the authentication, endpoint and response structure. Learn both without assuming that a working playground session automatically means every application identity has permission to call the same deployment.
Foundry resources, projects, and deployments solve different problems
A cloud resource represents provisioned capabilities and their access boundaries. A Foundry project provides the development context in which an application can work with models, agents and tools. A model deployment identifies the runnable model configuration selected for a call.
These layers are related, but they are not synonyms. When a sample refers to a project endpoint, it is not simply asking for the model display name. When the call specifies a model argument, that value typically identifies the deployed model name expected by the selected service interface.
In the Foundry portal, a learner should be able to find the model catalog, inspect whether a candidate supports the intended modality, deploy an available supported option with appropriate permissions, and try a small prompt. The exact navigation changes as the product evolves, so current issuer documentation has higher authority than a video captured against an older portal.
Do not assume a deployment can be made in every region, at every pricing tier, or without the RBAC roles required by the subscription. A good learning note records what version of the portal and SDK the walkthrough uses.
Once the model is callable, the rest of the problem is about moving a request through the application. A client needs the correct endpoint, a valid credential, permission to use the resource, a supported model deployment and an input.
An HTTP error caused by a wrong endpoint is not fixed by rewriting a prompt. A permission error is not fixed by changing the model temperature. Distinguishing infrastructure failures from poor prompt outputs is one of the practical insights behind AI-901’s expanded technical emphasis.
Write prompts as task instructions, not magic phrases
Prompt design becomes more reliable when the developer states the job, audience, evidence and expected form. The instruction “Help with incidents” leaves too much open. A better instruction is: “Given the fictional incident report below, return an impact summary, two facts directly supported by the report, and one question that would resolve the main uncertainty.
Do not claim that any remediation has been completed.” This gives the model an observable output contract. If the report does not identify a root cause, the response should say so rather than invent one.
Distinguish persistent instruction from task-specific input. A system instruction expresses boundaries and the role of the assistant across requests. A user message provides the individual question or data for the current request. In a chat interface, additional turns may change the conversation context.
These categories matter because a system-level instruction should not be silently overridden by text inside a retrieved file. However, prompt priority alone is not a substitute for access-control checks: the application must still decide which records and actions are authorized.
A useful test changes one factor at a time. First ask for a free-form summary and inspect what the model chooses to mention. Then specify three fields and test whether all appear. Next remove a critical fact and see whether the model admits it is missing.
Finally include a misleading sentence from the fictional report that says to ignore the assigned task; check whether the application keeps the report as data. The goal is a stable, reviewable answer, not perfect compliance with a particular example prompt.
Understand the modern Foundry SDK’s two client surfaces
Microsoft’s explanation of Foundry SDKs and endpoints describes a project client for Foundry-specific operations and an OpenAI-compatible client for model response calls. In the newer Foundry Python SDK, the project client can be constructed with a project endpoint and Microsoft Entra credential, then provide access to a response client.
Other model APIs may use an Azure OpenAI-compatible endpoint directly. The choice depends on the deployment and required capabilities; a copied example from “Foundry classic” may have different library versions and cannot be assumed interchangeable with the current Foundry portal.
For example, current Microsoft documentation shows a Python client using AIProjectClient from azure.ai.projects with DefaultAzureCredential from azure.identity, followed by get_openai_client() and a responses.create() call. The following adaptation keeps endpoint and deployment values in environment settings rather than embedding tenant-specific details or keys. The code is illustrative and not claimed to have been executed against an Azure subscription:
import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
project = AIProjectClient(
endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
credential=DefaultAzureCredential(),
)
responses_client = project.get_openai_client()
result = responses_client.responses.create(
model=os.environ["FOUNDRY_MODEL_DEPLOYMENT"],
input=(
"Summarize this fictional incident. State two supported "
"facts and one missing detail. Report: A store checkout "
"failed for several customers after a deployment."
),
)
print(result.output_text)Read the client line by line instead of memorizing it
The credential object requests the necessary authentication through an available supported identity; it does not hard-code a password in the article. The endpoint identifies the project. The model argument selects the deployment for the response request. The input is the content the model processes.
The result exposes generated output that the application can display after checking it. If a candidate can locate these five responsibilities, adapting to versioned SDK interfaces is easier than memorizing a single variable name. Microsoft distinguishes new Foundry 2.x packages from classic 1.x packages, so the package and portal version must be checked together.
A real implementation needs supporting work omitted from this minimal teaching example: validating environment configuration, handling failed authentication, applying retry guidance responsibly, protecting input data, bounding request size, recording non-sensitive diagnostics and checking whether the response meets the application’s quality requirements. Such handling is not proof that the model knows the answer. The generated text is a proposed summary, not evidence that checkout service was repaired. An incident timeline or operational log would be required to make that claim.
If the endpoint is correct but the call fails, diagnose in layers. Is the subscription and tenant the intended one? Does the identity hold the role required for this project? Is the deployment name spelled as configured? Does the chosen SDK match the portal and endpoint type? Is the feature actually available in the selected region? These questions prevent a common beginner mistake: altering business prose to fix a configuration problem that has nothing to do with language generation.
Evaluate output quality against source facts and expected form
A successful API response does not prove a useful or safe answer. For the service-desk scenario, compare the summary to the original fictional report. The model should identify a checkout failure affecting customers after a deployment, but it should not assert a verified root cause, duration or fix. Its clarifying question could ask which application version was deployed or how many transactions failed. If it writes “The database was unavailable for 42 minutes,” that is an unsupported inference despite sounding operationally plausible.
Next test structured output expectations. A response that asks for “two supported facts and one missing detail” can be evaluated for completeness. Another input might be a support request containing two unrelated problems; a robust answer should not drop the second one just because the model prefers a single summary.
A third could include personally identifiable data that is not needed for the task; a safer application would minimize that data before sending it. This creates a natural connection between prompt quality, workload selection and responsible AI.
For AI-901, the crucial distinction is between how a model is called and whether it is appropriate to trust its answer. A lightweight chat app can demonstrate the mechanics without solving all production concerns. The deeper Foundry project and deployment issues—network design, operational controls and production security—belong to more advanced engineering work rather than every fundamental study example.
Make the next exercise deliberately different
After the incident-summary example works conceptually, change the workload rather than simply improving the prompt forever. Ask the same model to classify a message into a small allowed set of service-desk categories, then ask what a text-analysis service might do differently. Later, compare a tool-enabled agent that can look up an authorized ticket with a direct model call that cannot retrieve current ticket status. That comparison reveals a real boundary between ordinary inference and tool use without requiring a large multi-agent environment.
Maintain a small evidence log: source documentation version, project/endpoint type, deployment name placeholder, what the input asked for, what the model produced and which claims were verified. Record limits rather than treating a demonstration as a production success. The objective is the ability to explain prompts, deployment, a Foundry SDK client and safe output review in ordinary technical language. When those pieces fit together, you have the implementation foundation the current AI-901 syllabus is asking for.