Implement AI solutions by using Microsoft Foundry
Two kinds of building block, and the input decides which
A support team hands you three requirements in one morning: answer customer questions in the product's own voice, transcribe last night's recorded calls, and pull the same eight values off every invoice that arrives. All three are built in Microsoft Foundry, and no two of them use the same building block. A Foundry resource provides unified access to models, agents, and tools, and the blocks you build with come in two kinds. A model you deploy is a catalog model you publish into your project and then address by the deployment name you gave it, and an agent wraps one of those deployed models with instructions and tools rather than being a third kind. A Foundry Tools service (the product family's name, not an agent's tools) is a ready-made capability you call at its own endpoint with its own client library, and three of them carry this domain: Azure Language in Foundry Tools, Azure Speech in Foundry Tools, and Azure Content Understanding in Foundry Tools. Which block a requirement wants falls out of what goes in and what must come out, read in this order: the same predefined fields off every incoming file is Content Understanding; an image as the input or as the required output is a deployed vision-enabled model, one that accepts an image alongside the text instruction, or a deployed image-generation model; written text to analyze or audio to transcribe, speak, or hold a conversation in is Azure Language, Azure Speech, or a deployed realtime model; whatever is left is open-ended generation, which is a deployed chat model or an agent. Reading in that order heads off this domain's most common wrong answer, reaching for a chat model because generative AI is the interesting part: the same eight values off every invoice is an analyzer, a configuration you write once and reuse for every file, and four thousand archived recordings is batch transcription, however well a chat model could improvise either.
Four pages, one for each pairing of what goes in and what comes out
These four pages carry 55–60% of the exam, against 40–45% for the concepts domain. Implement generative AI apps and agents by using Foundry covers text in and text out: what belongs in a system prompt, the standing instructions sent with every request, as against a user prompt, which carries this turn's input; how a deployment is exercised in the portal playground before any code exists; and how a lightweight client issues the same request against either a deployment name or a stored agent. Implement AI solutions for text and speech by using Foundry covers the two services that handle language and sound, Azure Language for analysis of written text and Azure Speech for transcription and synthesis, plus the deployed realtime model you use when the application has to hold a spoken conversation rather than hand back a transcript. Implement AI solutions with computer vision and image-generation capabilities by using Foundry covers the deployed models that read pictures and the ones that produce them, how an image is supplied to a request, and which request options belong to which direction. Implement AI solutions for information extraction by using Foundry covers Content Understanding and its analyzers, which turn documents, images, audio, and video into clean, machine-readable content plus a fixed set of fields, and which is where a requirement written about every file lands.
Let Foundry hold what stays the same, and let the request carry what changes
When two answers both work, the one the exam rewards is usually the one where durable configuration sits in Foundry and the request carries only this turn's input. That favors a system prompt over an instruction every user has to remember to repeat, one stored agent definition that several applications point at over the same instructions pasted into each of them, a prebuilt analyzer or a copy of one over a schema written from nothing, and a check in the playground before the first line of client code. The same instinct settles the parameter questions, because options do not transfer between build paths: detail belongs to reading an image, quality belongs to generating one, and an option that a custom analyzer's base analyzer, the built-in analyzer it inherits from, does not support will not make that analyzer behave the way its JSON reads.
What each page builds, and which building block it uses
| What the requirement asks you to build | Deployed model or Foundry Tools service | What you set to steer the result | Drill into |
|---|---|---|---|
| Generated prose, a chat experience, or an assistant that calls tools | A deployed chat model, called directly or through an agent definition stored in Foundry Agent Service that names it | The system prompt in the request, or the instructions and tools in the stored agent definition | Implement generative AI apps and agents by using Foundry |
| Written text to analyze, audio to transcribe or speak, or a spoken conversation | Azure Language in Foundry Tools, Azure Speech in Foundry Tools, or a deployed realtime model | The client class and the method you call, one per capability or direction | Implement AI solutions for text and speech by using Foundry |
| An answer about a picture, a picture that does not exist yet, or a change to one that does | A deployed vision-enabled model, or a deployed image-generation model | Request options that belong to one direction only, such as detail for reading and quality for generating | Implement AI solutions with computer vision and image-generation capabilities by using Foundry |
| The same values off every incoming document, image, audio file, or video | Azure Content Understanding in Foundry Tools | A prebuilt or custom analyzer, configured once and reused for every file | Implement AI solutions for information extraction by using Foundry |