Prompting is the interface between an application and a generative model, while model parameters shape how that model produces a response. AI-901 expects candidates to create effective system and user prompts and to recognize appropriate model configurations.
The goal is not to memorize every possible parameter. It is to understand how instructions, context, examples, randomness, output limits, and validation affect behavior—and when an application should constrain the model instead of hoping a vague prompt produces a reliable result.
Separate durable instructions from the current request
System instructions define the role, boundaries, style, and persistent behavior the application wants. User instructions carry the immediate task. Keeping them separate makes the interaction easier to maintain and reduces accidental conflicts.
For example, a support assistant might have a system instruction to answer only from approved product material and a user message asking about a specific error. The system policy should remain stable while the user request changes from turn to turn.
Write instructions that define the output, not just the topic
‘Explain networking’ is broad. ‘Explain the difference between public and private endpoints in three short paragraphs for a junior cloud administrator’ defines audience, scope, and form. Clear output requirements reduce variability and make the result easier to evaluate.
Good prompts specify what success looks like. If the application needs a list of actions, named fields, or a concise decision, say so. Avoid forcing downstream code to infer structure from an unnecessarily open-ended answer.
Provide relevant context and remove distracting context
Grounding information should be directly useful to the current request. Large, unfocused context can increase cost and make it harder for the model to identify which evidence matters.
Retrieval systems work best when they supply a focused set of relevant passages rather than an entire knowledge base. Prompt quality and retrieval quality are connected: the model can only reason over the evidence it receives.
Use examples when the desired pattern is hard to describe
Few-shot examples can demonstrate a classification label, writing format, transformation, or edge-case behavior. They are especially useful when a rule is easier to show than to explain.
Examples should represent the real range of inputs. If every example is simple and positive, the prompt may still fail on ambiguous or negative cases. Treat prompt examples as part of the application’s testable specification.
Control randomness according to the task
Some model parameters influence how deterministic or varied a response is. Low-randomness settings are often better for extraction, structured transformation, or repeatable business workflows. More creative settings may be appropriate for ideation or open-ended drafting.
The key exam concept is alignment with the workload. A compliance summary should not be optimized for novelty, while a brainstorming assistant may benefit from more diversity. Parameters should serve the task rather than use the same defaults everywhere.
Set output limits deliberately
Output limits help control latency, cost, and response shape. If a task requires a concise answer, allowing extremely long output is unnecessary. If the answer can be complex, an overly small limit can truncate useful content.
Applications should also design for what happens when the result is cut off or incomplete. A token limit is an operational control, not a guarantee that the model will finish every thought cleanly.
Prefer structured output when software consumes the answer
Human-readable prose is flexible, but software often needs predictable fields. Asking for structured output and validating it can make model responses safer to integrate into workflows.
Validation remains necessary because model output can still be missing fields or contain unexpected values. A schema is strongest when the application checks it rather than assuming the prompt alone guarantees compliance.
Treat user content as untrusted input
A prompt can include instructions from users, retrieved documents, web pages, or tool output. Those sources may contain text that conflicts with system policy or attempts to redirect the model. Applications should preserve instruction hierarchy and avoid blindly promoting untrusted text into high-priority instructions.
This is the core of prompt-injection defense. The model must distinguish trusted application policy from data it is supposed to analyze. Sensitive tool permissions should not depend only on whether a generated sentence sounds confident.
Ground high-stakes answers and preserve evidence
For factual or controlled workloads, prompts should encourage the model to use supplied evidence and avoid inventing unsupported details. The application may also preserve citations, source references, or retrieved passages for verification.
Grounding does not eliminate error, but it narrows the model’s information space and makes review possible. This is especially valuable for policy, financial, medical, legal, and operational content where unsupported generation can create real consequences.
Evaluate prompts as versioned application assets
Prompt changes can alter outputs as significantly as code changes. Teams should version important prompts, run regression tests, and compare quality before deployment. A prompt that works on five hand-picked examples is not necessarily robust.
Evaluation should include edge cases, adversarial inputs, long inputs, and failure conditions. Measure whether the output is useful and safe, not merely whether it sounds polished.
Model parameters do not fix a bad task definition
Changing temperature, output length, or another parameter cannot rescue a prompt that does not define the goal. Likewise, an excellent prompt cannot compensate for missing evidence or the wrong model capability.
Treat prompting, model choice, retrieval, and validation as a system. AI-901’s fundamentals scope is broad because practical AI quality depends on how these pieces work together.
Exam focus: choose instructions and settings that match the workload
If the scenario needs repeatable structured extraction, use clear instructions, constrained output, and lower variability. If the goal is creative ideation, allow more diversity. If the model needs private facts, provide grounded context. If untrusted content is involved, preserve instruction boundaries.
Microsoft AI certifications emphasize vendor-specific tooling, while AI and generative AI certifications span several ecosystems. For AI-901, prompt structure and parameters are foundational because they shape reproducibility, response length and how the model responds to uncertainty.
Use delimiters and clear context boundaries
When a prompt includes retrieved passages, user-provided text, or long documents, delimiters can make it clearer which text is instruction and which text is data. This improves readability for developers and can reduce accidental ambiguity in the model’s interpretation.
Boundaries are especially important when the included content may contain its own instructions. The application should make clear that retrieved content is evidence to analyze, not a new system policy.
Avoid overloading one prompt with too many goals
A prompt that asks for classification, extraction, explanation, policy checking, and creative rewriting in one step can be difficult to evaluate. Breaking complex work into stages often produces clearer outputs and better observability.
Multi-step design also makes retries cheaper. If only one stage fails, the application can repeat that stage instead of rerunning the entire workflow.
Use deterministic business rules outside the model
Not every decision belongs in a prompt. Exact arithmetic, authorization checks, identifier validation, routing based on fixed thresholds, and other deterministic logic are often safer in ordinary code.
The model should handle ambiguity and language where it adds value. Keeping fixed policy in code reduces prompt complexity and prevents model variability from changing rules that should be consistent.
Watch for prompt drift as applications evolve
Prompts often accumulate exceptions as teams patch individual failures. Over time they can become long, contradictory, and difficult to reason about. Periodic refactoring helps keep the highest-priority instructions clear.
Regression tests are essential during that cleanup. A shorter prompt is only better if it preserves the behaviors users actually need and does not reintroduce known failure cases.
Parameter changes should be evaluated with the prompt
A prompt that performs well at one randomness or output setting may behave differently when parameters change. Teams should evaluate prompt and parameter combinations together rather than assuming each can be optimized independently.
This matters when cost or latency tuning changes output limits or model choice. The application should preserve quality targets while adjusting operational settings.
Prompt for uncertainty when the model should not guess
Some workloads benefit from instructions that allow the model to say that the supplied evidence is insufficient. If the prompt implicitly demands an answer no matter what, the model may fill gaps with plausible but unsupported content. A controlled application should make abstention acceptable when facts are missing.
That behavior can be combined with retrieval or escalation. If the model cannot answer from the approved context, the application can request more information, search another source, or route the case to a person rather than inventing a confident response.
Keep sensitive values out of prompts when they are unnecessary
Prompts sometimes include entire records even though the task needs only a few fields. Minimizing the data sent to the model reduces privacy exposure, prompt length, and the chance that irrelevant details influence the answer.
Application code should select the context required for the task. This is another reason prompting is a system-design topic rather than just a writing skill: what the model sees is determined by retrieval, data access, and software logic.
Use a prompt review checklist before release
Before promoting a prompt, confirm that trusted instructions are separated from user data, required context is present, sensitive data is minimized, output expectations are explicit, and failure or abstention behavior is defined. Then run representative regression tests with the intended model and parameters. A short review checklist catches many avoidable problems before they reach users.
Prompt engineering becomes much more reliable when it is treated like configuration engineering: versioned, reviewed, tested, and monitored after release.