Microsoft AI-901: Foundry Models, Prompts and Python Clients
A deployed model and a client are two different deliverables
AI-901 now includes implementing a model interaction with Microsoft Foundry. It is not enough to identify a language model’s general purpose on an exam flashcard. A model must be available to a project, a suitable deployment must be selected, and a client must authenticate and send an appropriate request. The project must also be able to explain what happens if the model name, regional availability or caller’s permission is wrong.
The official Foundry SDK quickstart demonstrates the distinction between using a deployed model and creating an agent; both belong to the current Microsoft AI learning route. This article follows the exam’s basic build-and-test intent, not an independently executed cloud lab. It describes a reproducible small project with checks for valid outcomes and common failures.
Use synthetic task examples before connecting organizational records. For instance, ask a model to summarize three invented service tickets, keeping input and expected output in a controlled test file. Do not try to prove a deployment is safe by copying production customer records into a playground. Keep the reference data independent so a plausible hallucination is detectable.
Prepare an authorized Foundry project
Begin by confirming the Azure subscription, tenant, supported region and Foundry project you are authorized to use. A candidate should know that project-level permissions and resource-level permissions affect what can be deployed or viewed. Simply having a Microsoft account is not sufficient to create an arbitrary paid deployment. Request the least privilege necessary and understand any cost or quota implications before selecting a model.
Record the project endpoint from the Foundry project rather than guessing it from a resource nickname. Microsoft’s current quickstarts show an endpoint identifying both the Foundry resource and project. A model deployment identifier is distinct from the underlying model family name. Your client must address the deployment that actually exists in that project, even when a tutorial casually refers to the model by its marketing name.
Do not put a client secret or subscription key directly in checked-in tutorial code. For educational Python scripts, Microsoft shows an identity-based option using `DefaultAzureCredential` and `azure-identity`. The authenticated account must have permission for the exact endpoint. If local authentication succeeds for one project but returns forbidden for another, diagnose the role assignment instead of disabling identity checks.
Choose a model against the task’s actual capability
The model catalog offers different reasoning, text, vision and other capabilities subject to the service and region. For a beginner chat client, select a model supported for text generation and suitable for the requested response length. If the later task includes images, confirm that the deployed model supports visual input rather than assuming every text-capable model does. The cheapest model is not always the right one if quality failures create extra review work.
Document the selected model or deployment name, supported input type, expected response style, content safety behavior and maximum task size. Those facts help you compare a simple prompt with a changed prompt or a different deployment. Model versions may change over time, so fixed screenshots or SDK instructions must be cross-checked with current Microsoft product documentation instead of treated as timeless implementation truth.
An appropriate educational prompt might ask for a concise two-paragraph summary of synthetic tickets, each with a case number. If the model invents a missing case or confuses account data, mark it as a test failure. The correct model choice depends on whether it can perform the stated task within the intended reliability and access constraints, not on whether it sounds confident.
Write system and user prompts with a stable contract
A system instruction states durable boundaries such as role, permitted sources, output form and what to do when information is missing. A user prompt supplies the current task. Mixing all constraints into a single free-form user message makes it harder to test whether the app respects the same rules on the next request. Clear separation also allows an app to reuse policy while users submit different inputs.
Prompts should avoid impossible commands. A model told to ‘always cite the official ticket database’ cannot comply when no retrieval connection exists. Instead, require citations only to supplied evidence and allow an explicit ‘not available’ outcome. For a structured summary, define required fields and error values. A practical evaluation should include an empty ticket list, duplicate case IDs and a note containing an irrelevant instruction.
The model response is not the same as a verified database write. Prompts can propose actions but only authorized application code or a governed tool should perform them. If an AI-901 learner demonstrates a chat response that says ‘ticket updated’, the demonstration is incomplete unless an actual task-specific backend exists and returns independent confirmation. For a safe fundamentals example, keep the workflow read-only.
Connect using a supported SDK instead of copying stale snippets
Microsoft’s current Python SDK quickstart uses `AIProjectClient` with a project endpoint and `DefaultAzureCredential`, and shows a model response interaction before creating an agent. The surrounding package imports and API surfaces can evolve across SDK versions. Confirm the documentation version and install the compatible packages shown in the live guide rather than guessing an old `azure-ai-projects` method signature.
A minimal client should load the intended endpoint and deployment configuration, authenticate, submit a short synthetic request, receive response content, and record success or an actionable error. Avoid printing credentials or sensitive requests into ordinary logs. One request is enough to prove connectivity in a test environment, but it does not prove production reliability, rate-limit behavior or coverage for all supported modalities.
Common failure patterns include a malformed project endpoint, an unavailable deployment, insufficient resource privileges, an unsupported response parameter, quota exhaustion and a network path the client cannot reach. Diagnose them as distinct classes. Repeating the same failing request without checking the service status is not a useful troubleshooting method and may incur unnecessary charges.
Validate the interaction beyond a friendly greeting
Write a compact acceptance set with at least one expected success and several expected failures. A model can greet the user while still failing the real task. For the synthetic ticket example, check whether case IDs are preserved, dates are not invented, and irrelevant instructions inside ticket text do not override the system-level output contract. Compare actual responses with reference facts rather than relying on eloquence.
Test a malformed or missing input and observe whether the client exits safely. Test a user prompt requesting restricted information that the application has not supplied. Test a longer valid request within documented limits and note latency or truncated output. These outcomes demonstrate how the client handles the real interface, not merely what a model claims it can do.
Record the model/deployment identifier, prompt revision, test input category, observed result and a short explanation of the discrepancy. Such a log supports improvement when a model or SDK changes. Do not place secrets or production personal data in it. AI fundamentals include understanding that generated language is probabilistic and that operational confidence comes from repeatable tests.
Interpret configuration options without treating them as guarantees
Foundry deployments and model interfaces may expose controls for output length, model reasoning or generation behavior, but availability differs by model and API. A parameter that is accepted by one model may not be supported by another. The correct implementation reads the selected model’s documentation and avoids assuming that a universal temperature or response format exists across every Foundry provider.
Limit the response to what the application can display and validate. For a beginner client, a short answer with documented error handling is often better than generating pages of uncertain text. In a structured-output task, validate required fields independently even if the model interface supports a schema. The application is responsible for deciding what to do when the output does not conform.
Model selection and settings also have cost implications. More requests and longer output consume resources, and failed retries may increase spend. Use a small test budget and record what is actually measured. An article that offers conceptual configuration advice should not claim precise benchmark speed, model pricing or a production reliability percentage without a tested workload.
Keep a model app different from an agent
A simple client sends a prompt and receives a response. An agent can maintain instructions and, depending on configuration, use tools or orchestrate additional steps. The two experiences share models but have different lifecycle and permission questions. Do not describe a single response as proof that an agent successfully coordinated work, accessed a knowledge source or performed an authorized tool action.
The companion Foundry single-agent client guide starts with the same approved project and asks how persistent instructions, agent identity, follow-up interactions and tested tools should be managed. That is a separate practical subskill in the AI-901 study guide. A learner should be able to explain why one application might need an agent while another is adequately served by a straightforward model call.
A high-consequence workflow might need approval, audit and deterministic validation that exceed an introductory agent demo. AI-901 tests light implementation awareness, not a guarantee of competence to operate an autonomous financial or medical agent. Keep the exercise narrow enough that each action can be inspected and mistakes can be corrected without affecting outside systems.
Close with a deployment and failure checklist
Before marking a model-client task complete, verify the project endpoint, deployment identifier, caller role, prompt structure, safe sample input, expected result, failure path, cost visibility and cleanup plan. Also confirm whether the selected SDK version actually matches the examples you used. If the project setup changed, record that rather than quietly substituting a different deployment and claiming the original procedure succeeded.
A useful practice exercise asks the candidate to diagnose three outcomes: authentication succeeds but deployment lookup fails; a model responds but hallucinates a missing record; or the response format is invalid. The first is an environment/deployment problem, the second a content-quality problem, and the third a client-contract problem. Choose the correct remedy rather than calling every failure an ‘AI issue’.
Use AI-901 preparation scenarios to identify gaps, but third-party practice questions cannot certify a real Azure deployment. The official guide and current SDK quickstart are the authority for product capabilities. No actual Foundry project or Python client was connected or executed in the preparation of this editorial walkthrough.
