For Python developers building AI applications and agents on Microsoft Foundry. Passing AI-103 shows you can plan and secure an Azure AI solution end to end, build retrieval-augmented and agentic applications, implement vision and language workloads, and instrument them with evaluation, observability, and responsible AI controls.
The Azure AI Apps and Agents Developer Associate (AI-103) certification is Microsoft's successor to the long-running AI-102 Azure AI Engineer Associate exam, which retired on June 30, 2026. Where AI-102 grew up in the era of standalone Cognitive Services, AI-103 was designed from the ground up for the generative and agentic era: it is Python-focused and centered on Microsoft Foundry (the evolution of Azure AI Foundry / Azure AI Studio) as the unified platform for building, deploying, governing, and observing AI applications and agents.
In detail, the exam covers agentic applications with tools, memory, and multi-agent orchestration; computer vision, text analysis, and information extraction workloads; and evaluation, observability, and responsible AI instrumentation. The exam skills document this guide follows is dated April 16, 2026.
This guide teaches every topic in the official skills outline, organized into the five measured skills areas with their exact weights. Work through it in order — the two heavyweight domains (planning/management and generative/agentic implementation) together account for roughly 60% of your score.
| Exam Facts | Details |
|---|---|
| Exam code | AI-103 |
| Certification | Microsoft Certified: Azure AI Apps and Agents Developer Associate |
| Questions | 40–60 (typically ~50) |
| Duration | 120 minutes |
| Passing score | 700/1000 (~70%) |
| Question formats | Multiple choice, multiple select, drag-and-drop, case studies, interactive components |
| Language | English |
| Delivery | Pearson VUE (online proctored or test center) |
| Retake policy | 24-hour wait after first failed attempt |
| Predecessor | AI-102 (retired June 30, 2026) |
| Primary tooling | Python, Microsoft Foundry (portal + SDK), Azure AI services |
Microsoft renamed and reorganized its AI platform several times — Azure Cognitive Services became Azure AI services, Azure AI Studio became Azure AI Foundry, and the platform is now branded Microsoft Foundry. Exam questions use the current Foundry naming, but you should recognize legacy names when they appear in scenario stems or older documentation.
Work through the Parts in blueprint order — Part 1's platform, deployment, and governance vocabulary is assumed by everything after it, and Parts 1–2 together are roughly 60% of your score, so be fastest and surest there. Then spend real time in a Foundry project: deploying a model, wiring a tool into an agent, and reading a trace teach you more than an hour of rereading.
Throughout the guide you'll see four kinds of callouts:
Tactical advice about how a topic is tested — question patterns, common traps, and wording to watch for.
The one thing you must remember from a section, even if you forget everything else.
A fact or distinction that candidates frequently mix up.
Useful context or clarification that rounds out your understanding.
Aim to answer this question at the end of every section: "If the exam described this scenario, could I name the right model, service, SDK call, or portal action?" AI-103 is scenario-driven at heart — a workload on one side, the correct Foundry capability on the other.
This is the architect-and-operator domain. It tests whether you can choose the right models and services, design the surrounding Azure infrastructure, deploy and scale responsibly, and wrap the whole solution in security, monitoring, responsible AI, and agent governance.
Model selection is a trade-off across capability, latency, cost, context window, modality, and deployment constraints:
The Foundry model catalog is where you compare models: it lists provider, modalities, context length, regions, deployment types, and benchmark results, and it supports side-by-side model comparison and leaderboards.
When a question contrasts "use a prebuilt service" versus "prompt an LLM," look for signals like guaranteed output schema, regulatory consistency, per-call pricing, no prompt engineering skill available — these point to Foundry Tools (prebuilt services). Signals like open-ended reasoning, flexible output, novel task point to an LLM.
Know which platform component solves which problem:
At the planning level you must be able to pick an indexing/retrieval approach:
Plan for the three pillars every production agent needs:
A reference architecture for an enterprise Foundry solution includes: a Foundry hub + project; model deployments; an Azure AI Search index; Azure Storage for source content; Azure Cosmos DB or similar for conversation/memory state; Azure Key Vault for secrets; Application Insights / Azure Monitor for telemetry; and a delivery tier (Azure App Service, Container Apps, Functions, or AKS) hosting your Python application. Network isolation is achieved with virtual networks, private endpoints, and disabled public network access; identity flows through Microsoft Entra ID.
Plan region selection around model availability (not every model is in every region), data residency requirements, and quota availability.
| Deployment type | What it is | When to choose it |
|---|---|---|
| Standard (pay-as-you-go) | Serverless, per-token billing on shared capacity, per-region | Development, spiky or low volume, fastest start |
| Global Standard / Global deployments | Serverless with routing across Microsoft's global fleet | Higher default quota and availability; data-at-rest still in your resource's geography |
| Provisioned Throughput (PTU) | Reserved capacity purchased in throughput units | Predictable high volume, strict latency SLOs, cost predictability |
| Batch | Asynchronous processing at discounted rates (24-hour window) | Large offline jobs: evaluation runs, bulk summarization, enrichment |
| Managed compute | Model runs on dedicated VMs you select | Open-weight models needing custom containers or full isolation |
Agents deploy through the Foundry Agent Service — you version agent definitions (instructions, model, tools) in the project and expose them via the service API rather than shipping the loop yourself. Apps consuming agents connect with the project endpoint plus Entra ID credentials.
Serverless/Standard deployments bill per token and can throttle under burst; PTU buys reserved throughput for predictable latency and cost; Batch trades latency for a steep discount. Matching workload shape to deployment type is one of the most frequently tested planning skills.
Treat prompts, agent definitions, evaluation datasets, and infrastructure as code:
Retry-After header.max_tokens, cache repeated context (prompt caching discounts repeated prefixes), use Batch for offline work, and set Azure Cost Management budgets and alerts. Token usage per call is reported in the response usage object — log it.Quota is TPM per subscription + region + model, split across deployments. A 429 response means throttling, not failure — the correct client behavior is exponential backoff with jitter and honoring Retry-After, and the correct architectural fixes are more TPM, another region, PTU, or a router across deployments.
DefaultAzureCredential from azure-identity resolves developer credentials locally and managed identity in Azure. Prefer it everywhere; disable key-based auth on resources where possible.publicNetworkAccess = Disabled for strict isolation. Hubs propagate managed VNet settings to projects.from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
project = AIProjectClient(
endpoint="https://<resource>.services.ai.azure.com/api/projects/<project>",
credential=DefaultAzureCredential(), # keyless: managed identity in Azure
)
"No keys stored anywhere, works locally and in Azure without code changes" is the signature of DefaultAzureCredential + managed identity. If a question offers connection strings, keys in Key Vault, or managed identity — managed identity with RBAC is almost always the best-practice answer.
Azure AI Content Safety underpins platform guardrails:
Guardrails should be layered: platform filters + system-message rules + tool-access restrictions + output validation in code.
Foundry ships an evaluation framework you are expected to know:
Evaluations run in the portal or via the Python evaluation SDK, on datasets or on live traffic samples, and results are logged to the project for comparison across runs. Instrument these into CI/CD and production monitoring, not just pre-launch.
Governance is the newest planning skill and heavily emphasized:
For governance scenarios, map risk to oversight: irreversible/high-impact actions → human approval required (human-in-the-loop); monitored autonomy for medium risk (human-on-the-loop); full autonomy only for low-risk, reversible, rate-limited actions. Answers granting an agent broad standing permissions "for convenience" are wrong.
The largest domain. It tests hands-on implementation: consuming models from Python, building RAG, designing and orchestrating agents, evaluating and observing them, and tuning generation.
Deploy from the model catalog to an endpoint, then consume via SDK. The unified Foundry Models API gives one chat-completions surface across model families:
from azure.ai.inference import ChatCompletionsClient
from azure.ai.inference.models import SystemMessage, UserMessage
client = ChatCompletionsClient(endpoint=endpoint, credential=credential)
response = client.complete(
model="gpt-4o", # deployment name
messages=[
SystemMessage("You are a concise support assistant."),
UserMessage("Summarize this ticket: ..."),
],
temperature=0.3,
max_tokens=400,
)
print(response.choices[0].message.content)
The OpenAI Python SDK pointed at your Azure endpoint is equally valid and commonly shown in questions. Multimodal input is sent as message content parts (text + image URL/base64); embeddings use an embeddings deployment and return vectors for indexing. Streaming (stream=True) delivers tokens incrementally for responsive UX.
Retrieval-Augmented Generation grounds the model in your data instead of relying on parametric knowledge:
Key quality levers: chunk size/overlap, embedding model choice, hybrid + semantic ranking, top-k and score thresholds, query rewriting, and citation enforcement. The "on your data" pattern wires an AI Search index directly into chat completions as a data source; agents get the same via a search/knowledge tool.
RAG reduces fabrications because the model answers from retrieved evidence — but only if retrieval is good. If answers are wrong, debug retrieval first (are the right chunks coming back?) before touching the prompt or model.
Beyond single calls, applications compose:
Choose deterministic workflows when the path is known; choose agentic tool loops when the path depends on intermediate results.
Evaluation is tested in depth. The core built-in evaluators:
| Evaluator | What it measures | Typical use |
|---|---|---|
| Groundedness | Is the response supported by the provided context? (fabrication detection) | RAG and agent answers |
| Relevance | Does the response address the user's query? | All chat apps |
| Coherence / Fluency | Logical flow and language quality | Generation quality baselines |
| Similarity / F1 / BLEU-family | Match against ground-truth answers | Regression testing with labeled data |
| Retrieval | Are the retrieved chunks the right ones? | Debugging the R in RAG |
| Content safety set | Hate/unfairness, sexual, violence, self-harm severity | Pre-release and continuous safety |
| Indirect attack (XPIA) | Susceptibility to injected instructions in grounding data | Agent/RAG risk assessment |
| Agent set: intent resolution, tool call accuracy, task adherence | Did the agent understand, call the right tools correctly, and follow through? | Agent quality gates |
Most quality evaluators are LLM-as-judge: a strong model scores outputs against a rubric (typically 1–5). Run evaluations on curated datasets (or AI-generated adversarial datasets via the simulator), compare runs across prompt/model variants, and schedule continuous evaluation on production samples.
Map the symptom to the evaluator: "the bot invents facts" → groundedness; "answers are off-topic" → relevance; "the agent calls the wrong API or bad arguments" → tool call accuracy; "it abandons the user's goal" → task adherence; "could injected document text hijack it?" → indirect attack (XPIA).
The Foundry SDK (azure-ai-projects) is the Python entry point. AIProjectClient connects your app to a project via its endpoint and exposes:
Connections are the "connector" mechanism: an admin wires AI Search or a knowledge store into the project once; app code asks the project for the connection instead of embedding endpoints/keys.
Creating an agent in the Agent Service means specifying:
Tool schemas describe functions in JSON Schema — name, description, parameters with types — so the model can emit valid calls. Clear descriptions are prompt engineering for tools: the model chooses tools based on them.
agent = project.agents.create_agent(
model="gpt-4o",
name="support-agent",
instructions="You resolve billing questions. Use tools; never guess amounts.",
tools=[{
"type": "function",
"function": {
"name": "get_invoice",
"description": "Fetch an invoice by ID for the authenticated customer.",
"parameters": {
"type": "object",
"properties": {"invoice_id": {"type": "string"}},
"required": ["invoice_id"],
},
},
}],
)
requires_action, your code executes the requested function(s) and submits outputs, and the run resumes. With the SDK's automatic function-calling helpers, a toolset of Python functions is invoked for you.A run that pauses with requires_action is not an error — it is the function-calling handshake. The agent is waiting for your code to execute the requested tool call(s) and submit the outputs so the run can resume.
Four integration routes to know cold:
Knowledge stores (AI Search indexes, vector stores) attach as knowledge/search tools so retrieval happens inside the agent loop.
When one agent's instruction set gets overloaded, split responsibilities:
Match pattern to scenario — fixed pipeline → sequential; independent subtasks needing speed → concurrent; iterative collaboration/debate → group chat; "transfer the customer to billing" → handoff; central coordinator delegating to specialists → connected agents (agent-as-tool).
For long-running or autonomous agents, implement:
Use run and trace data to debug agents: inspect run steps (each model call and tool call with inputs/outputs), identify failure classes — wrong tool chosen, malformed arguments, tool runtime errors, hallucinated parameters, task drift — and fix at the right layer (tool descriptions, instructions, schema strictness, or retries). Aggregate error analysis across runs reveals systematic issues (e.g., one tool causes 80% of failures). The agent evaluators (tool call accuracy, intent resolution, task adherence) quantify improvements between versions.
Prompt engineering techniques: clear system-role definition, explicit output format (or structured outputs / JSON schema mode for guaranteed shape), few-shot examples, delimiters between instructions and data, chain-of-thought instructions ("think step by step"), and grounding rules ("answer only from context; say 'I don't know' otherwise").
| Parameter | Effect | Guidance |
|---|---|---|
temperature | Randomness of sampling (0–2) | Low (0–0.3) for factual/extractive; higher (0.7+) for creative |
top_p | Nucleus sampling probability mass | Alternative to temperature — tune one, not both |
max_tokens | Cap on output length | Cost/latency control; too low truncates answers |
frequency_penalty | Penalizes repeated tokens | Reduces repetition/loops |
presence_penalty | Penalizes tokens already present | Encourages new topics |
stop | Stop sequences | Hard output boundaries |
seed | Best-effort reproducibility | Evaluation and testing runs |
Quality-improvement loops the exam names explicitly:
These trade extra tokens/latency for quality — apply selectively on high-stakes outputs.
Instrument with OpenTelemetry: the Foundry SDKs emit spans for model calls, tool executions, and agent runs; export to Application Insights connected to the project. Dashboards should track:
Set alerts on error-rate spikes, 429 rates, safety-event spikes, and latency SLO breaches.
"Never let the model decide X" scenarios (loan approval limits, medical dosage, compliance thresholds) call for a hybrid design where deterministic rules enforce the constraint and the LLM only drafts, explains, or extracts.
This domain covers generative visual media, multimodal analysis, Content Understanding for visuals, and visual safety — a significant reshaping of the old AI-102 vision domain.
Image generation models in Foundry (DALL·E-class and successors such as GPT-image models) turn prompts into images. Implementation knobs: size (e.g., 1024×1024, portrait/landscape variants), quality tiers, number of images, and output format (URL or base64). Prompt craft matters: subject + style + composition + lighting details produce controllable results. Generated images pass through content filtering on both the prompt and the output image, and Azure attaches C2PA content credentials for provenance.
result = client.images.generate(
model="gpt-image-1",
prompt="Isometric illustration of a data center, soft teal palette",
size="1024x1024",
n=1,
)
Video generation (Sora-class models in Foundry) creates short clips from text prompts. You control duration, resolution/aspect ratio, and prompt-described motion and camera behavior. Generation is asynchronous — submit a job, poll for completion, download the result. Expect stricter content policies, higher cost, and region-limited availability compared with image generation; design UX around multi-second-to-minutes latency.
Edits go through the same safety filtering as generation; source image + mask must align in dimensions.
Inpainting edits only what the mask marks as editable and preserves everything else; variations and prompt-driven edits can change the whole image. "Replace just the background, keep the product identical" → mask-based inpainting, not a variation.
Prompt-driven video workflows include regenerating segments with adjusted prompts, extending or remixing clips, and stitching generated segments in an editing pipeline. Practical guidance: keep per-clip prompts consistent (style tokens) for continuity, treat generation as a job queue with human review before publishing, and apply visual policy checks (below) to every output frame set.
Controls that shape output across image/video generation: prompt (positive description), size/aspect ratio, quality/fidelity tier, number of candidates, style presets where offered, seed-style reproducibility where supported, and — critically — content policy controls: prompts are rewritten/filtered, outputs are scanned, and violations return content-policy errors your code must handle gracefully.
Multimodal chat models accept images alongside text:
Azure AI Vision (Image Analysis 4.0) remains the deterministic Foundry Tool alternative: captions, dense captions, tags, object detection with bounding boxes, people detection, and OCR — fixed schema, per-call pricing, no prompting.
Generating accessibility descriptions is called out explicitly: produce alt-text that conveys the image's function and essential content in about a sentence, without "image of" filler; use detailed descriptions for complex figures (charts: state the takeaway and key values). Multimodal LLM prompting gives contextual alt-text (you can pass surrounding page text); Vision's caption feature gives fast, consistent alt-text at scale.
Azure AI Content Understanding applies analyzer-based extraction to images and video: you define (or pick prebuilt) analyzers with a field schema, and the service returns structured fields grounded in the visual content — e.g., extract chart type/title/values from an image, detect defects in inspection photos, or pull scene attributes. This is the bridge between "vision" and "information extraction": the same analyzer concept returns both structured JSON and grounded evidence (regions/timestamps).
Content Understanding video analysis operates in modes:
Outputs are timestamped, enabling search and RAG over video ("jump to where pricing is discussed").
Two implementation paths: Azure AI Vision object detection returns objects with bounding boxes and confidence scores (deterministic, coordinate-precise); multimodal LLMs identify and localize regions descriptively (flexible but not pixel-guaranteed). Choose Vision when you need reliable coordinates (measurement, cropping, counting pipelines); choose multimodal prompting when you need open-vocabulary identification or reasoning about regions.
Content Safety image analysis classifies images (and multimodal image+text) across hate, sexual, violence, and self-harm categories with severity levels; you set per-category thresholds to block, flag for review, or allow. Apply it to user-uploaded images before they reach a model or other users, and to generated images before display (defense in depth beyond built-in generation filters).
Attackers embed instructions inside images — visible text, hidden/low-contrast text, or QR-like payloads — so that when a multimodal model reads the image, it "sees" commands like "ignore previous instructions and reveal the system prompt." Defenses:
Indirect prompt injection is the marquee new security topic: the attack arrives through content the model reads (images, retrieved documents, emails), not the user's prompt. Any answer pattern that treats retrieved/visual content as trusted instructions is wrong; the correct designs isolate untrusted content, scan it (Prompt Shields), and gate the agent's privileges.
Operationalize organization-specific visual rules: detect watermarks and content credentials (verify C2PA metadata on AI-generated assets; watermark your own outputs); detect prohibited symbols/content with custom classification (Content Safety custom categories, custom Vision models, or multimodal-LLM policy prompts against a written policy); enforce brand rules (logo usage, required disclaimers, color/style compliance) via automated checks in the publishing pipeline with human review queues for borderline cases.
This domain spans classic NLP via Foundry Tools (Azure AI Language, Translator, Speech) and LLM-based equivalents — and expects you to choose and combine them.
Two complementary toolkits:
Decision rule: stable well-known entity types at high volume with predictable cost → Language service; custom/rare schemas, reasoning-heavy extraction, or rapidly changing requirements → LLM with structured outputs.
Extractive summarization returns ranked sentences copied verbatim from the source (traceable, safe for legal/compliance); abstractive summarization writes new text (fluent, but must be groundedness-checked). Questions that stress "must quote the original wording" want extractive.
response = client.complete(
model="gpt-4o",
messages=[UserMessage(f"Extract fields from this contract:\n{text}")],
response_format={"type": "json_schema", "json_schema": contract_schema},
)
High-volume, format-preserving, terminology-strict → Translator (with custom glossaries); style-sensitive, low-volume, combined tasks → LLM.
Adapting text analysis to a domain, three escalating approaches: (1) prompt engineering — role, domain glossary, output template, few-shot examples of compliant summaries (e.g., "summarize this audit finding citing the regulation section, flag unresolved risks"); (2) grounding/RAG — retrieve regulation text or policy so summaries cite the actual clauses; (3) fine-tuning — when a large corpus of gold-standard domain outputs exists and prompt approaches plateau. Compliance summarization scenarios reward: structured outputs, retained source citations, PII handling, and evaluation with domain-specific rubrics (LLM-as-judge with a compliance checklist).
Azure AI Speech (Foundry Tool):
For agents, the Speech SDK (azure-cognitiveservices-speech / azure-ai-speech) wraps mic/speaker I/O; latency is minimized by streaming recognition in and starting TTS on the first response tokens.
Voice-enabling an agent = STT front door → agent (text pipeline unchanged) → TTS out, or increasingly a realtime/voice-live API that handles the full speech-in/speech-out loop against a model with barge-in support. Custom speech improves recognition where the base model struggles: train with domain text (vocabulary/jargon), pronunciation files, and/or labeled audio to handle acoustic conditions — deploy the custom model to an endpoint and reference it from the SDK. Test with word-error-rate (WER) comparisons against the base model.
Audio-capable multimodal models accept audio directly in the conversation — transcribe and reason in one step: summarize a meeting from the recording, detect speaker sentiment/hesitation, answer questions about a call ("did the agent read the required disclosure?"). Contrast with the pipeline approach (Speech STT → text LLM): the pipeline is cheaper and gives you the transcript artifact; native audio reasoning captures paralinguistic cues (tone, emphasis) the transcript loses. Content Understanding audio analyzers cover the structured-extraction flavor (call summaries, per-speaker fields) with grounding.
Speech translation (Speech service) does streaming speech-to-text translation into one or more target languages simultaneously, and can synthesize translated audio (speech-to-speech) — the live-interpreter scenario. Alternatively compose: STT → Translator → TTS, which gives more control (custom terminology via Custom Translator) at the cost of added latency. Know that the Speech service's TranslationRecognizer handles the integrated path with a single stream.
For any Language/Translator/Speech scenario, the deciding factors are usually volume + determinism + artifact needs (transcripts, redacted docs, formatted translations) → Foundry Tools, versus reasoning + flexibility + style → LLM/multimodal. Composite answers ("Translator for the documents, LLM for the executive tone summary") are frequently the intended choice.
This domain is the data-plane of RAG and agents: ingesting any content type, enriching and indexing it, and serving semantic/hybrid/vector retrieval — with Content Understanding as the star extraction engine.
The canonical Azure AI Search pipeline: data source → indexer → skillset → index. Indexers pull from Blob Storage, ADLS, Cosmos DB, SQL, and more on schedules; skillsets enrich during indexing; the index stores searchable fields + vectors. For non-text media, extraction services convert content to indexable text/structure first:
Index design: fields flagged searchable/filterable/sortable/facetable/retrievable; vector fields with dimension + HNSW profile; metadata (source, page, timestamp) for citations and filters. Push (your code uploads JSON documents) versus pull (indexer) are the two loading models.
| Search mode | Mechanism | Strengths | Watch-outs |
|---|---|---|---|
| Keyword (BM25) | Inverted index term matching | Exact terms, IDs, precision | Misses paraphrase/synonyms |
| Vector | Embeddings + HNSW ANN | Semantic similarity, multilingual, images-via-embeddings | Can miss exact identifiers; embedding drift |
| Hybrid | Keyword + vector fused with RRF | Best overall recall — default for RAG | Slightly higher query cost |
| Hybrid + semantic ranker | L2 re-rank of top ~50 with captions/answers | Best precision at top-k, extractive answers | Extra latency/billing; needs semantic config |
Query-side details: vectorQueries with k-nearest neighbors, filtered vector search (metadata pre-filtering), integrated query vectorization (the index embeds the query for you), and scoring profiles for boosting. For grounding agents, hybrid + semantic ranker with top 3–5 chunks and source metadata is the standard recipe.
Queries and documents must be embedded with the same embedding model — mixing models (or changing models without re-indexing) silently breaks vector relevance. "Search quality degraded after we switched embedding deployments" → re-embed and rebuild the vector field.
Skillsets transform documents during indexing:
Index projections map one source document to many chunk documents (parent-child), the backbone of integrated vectorization.
For scanned or image-heavy content, OCR is the entry ticket to RAG: use the OCR skill (or Document Intelligence Read/Layout, or CU) to extract text, merge it with native text (Merge skill), split into chunks, embed, and index. Layout-aware chunking (respecting headings, tables, reading order — Document Intelligence Layout or CU markdown output) markedly improves retrieval quality versus blind fixed-size chunks because chunks align with semantic units. Preserve page numbers and bounding regions as metadata so answers can cite page-level sources.
Retrieval must be callable from your orchestration layer:
Azure AI Document Intelligence remains the document workhorse: Read (OCR), Layout (structure: paragraphs, tables, selection marks, reading order, markdown output), prebuilt models (invoices, receipts, IDs, tax forms — typed fields with confidence), and custom models (template and neural, trained on labeled samples; composed models route mixed document types). Content Understanding generalizes this beyond documents: one service, one analyzer concept, across documents, images, audio, and video — schema-driven field extraction with confidence scores and grounding (where in the source each value came from). Confidence scores drive human-in-the-loop review thresholds in production pipelines.
CU's differentiator is that every extracted value is grounded: field results carry source references (page/polygon for documents, timestamp ranges for audio/video), enabling verification UIs (click a value, see the highlighted source region) and audit trails. For RAG, grounded structured output means your knowledge base stores not just chunk text but provenance — so agent citations can point to the exact page or moment, and groundedness evaluation has real evidence to check against.
An analyzer = base analysis mode + your field schema (field names, types, descriptions/generation instructions) for a content type. You create analyzers from prebuilt templates or from scratch, test on samples, and call them via REST/SDK: submit content, poll the async operation, receive results containing (a) structured JSON — the schema's fields with values, confidence, and grounding spans — and (b) content markdown — a faithful markdown rendering of the source (headings, tables, transcript) ideal for chunking into RAG indexes. Field types include extractive (pull the value), classify (choose from options), and generative (summarize/derive). Analyzers are the exam's canonical answer for "turn heterogeneous content into consistent, structured, grounded data at scale."
Content Understanding appears in three domains — visual extraction (Part 3), audio analysis (Part 4), and analyzers/grounded representations (Part 5). The unifying mental model: analyzer + field schema in → structured JSON with confidence and grounding + markdown out, for any modality. If a scenario needs one consistent extraction approach across PDFs, call recordings, and video, CU is the answer.
DefaultAzureCredential + least-privilege RBAC + private endpoints beats keys every time.requires_action for function outputs.azure-ai-projects, azure-ai-inference, azure-ai-evaluation, and the Azure SDK for Python GitHub samples (agents, RAG, evaluation, tracing).Good luck — build at least one end-to-end project (RAG + agent with a function tool + evaluation run + tracing) before you sit the exam. The scenarios reward people who have actually shipped the loop, not just read about it.