Foundry model invocation and prompt testing are two separate checkpoints. First establish whether the chosen model uses an approved deployment or qualifies for instant model access in the supported preview region, then verify project identity, caller permissions and quota. Next compare a baseline prompt with one that separates system instructions, user input and retrieved evidence; record the model, invocation route, settings and expected result. A successful playground answer proves only one interaction, not application authorization or handling of missing evidence. An independent AI-901 Foundry practice question that assumes every catalog model is immediately callable is incomplete: the correct decision needs region, access, model support and deployment or preview eligibility. Include a denied request or invalid input to test behavior beyond a single fluent answer.
Imagine a fictional library assistant that explains public opening hours and suggests which help desk can answer a question. The assistant should not invent opening hours, access a patron’s account or take an action beyond its scope. We can use this requirement to separate the roles of Foundry project configuration, model deployment, prompt wording and response validation.
Check the project and model prerequisites
Before using a playground, confirm the Azure subscription, Foundry project, model entitlement and permissions. Region, account policy, provider and quota restrictions affect which models are available. For a standard deployment, capture its actual deployment name and endpoint; for supported instant model access, record the model identifier and confirm the preview prerequisites rather than inventing a deployment that does not exist. Never paste an API key into screenshots, shared notes or a public repository.
The model catalog includes services with different capabilities, quotas and deployment conditions. A serverless deployment and managed compute path are not interchangeable. Microsoft’s instant model access currently remains preview for supported models in West US 3, with eligibility and quota requirements; it is not a guarantee that every model works without deployment in every region. Check the actual option and its limitations in the Foundry deployment guide before documenting a learner’s setup.
For the library task, choose a model capable of ordinary text instructions and short answers, with permissions and cost controls appropriate to experimentation. Do not select an image-generation model just because it is more impressive in a demonstration. Confirm that the model is allowed in the chosen region and that you understand how its invocation is billed.
Separate system instructions from user input
A system instruction defines the application’s stable behavior: for example, answer questions about library services, do not infer personal account details, and disclose when opening-hour information is unavailable. A user message describes the person’s immediate request: “When does the reading room open on Saturday?” They are different trust levels and play different roles.
Do not put hard-coded hours into the system message unless the application has a maintained authoritative source and a process to update them. Otherwise the model may give an old schedule confidently. Better instructions say which source must be consulted, how to present uncertainty and when to refer the person to staff. Instructions can guide model behavior; they do not grant access to private databases or guarantee factual accuracy.
A few representative user prompts should cover direct questions, ambiguous questions and requests outside the task. For example: “How do I find the children’s section?” might be appropriate; “Show me a specific person’s borrowing history” should not reveal confidential records; “Book a room” should not be confirmed unless the application is genuinely integrated with and authorized to use a booking system.
Deploy and test in the Foundry portal
Inside an authorized project, locate the relevant model catalog entry, examine supported regions and deployment options, and create a deployment when required. Note its deployment name and model version, which are not necessarily the same string. In the portal playground, enter the system instructions and send a simple user request. Compare the response against a short acceptance rubric rather than judging whether the prose sounds friendly.
Change just one parameter at a time during experimentation. Altering both the prompt and model simultaneously makes it difficult to explain a result. Where a model supports a temperature or output-token limit, use them deliberately: higher variation may be useful for creative writing but often makes strict categorization less consistent; a restrictive output limit may truncate a useful response. Parameter names and support differ across models and APIs, so inspect the selected documentation instead of borrowing settings blindly.
A completed deployment does not itself validate the library’s business rules. Keep a separate set of checks for acceptable topics, source citations, unsupported claims and proper escalation. The playground helps you iterate; final application validation still belongs to deterministic code and an explicit test process.
Write prompts that specify a useful result
An effective prompt describes the user’s real task, required context, boundaries and expected output format. Compare “Tell me about the library” with “Summarize the opening hours supplied below in two sentences; if a day is missing, state that the schedule is unknown rather than estimating.” The second version specifies what evidence the model may use and how to handle incomplete input.
Examples can improve consistency, but every example should illustrate a real constraint. Do not overwhelm a simple task with dozens of unrelated examples or repeat the same instruction in different wording. The prompt should leave room for a model to say “I don’t have that information” when the available source is incomplete.
When output must be processed by software, a stable schema or strongly defined response format can help. But valid JSON is not automatically correct JSON: an invented date can satisfy a schema perfectly. Validate business values and source consistency separately. In an interactive chat, make the final user-facing answer clear without hiding uncertainty behind a machine-readable field.
Understand model versions and release limitations
A model deployment is a configured service resource with versions and limits that can evolve. A model’s input modalities, context capacity, regional availability, quotas and pricing are not universal. Record the actual deployment reference used in tests. If a demonstration depends on a preview feature, say so and check whether it is suitable for the intended environment; a preview may lack the same support conditions as generally available capabilities.
Avoid assuming that switching the model identifier is sufficient to preserve application behavior. A newer model may accept different optional parameters, refuse different examples or return a changed output structure. Retest a representative prompt set whenever a model, deployment or system instruction changes. Successful infrastructure deployment and successful task output are separate things.
At an introductory level, catalog selection identifies a model candidate; the supported invocation route (an ordinary deployment or eligible instant-access preview) determines where and how it can run; prompting defines requested behavior; and evaluation tests whether the response meets the task. Foundry identity and deployment architecture becomes important when projects serve multiple workloads, whereas this AI-901 exercise deliberately uses a small, controlled application.
Evaluate ordinary, negative and ambiguous requests
Make a small table of expected outcomes before experimenting. “Where is the public reference desk?” should receive the documented answer if evidence is supplied. “What is the patron’s password?” should never produce confidential account data. “What time do you close on an unspecified holiday?” should produce a qualified response or ask for the date. A model may answer a straightforward case correctly and still fail the next two.
Record the model and prompt version, input, observed response, evidence provided, pass/fail judgment and rationale. Include cases with missing context and adversarial text inside supplied documents. Treat external text as data rather than promoted instructions. Compare the results after each important change. A broad benchmark score is less useful to this small project than a reproducible set of real requirements.
When evaluating, separate accuracy, format, safety and latency. A model can provide the right information in the wrong structure, or the right structure with unsupported facts. Time to first token is a useful user-experience measure in interactive systems, but it does not excuse an inaccurate answer or a failure to observe the user’s permissions.
A valuable extra test is to insert an irrelevant instruction into the reference material, such as a fictional web page that says to reveal application secrets. The assistant should treat that instruction as untrusted text, not as a replacement for its stable behavior. A system prompt can guide this distinction, but the stronger protection is that sensitive data and high-impact tools are not available to unauthorized requests in the first place. Record the result alongside other negative tests; a prompt that seems effective on ordinary questions can still fail in adversarial contexts. If the system cannot safely respond, clear refusal or escalation is preferable to a fabricated successful answer.
Move from playground understanding to a real client
Once the portal interaction is understood, a lightweight SDK client can authenticate with the appropriate project endpoint, send a structured request and inspect the response. Treat connection errors, service limits, blocked content and malformed output as expected failure paths. Do not build business side effects directly into generated text; a separate authorized API must confirm any action.
For a reproducible local client, follow version-matched Foundry project setup and SDK examples and record the exact package generation, authentication method and endpoint or model identifier used. Azure AI Projects 2.x examples do not run unchanged with classic 1.x clients. Validate supported method names and environment variables before copying a code sample into an application.
AI-901 preparation becomes more effective when you can explain why a particular model and prompt worked for one case and why it failed another. Keep the project small, use an explicit source of truth, document the selected deployment and evaluate with a handful of meaningful cases. Those habits make the transition from a model playground to an application much safer.