AI Models and Deployment Fundamentals for AI-901

The April 2026 AI-901 blueprint changed the emphasis of Azure AI Fundamentals. Candidates are now expected to describe how generative AI models work, choose an appropriate model based on capabilities, and identify deployment options and configuration parameters. That is still fundamentals-level knowledge, but it requires more engineering judgment than simply naming a service.

For the AI-901 exam, model selection should be treated as a requirements problem. What kind of input does the application accept? What kind of output does it need? How much context is required? Does the workload need text, vision, audio, or agentic behavior? How much latency and cost can the system tolerate? The right model is the one whose capabilities and deployment characteristics fit those requirements.

Generative models predict outputs from learned patterns

A generative model is trained on large amounts of data to learn statistical relationships in that data. For a language model, the system generates a response by predicting likely token sequences conditioned on the input and prior context. The model is not looking up a single stored paragraph each time it answers, and it does not “know” facts in the same way a database stores records.

This helps explain both the power and limitation of generative AI. The same learned representation lets a model summarize, rewrite, answer questions, create code, and follow instructions, but it can also produce plausible output that is not grounded in a verified source. That is why application design often adds retrieval, tools, validation, or human review around the model.

AI-901 does not require deep neural-network mathematics. The important point is that generative models produce outputs probabilistically from learned patterns, so model behavior is influenced by training, context, instructions, configuration, and the application around the model.

Capabilities should drive model selection

Start with the modality. A text-only model cannot directly solve a requirement that depends on interpreting an image. A multimodal model may be appropriate when the application must reason about text and visual input together. An image-generation model serves a different purpose from a model designed primarily for language understanding or chat.

Then consider the task. Some models are optimized for fast everyday interactions, others for stronger reasoning, code, longer context, or specific media. A larger or more capable model can improve quality on difficult tasks but may cost more or respond more slowly. A smaller model may be a better engineering choice when the task is narrow, latency sensitive, or high volume.

The exam can present a scenario where several models could technically produce an answer. The correct choice should match the requirement rather than defaulting to the most powerful model available.

Context, latency, cost, and quality are connected trade-offs

Model choice affects more than raw answer quality. A larger context window can allow the application to supply more documents, conversation history, or instructions, but sending more tokens can increase latency and cost. A highly capable model may reduce the need for elaborate prompting, while a smaller model may be sufficient if the application narrows the task and provides high-quality context.

Latency matters for interactive applications. A conversational assistant used by customers may need a response quickly enough to feel natural, while an offline summarization job can tolerate more processing time. Cost matters at scale: a small difference per request can become significant across millions of calls.

These trade-offs are not separate exam facts. They are the decision criteria behind “identify an appropriate model based on capabilities.” Good preparation means being able to explain why one model fits the use case better than another.

Deployment turns a model capability into an application endpoint

A model must be made available through a deployment before an application can use it in a practical solution. In Microsoft Foundry, deployment creates the managed endpoint and configuration the application interacts with. The exact options depend on the model and environment, but the fundamentals are stable: choose the model, choose an appropriate deployment approach, configure the deployment, and then call it through the supported portal, SDK, API, or client application.

Deployment choices can affect capacity, performance, region, availability, and cost. A development environment may use a simple deployment for experimentation, while a production application may need stronger capacity planning, rate limits, or operational controls.

It also helps to separate the model identity from the deployment identity. An application can be designed around a particular capability while the deployed resource supplies the endpoint, capacity, access boundary, and runtime settings used to reach it. That distinction explains why a team can test a model successfully and still encounter production problems caused by quota, throughput, regional availability, or deployment configuration. For AI-901, the useful mental model is straightforward: the model defines what kind of intelligence is available; the deployment defines how that intelligence is exposed to the application. Questions that mention capacity, endpoint access, availability, or runtime configuration are therefore asking about the deployment layer rather than the underlying model alone.

AI-901 candidates do not need to design a global production architecture from scratch. They should understand that selecting the model is only one step. The deployment determines how the chosen model becomes an accessible resource.

Configuration parameters influence generation without changing the model

Applications can adjust model behavior through configuration parameters. Depending on the model and API, parameters can influence randomness, output length, or other aspects of generation. These settings do not retrain the model; they change how the model produces a response for a request.

A creative brainstorming task can tolerate more variation than a structured extraction task. A system expected to return a concise response may use a tighter output limit. A deterministic business workflow generally benefits from more controlled generation than an open-ended creative application.

Do not confuse deployment configuration with prompt instructions. The prompt tells the model what task to perform and provides context. Generation parameters influence how the response is sampled or constrained. Both affect output, but they are different control surfaces.

Prompts and system instructions remain part of the application design

The current AI-901 blueprint also includes creating effective system and user prompts for generative AI models. System instructions establish durable behavior or role constraints for the application, while user prompts express the current request. The distinction matters because a strong deployment can still perform poorly if the application sends vague or conflicting instructions.

Model selection and prompt design should be considered together. If a model supports the required capability, better instructions and context may solve a quality problem without moving to a more expensive model. If the model lacks the required modality or context capacity, prompt engineering cannot create a capability that is not there.

This is a useful exam decision rule: first confirm the model can do the job, then decide how the application should instruct and configure it.

Agentic workloads add tools and state around the model

An agent is not a fundamentally different kind of language model; it is an application pattern in which a model can reason about actions, call tools, and continue through a task. Model selection still matters because the model needs enough capability to follow the orchestration, use tools correctly, and handle the expected context.

The broader AI agents fundamentals are useful when a scenario introduces tools, memory, planning, or feedback loops. For AI-901, keep the distinction clear: the model provides generative capability, while the agent application adds orchestration around it.

A simple question-answering app may need only a deployed model and client. A support agent that looks up customer information and performs actions needs additional tool and permission design. The workload should determine the architecture.

Responsible AI still applies to model and deployment choices

Choosing a model solely for benchmark quality can ignore important risks. A model may perform differently across user groups, handle sensitive data, generate unsafe content, or be difficult to explain in a high-impact workflow. Deployment configuration can also expose too much capacity or access if controls are not designed appropriately.

The AI-901 responsible-AI scenarios help connect these principles with the workload. At fundamentals level, ask whether the design is fair, reliable, secure, inclusive, transparent, and accountable before treating performance as the only criterion.

Practice model-selection questions as trade-off tables

Take a short workload description and write four columns: required modalities, quality or reasoning needs, operational constraints, and risk considerations. Then decide what kind of model and deployment would fit. Repeat with a vision assistant, a low-latency FAQ bot, an image-generation tool, and an agent that calls business systems.

The goal is not to memorize every model name in the current catalog, which can change. It is to develop the reasoning behind model choice. Microsoft’s current AI-901 objectives emphasize capabilities, deployment options, and configurations precisely because those concepts survive catalog changes.

If you can explain why a workload needs a particular modality, why a smaller model may be preferable under latency or cost constraints, how deployment makes the model available to an application, and how parameters influence generation, you have the model-and-deployment objective at the right depth for Microsoft Azure AI Fundamentals.

Model availability can also vary by region, deployment type, or service capacity, so a design must separate “the model has the capability” from “this environment can deploy it in the required way.” At fundamentals level, you do not need to memorize every regional matrix. You do need to recognize availability, quota, and capacity as deployment considerations rather than model-quality characteristics. A suitable model that cannot be deployed where the application must run is not yet a workable solution.