Generative AI

Assuming you can already tell generative AI apart from the other four AI-900 workloads, this domain leaves you able to operate at both levels it is tested on: the concept and its Azure realization. It is the one workload defined by producing new, original output from a prompt rather than a fixed prediction. This domain is examined on two levels that map directly to its two subtopics, and learning to tell those levels apart is what this overview equips you to do: first the conceptual mechanics of how generative models work (the generative AI solutions subtopic), and second the catalog of Azure services you would actually use to build with them (the Azure generative AI services subtopic). A question can therefore arrive as either 'what does this technology do?' or 'which Azure service do I pick for this?', and recognizing which level a stem is operating at is the fastest route to the right answer. The whole domain hangs together as a single chain: a prompt is sent to a transformer-based large language model, which predicts tokens to produce a completion, and Azure packages that loop at progressively higher levels of abstraction (raw model API, build platform, finished assistant) plus a safety layer.

The four services in this domain are not alternatives that do the same thing: they sit at different points on a build-to-buy spectrum, and the exam's service questions almost always reduce to identifying which point the scenario describes. The deciding axis is what you do with a model (call, build with, or consume one) not which model. At the lowest level, Azure OpenAI Service exposes OpenAI's GPT, embedding, and DALL-E models through Azure's own secured endpoints, so you pick it when the verb is to call, access, or invoke a specific model with enterprise authentication and compliance. One level up, Azure AI Foundry (formerly Azure AI Studio) is the development platform where you build, compare, evaluate, and deploy a generative AI application using its multi-vendor model catalog and prompt-flow orchestration: choose it when the work is constructing an app, not just hitting one model. At the top, a Microsoft Copilot is a finished assistant already built and embedded into a product (Microsoft 365, GitHub, Security), so it is the answer whenever the scenario wants results with the least development effort or 'without writing code'. The practical 'verb test' (call → Azure OpenAI, build → AI Foundry, consume a finished assistant → Copilot) resolves most service questions here.

Because a large language model generates output from its training data probabilistically, it can produce confident but wrong answers (hallucinations) and has no knowledge of private or recent information. The domain treats two responses to this as core, not optional. Grounding via retrieval augmented generation (RAG), described in generative AI solutions and realized as Azure OpenAI 'on your data' and Microsoft 365 Copilot's grounding through Microsoft Graph in Azure generative AI services, first retrieves relevant organizational data and adds it to the prompt, so the model answers from supplied content rather than guessing. Separately, responsible generative AI is examined as Microsoft's map-measure-mitigate-manage lifecycle and a layered mitigation stack (model, safety system, system message/grounding, user experience), with Azure AI Content Safety supplying the concrete safety-system layer: harm-category scoring, Prompt Shields against jailbreak and injection, and groundedness detection that flags responses not supported by the source. The exam links the concept to the service: when a stem asks how to verify an answer is grounded or block a jailbreak, the answer is a Content Safety feature, not a different model.