A deployment tutorial can be confusing when it mixes subscriptions, resources, projects, model cards and client endpoints into one sequence. Microsoft AI-901 expects a beginner to understand how to deploy a model and interact with it in the Microsoft Foundry portal. The goal is not to master every infrastructure option; it is to recognize which resource represents which responsibility and how to verify a model is actually callable.
Use fictional, nonsensitive sample data for this lab. An Azure subscription may incur costs, and available models, regions and quotas vary. A successful exercise produces a recorded deployment name, an appropriate endpoint, a tested inference response and a cleanup decision. Taking a screenshot of a model catalog entry alone does not demonstrate that an application can call a deployment.
Identify subscription, resource and project boundaries
An Azure subscription handles administrative and billing scope. A resource group organizes related Azure resources for management. A Foundry resource and project provide an environment for developing and operating supported AI capabilities. Names shown by the user interface can evolve, so rely on the actual resource identifiers and permissions rather than a memorized menu path. Microsoft’s Foundry model-deployment instructions are the authoritative place to check current portal steps.
Choose a disposable learning resource group and record who can access it. Do not connect production storage or directory-wide credentials simply to run a small prompt. Verify the deployment region is appropriate for the information you plan to send. If your account does not have permission to create resources or a model is unavailable in that region, treat that as an access or availability issue—not evidence that the model’s inference behavior is broken.
Read a model card as an engineering document
A model card can indicate the model’s task types, supported input modalities, context capacity, publisher, restrictions, license conditions and available deployment methods. Compare these against the intended task. For a text summarizer, a chat-capable model is a reasonable place to start. For a photo-analysis scenario, confirm image input support instead of assuming all chat models accept photos. For a privacy-sensitive experiment, consider where the inference runs and which processing locations the deployment option supports.
Review model terms when selecting partner or community offerings. Microsoft notes that certain partner/community models require accepting Marketplace terms before deployment, whereas some Azure-sold models follow a different process. Do not assert that one model family, price or deployment type is available in every account. The model selection and deployment parameters explains how to compare capability, performance and processing requirements before provisioning.
Deploy under a stable application-facing name
The deployment name is not necessarily the model’s original catalog identifier. It is the name used by requests to route inference to the selected deployment. Choose a descriptive name for the lab and record the underlying model and deployment type separately. The Foundry portal provides default or customizable deployment settings for supported models, and the exact choices depend on the selected offering.
After submitting deployment, wait for a successful provisioning state before attempting inference. A failure may involve insufficient quota, unavailable region, missing permissions, terms that were not accepted or an incompatible model/deployment choice. Inspect the error rather than repeatedly creating duplicate deployments. The learner should be able to distinguish a provisioning failure from a successful deployment receiving an invalid API request.
Test a narrow prompt in the playground
Open the deployed model’s playground and send a simple request with a verifiable expected outcome: for example, summarize a short fictional support message and return a category from a fixed list. Record the input, resulting category, underlying deployment and any configured output limits. Then try an ambiguous message. A robust application should acknowledge missing information rather than fabricate a specific customer identity or action.
Compare two prompt versions using identical sample cases. One may be vague (“help the customer”); another specifies the task, allowed labels and expected handling of uncertainty. Good instructions improve task clarity but do not prove factual correctness. For stronger prompt construction, see the system and user prompts lab. A single convincing playground response is evidence only for that run, not proof that the model is reliable across users.
Understand authentication before writing a client
The portal can display connection details and code guidance for the deployed model. An application may authenticate using supported keys or Microsoft Entra credentials. Keys are secrets: store them in approved configuration or secret-management facilities rather than committing them to a repository. Managed credentials and role assignments can avoid embedding static keys where the service supports them.
Do not confuse a project endpoint with a model deployment name or a tool endpoint. An SDK may require a project endpoint to access Foundry services, while a model-inference call identifies the target deployment. Copying the wrong host or using an unauthorized identity leads to an access error even when the deployment is healthy. The Python Foundry client breaks down the request and response responsibilities without assuming every SDK version has identical methods.
Distinguish quota, throughput and request limits
A successful model deployment still has operational constraints. Region and model quotas affect available capacity. Throughput and rate limits affect how many requests can be served during a burst. For a small lab, one user and a few short prompts may be sufficient; a production design needs a more careful capacity assessment. Check the current account and selected deployment rather than copying another person’s quota numbers.
Observe what happens if a request is rejected or delayed. Record the error status and whether retrying would be appropriate. Avoid uncontrolled retry loops that increase charges or exceed limits. Remember that preview deployment methods may have support restrictions; do not treat a preview as a general-production default. The official Foundry deployment options distinguishes supported serverless paths from managed-compute preview features.
Clean up and preserve a learning record
Before ending the lab, record the model card, deployment name, region, configuration choices and three test outcomes. Save only synthetic prompts and nonsecret metadata. Remove resources that are no longer needed and confirm billing or capacity has stopped where applicable. Avoid deleting shared resources owned by someone else just because they appear in your learning project.
AI-901 preparation benefits from a repeatable evidence trail: selected model, successful provisioning, verified endpoint, expected and actual responses, an error scenario and cleanup. That is a more transferable skill than memorizing a particular icon location in the portal. Once direct inference makes sense, the next step is learning why a single-agent solution adds instructions and optional controlled actions around a model.