Microsoft AI-103 - Questions & Answers

PII detection is the control that aligns with the customer information requirement in the case study. Agent1 is grounded on product sheets stored for customer support. If material containing customer names, contact data, or other sensitive identifiers is accidentally added to that repository, the agent must not expose those details in its responses. A PII detection capability can identify personal data in generated content or retrieved context and support blocking or redaction before information is returned to users.

Prompt shields address prompt injection attempts, such as malicious instructions embedded in third-party content, but the question asks for the security and compliance control tied to preventing customer information disclosure. Self-harm and violence filtering are content harm categories; they are useful for general safety moderation but do not specifically detect personal identifiers. The best fit is therefore the capability that targets sensitive personal data rather than generic harmful content or adversarial prompt behavior.

Azure AI Search is the appropriate recommendation because Agent1 needs to retrieve detailed product information from PDF product sheets stored in Azure Blob Storage. The technical requirement is not simple file storage or translation; it calls for an indexing pipeline that supports semantic and vector search so the agent can ground natural language answers in the most relevant product content. Azure AI Search is the service designed to index enterprise content, enrich it, and return relevant passages for Retrieval Augmented Generation.

Azure Translator handles language translation and does not provide retrieval over product manuals. Azure Document Intelligence can extract document structure and fields, but by itself it does not provide a reusable semantic search index for agent grounding. Grounding with Bing Search is for public web content, while the requirement is to use internal product sheets in storage1. A search index connected to the agent gives the required retrieval layer and keeps answers focused on approved product information.

Azure Content Understanding in Foundry Tools is the best fit for the invoice review scenario because the invoices contain tables, logos, varied layouts, and textual details that must be evaluated against vendor contract terms. The problem is not merely generating text or reading a single field. The solution must understand document layout and content together so invoice values, table entries, and visual structure can be interpreted consistently across suppliers.

Chat completions alone would require the application to provide already-structured content and would not solve extraction across varied invoice layouts. Azure Document Intelligence is strong for document extraction, but the scenario emphasizes a Foundry tool that can combine visual layout and textual content for complex document understanding. Image Analysis is too narrow because it focuses on visual features rather than structured business document review. Content Understanding provides the document-processing layer needed before downstream validation can compare invoice details with contract terms.

Modifying the system message instructions is the right way to constrain Agent1 to answer only about Contoso products. A system message defines the agent's operating rules, scope, and refusal behavior. In this case, the business requirement is a policy boundary: the agent should stay within Contoso product information and avoid answering general questions outside that domain. Clear instructions can tell the agent to use approved product grounding and to decline when the requested information is outside scope.

Top-p sampling and temperature are generation controls. They influence randomness and diversity, but they do not establish a durable business boundary. Increasing temperature would make responses less predictable, not more compliant. Few-shot examples can demonstrate style or patterns, but examples alone are weaker than an explicit system-level instruction for domain restriction. The control that directly expresses the rule the agent must follow is the system message, ideally combined with retrieval grounded in the approved product sheets.

A custom Azure Content Understanding analyzer is the correct choice because the application needs a single analyzer that extracts specific invoice fields across varying templates and returns confidence scores for routing. The requested fields are invoice number, invoice date, vendor name, and total amount. Those are business-specific fields, so the analyzer should be configured with the extracted fields the workflow needs rather than relying only on a generic layout result.

A prebuilt layout analyzer can preserve structural content, but it is not enough when the application requires named field extraction and confidence-driven supervisor review. A groundedness guardrail evaluates generated responses; it does not create a document analyzer that extracts invoice fields into structured JSON. A document search analyzer and search score relate to retrieval relevance, not field-level extraction confidence. The custom analyzer provides the right combination of field schema, structured output, and confidence values so low-confidence invoice results can be sent to a human supervisor before they are used as grounding data.

Increasing temperature does not meet the goal because temperature controls randomness in generation. A higher value usually makes responses more diverse and less deterministic. The reported problem is that summaries omit required regulatory clauses even when the clauses are present in retrieved content. That is a completeness and grounding issue, not a need for more creative wording. Raising randomness can make omissions more likely or make responses harder to validate.

To improve completeness, the system should use controls that check whether required information from retrieved documents is included, such as reflection, completeness evaluation, stronger instructions, or retrieval-aware validation. The solution in the item changes only a sampling parameter and does not add a verification step against the retrieved policy clauses. It also does not improve retrieval quality or expand the agent's ability to inspect the source material. Therefore the proposed solution fails to address the cause of the missing regulatory content.

The project property should be set to the custom speech project ID. In a custom speech workflow, the model is trained and managed within a custom speech project, and REST operations that refer to that project need the project's identifier. The error says the project ID is invalid, so the fix is to provide the actual ID of the custom speech project associated with the fine-tuned speech to text model.

The custom speech endpoint URL is used to send recognition traffic to the deployed endpoint, but it is not the project identifier. A project URL is a portal or service location and is not the value expected by the project property. A generic Foundry project ID would not necessarily identify the custom speech project used by the Speech service. The key detail is that custom speech has its own project metadata for training and deployment, so the request must use that custom speech project ID.