Two models can both generate text while differing considerably in the work they can do reliably. One may accept images, another may handle very long documents, and another may be fast enough for a real-time conversation but poor at complicated reasoning. Microsoft AI-901 expects candidates to recognize model components and choose models based on capabilities, deployment options and configuration parameters. The appropriate choice begins with the task, not the newest marketing name.
Consider a travel company that needs an email sorter, an illustrated destination guide and a voice information service. A text classifier, an image generator and a speech-enabled conversational model solve different parts of this problem. Choosing one model for everything may increase expense and make evaluation difficult. A model catalog describes potential capabilities; an application test reveals whether those capabilities fit the actual inputs and quality requirements.
Start by specifying input and output modalities
Text-only models can process written instructions and generate written responses. Multimodal models may accept combinations of text and visual or audio information, but supported operations differ by model and deployment. Image-generation models create new visuals; image-understanding models interpret existing visuals. Speech recognition converts spoken audio into text, whereas synthesis creates spoken audio. These distinctions can appear in scenario questions even when the underlying service names are similar.
Write the input and required output before searching a catalog. If the use case needs a shipping label’s tracking number with verified coordinates on a document, general image descriptions may not be enough; a document or visual extraction tool may be a better fit. For the whole landscape, see the AI workload selection. For a visual comparison, the computer-vision lab distinguishes interpretation from creative generation.
Understand token context and output boundaries
A text model receives input represented as tokens and produces a bounded output. Context capacity limits how much conversation, retrieved evidence or other supported information can be considered at once. A model can misstate details even when everything fits within the context window, and adding irrelevant text can make evaluation more difficult. A longer context is a capability, not a guarantee that every sentence in a document will be interpreted correctly.
Select source passages based on relevance and permission rather than indiscriminately copying a complete document library. If the input is a short support message, a modest context capacity may be sufficient. If the task requires comparing several long contracts, different retrieval and reasoning requirements apply. Record truncation behavior and test an example near the expected context limit. For study purposes, distinguish the model’s context window from the output-token limit set by the application.
Know the role of generation parameters
A temperature-style setting, where supported, influences the distribution of possible responses; a lower value can make outputs more predictable but does not guarantee factual accuracy or complete determinism. A maximum output length constrains response size, not truthfulness. Some models support top-p sampling, structured output or other controls; support is not universal and parameters may change between APIs. The foundational skill is understanding what a setting is intended to affect and why it should be evaluated for the workload.
For a customer ID extractor, use a narrow output contract and server-side validation. For creative destination descriptions, variation may be desirable, provided factual claims are grounded in approved data. Do not attempt to solve authorization or sensitive-data issues by changing temperature. Those require ordinary application controls and permission checks outside the model.
Treat a model deployment as a named operational resource
A model entry in a catalog is not necessarily callable by an application until an appropriate deployment or supported instant-access route exists. Microsoft describes model deployments in the Foundry model deployments. A deployment name is the handle used by a client request; the underlying model family, version, processing location, capacity and access settings are separate facts to verify.
Some models offer serverless deployment, different throughput options or dedicated compute. Regional availability, allowed processing locations and quotas vary. Foundry also documents preview features, including instant model access and managed compute, which should not be presented as automatically production-ready in every environment. For an entry-level lab, learn to identify the resource, select a supported model, inspect its card, deploy when needed and observe a successful inference response.
Compare cost with accepted quality
Token price alone does not determine the cost of a business result. A cheap model may need more examples, repeated calls or human correction. A stronger model can cost more per request yet reduce the number of retries. For an email sorter, measure correct category, abstention on ambiguous messages, request latency and accepted-result cost. If two models meet the same required accuracy and security constraints, the simpler or cheaper choice may be preferable.
Performance also depends on concurrent usage and deployment capacity. A model that answers one playground request quickly can still throttle when dozens of users arrive. Check supported quotas and monitor response times and errors. The first-model Foundry lab explains why successful deployment, sufficient quota and an application-ready endpoint are separate release conditions.
Apply a small repeatable test dataset
Create a set of fifteen realistic travel emails: date changes, refund requests, baggage questions, ambiguous requests and a message containing misleading instruction text. Define acceptable labels, including “needs human review.” Run the same dataset against two candidate models and record predictions. Then test an alternate prompt, noting whether the improvement holds across several categories instead of one appealing example. This approach prevents model choice from becoming a matter of personal preference.
Add one edge case with an unsupported language and another that mentions two intentions. A high-confidence wrong label may cause more downstream work than a cautious refusal. Make risk and operational constraints explicit in the comparison. The responsible-AI case studies provide language for fairness and safety criteria alongside raw classification accuracy.
Avoid confusing model, application and agent capabilities
A model has learned inference capabilities. An application assembles data, prompts, authentication and presentation. An agent adds task instructions, state and potentially tool selection. A model may generate a calendar appointment description, but only an authorized calendar integration can actually create the event. Do not infer that a model supports external operations because it can describe them convincingly.
Foundational exam preparation should end with a clear decision rule: define the task and evidence first; choose a model supporting the necessary modality and region; set only supported parameters; expose it through a verified deployment; and evaluate real outcomes. A larger model, more expensive capacity or additional agent framework is justified only when it solves a measured problem that a simpler approach cannot.