Domain 2 · Implement generative AI and agentic solutions
This is the largest domain on the exam and the one that most rewards depth. It moves through three stages that mirror how these systems are actually built: first a generative application that answers from grounded context, then an agent that can act rather than only respond, and finally the tuning and observability that keep either of them trustworthy in production. Budget your study time accordingly — generative apps, agents, and operationalization all need to be solid.
Build generative applications with Foundry
The starting point is deploying and consuming models from a Foundry project — LLMs, small models, code models, and multimodal models — through a consistent surface, so that swapping a model is a configuration change rather than a rewrite.
Most production applications then add retrieval-augmented generation (RAG): retrieve grounding context, typically through Azure AI Search's vector, hybrid, or semantic modes, and inject it into the prompt so the model answers from your data instead of from its training distribution alone. RAG is the single most heavily examined pattern in this domain, and the retrieval half is where most real failures originate.
From there, applications grow tool-augmented flows and multistep reasoning pipelines, where the model calls out to functions and services and composes several steps into one answer. Because that composition can fail quietly, evaluation is treated as a first-class activity: detecting fabrications and hallucinations, and scoring relevance, quality, and safety. Integration throughout is via the Foundry SDKs and connectors, with the application connected to a Foundry project.
Build agents with Foundry
An agent is a generative application that has been given goals and the means to pursue them. Defining one means specifying its role and goals, how conversation is tracked across turns, and the tool schemas that describe what it may call — the schema is what the model reasons over, so a vague schema produces a confused agent.
Capability comes from integrating retrieval, function-calling, and conversation memory, and then from the tools themselves: APIs, knowledge stores, search, content understanding, and custom functions.
Beyond a single agent, the exam covers orchestrated multi-agent solutions and autonomous/semiautonomous workflows. The pairing to remember is autonomy with safeguards and approval flows — the more independently an agent acts, the more the design questions turn on where a human approves before an action commits. Closing the loop, agents need monitoring, behavioural evaluation, and error analysis, because an agent that degrades usually does so by choosing the wrong tool rather than by producing obviously bad text.
Optimize and operationalize
Optimization has two levers that are often confused. Prompt engineering changes what you ask; model parameters — temperature, top-p, max tokens — change how the model samples its answer. A scenario complaining about inconsistent or overly creative output is usually pointing at temperature, not at the prompt.
More sophisticated quality techniques include reflection, chain-of-thought evaluations, and self-critique loops, where the system reviews its own output before returning it.
Observability here means more than uptime: tracing, token analytics, safety signals, and latency breakdowns together explain both what an answer cost and why it took as long as it did. Finally, orchestration covers combining multiple models, flows, or hybrid LLM-plus-rules-engine designs — routing a request to the cheapest component that can handle it correctly.
Quiz · Domain 2
You are designing an agent in Microsoft Foundry Agent Service. According to Microsoft, every agent combines exactly three core components. Which set correctly lists them?