Microsoft Developing AI Apps and Agents on Azure AI-103 Exam Questions

Answer : D

The correct selection is D. In Microsoft Foundry Agent Service, tool_choice is the runtime control used to influence whether the model may answer directly or must invoke a tool. Microsoft's tool best-practice guidance states that auto lets the model decide whether to call tools, none prevents tool calls, and required means the model must call one or more tools. This directly addresses the issue where some runs answer from the base model and skip the knowledge base.

For an agentic retrieval solution backed by Azure AI Search through an MCP tool, Microsoft's tutorial states that setting tool_choice='required' ensures the agent always uses the knowledge base tool when processing queries. This produces grounded answers because the run is forced into tool invocation before responding. auto is incorrect because it preserves the nondeterministic behavior already causing missing citations. {'type':'knowledge_base'} is not a valid Foundry tool-choice type. {'type':'mcp'} describes an MCP tool type in some Responses API schemas, but the deterministic guarantee for this agent run scenario is the required tool-call mode. Reference topics: Microsoft Foundry Agent Service, MCP tools, Azure AI Search agentic retrieval, tool_choice, and grounded citations.

Answer : B

The solution does not meet the goal. Increasing max_tokens only raises the maximum number of tokens the model is allowed to generate. Microsoft's Azure OpenAI reference defines max_tokens as the maximum number of tokens allowed for the generated answer, and the quota guidance notes that increasing it can help when responses are being truncated.

In this scenario, the problem is not described as output truncation. The required regulatory clauses are already present in the retrieved policy documents, but the agent omits them during summarization. That is a response completeness issue: Microsoft Foundry RAG evaluator guidance defines response completeness as the recall aspect of the response, meaning the response should not miss critical information compared with expected content or ground truth.

A larger token budget might permit a longer answer, but it does not force the model to identify, verify, or include each mandatory clause. It can also increase cost and latency. The appropriate control is a reflection or completeness verification pass that checks the draft against the retrieved policy clauses and regenerates or revises the response when required content is missing. Reference topics: RAG response completeness, model output limits, max_tokens, reflection, and response validation.

Answer : B

The correct configuration is advanced data parsing because the issue is not merely OCR; the ingestion job must preserve document structure for reliable RAG retrieval. Microsoft guidance for advanced parsing states that it automatically detects tables across all pages, including tables in scanned documents, merges tables that span multiple pages, restores column headers, and creates table chunks with metadata such as table index, shape, page numbers, section headings, and table previews. This directly satisfies the requirement to retrieve specific rows from multipage tables while retaining source-page context.

Basic parsing with fixed-size chunking would flatten the document into arbitrary text fragments, which is the current failure mode. OCR with page-level chunking improves text extraction from scanned PDFs, but it does not provide structure-aware chunks that preserve headings and table relationships across pages. Storing each page as a single chunk is too coarse for row-level retrieval and can bury relevant table rows in excessive context. Advanced data parsing is purpose-built for RAG ingestion because it produces semantically meaningful, retrievable chunks and enriches them with metadata needed for citations and grounding. Reference topics: RAG ingestion, advanced parsing, OCR, table extraction, structure-aware chunking, page metadata, and Azure Blob Storage document ingestion.

Answer : C

The correct capability is tracing because the requirement is to inspect the execution path of an individual agent run. Microsoft Foundry tracing captures detailed telemetry for agent behavior, including LLM calls, tool invocations, agent decision flows, inputs, outputs, tool results, token consumption, duration, and latency. This is the appropriate observability mechanism when you need to determine which step introduced a delay, whether the agent called the internal knowledge API, what data the tool returned, and how the model used that data before producing the final response. Microsoft's Foundry observability guidance describes distributed tracing as the mechanism that provides visibility into LLM calls, tool invocations, agent decisions, and inter-service dependencies.

Token usage is useful for cost analysis and prompt optimization, but it does not show ordered run steps or tool-call sequencing. Safety metrics evaluate risk-related output behavior, not latency or tool execution. General monitoring provides aggregate health, latency, success-rate, and dashboard views, but the question asks for per-run sequence inspection and timing breakdowns. Foundry agent tracing specifically supports debugging unexpected behavior and monitoring latency across requests. Reference topics: Microsoft Foundry observability, agent tracing, OpenTelemetry-based traces, tool invocations, LLM call inspection, and latency diagnostics.

Answer : C

The correct answer is a workflow. Microsoft Foundry workflows are designed to orchestrate agents and business logic as declarative, predefined sequences of actions. The official workflow guidance states that workflows are ideal when you need to orchestrate multiple agents in a repeatable process, add branching logic such as if/else, and handle variables without writing application orchestration code. This directly matches the requirement for a deterministic, step-based process with conditional branching and shared state.

In this scenario, TriageAgent can classify the request first, the workflow can store the triage result, and conditional logic can determine whether to invoke PolicyAgent, ActionAgent, or both. The ticket action is optional, so it should be triggered through a workflow condition based on the triage output. This minimizes development effort because the branching, sequencing, and variable handling are managed in the Foundry workflow rather than being manually implemented across separate runs in application code.

A group chat session is better for dynamic agent handoff, not a strict deterministic process. Threads and runs or separate app-coordinated calls require more custom orchestration. Reference topics: Microsoft Foundry workflows, multi-agent orchestration, conditional branching, variable handling, and agent-driven workflows.

Answer : D

The correct answer is D. Set the output_content_format=ContentFormat.MARKDOWN value. Azure Document Intelligence Layout API can return extracted document content in Markdown format, preserving semantic structure such as headings, paragraphs, sections, tables, and other layout elements. Microsoft's Document Intelligence layout guidance shows the Python SDK pattern for analyzing a document with the prebuilt-layout model and setting output_content_format=ContentFormat.MARKDOWN in the begin_analyze_document call. The Markdown output is returned in the top-level content section of the analysis result.

This minimizes development effort because the service produces structure-preserving Markdown directly, rather than requiring custom post-processing to reconstruct sections and table formatting from raw OCR spans. Microsoft's Markdown output documentation states that specifying Markdown output produces semantically structured content that maintains paragraphs, headings, tables, and other document elements in their proper hierarchy.

Option A only changes validation behavior and does not generate Markdown. Option B requests figures, not structured Markdown. Option C uses an incorrect parameter name; the documented SDK setting is output_content_format, not content. Reference topics: Azure Document Intelligence Layout API, Markdown output, PDF analysis, table extraction, and Foundry Tools document processing.

Answer : A

The correct recommendation is Azure Content Understanding in Foundry Tools. The case study states that Contoso's finance department must manually review vendor invoices to verify that invoice details match vendor contract terms, and that the invoices contain tables, logos, and varied layouts that make consistent processing difficult. It also states that the planned solution must evaluate both the visual layout and textual content of the invoices.

Azure Content Understanding is designed for this type of multimodal document-processing workload. Microsoft describes Content Understanding as a Foundry Tool that processes unstructured and multimodal content, including documents and images, and transforms it into structured output for AI applications. It can use document analyzers to extract text, layout, tables, fields, and relationships from diverse document types.

Chat completions alone would not reliably extract structured invoice fields from complex layouts. Azure Document Intelligence can extract OCR, layout, and tables, but Content Understanding is the better end-to-end Foundry capability for combining visual and textual understanding with structured extraction for downstream verification. Image Analysis focuses on image-level visual features and is insufficient for invoice field and table review. Reference topics: Content Understanding, document analyzers, multimodal extraction, invoice processing, tables, layout, and structured JSON output.