Free Microsoft AB-731 Practice Exam with Questions & Answers | Set: 2

For scanned invoices, the requirement is structured field extraction (invoice number/ID, vendor, totals) from document images or PDFs at scale. The best fit is Azure Document Intelligence because it is purpose-built for document processing and provides prebuilt invoice models that combine OCR with layout/structure understanding to extract common invoice fields into a structured output. Microsoft’s invoice model is explicitly designed to analyze invoices (including scanned images) and return key fields and line items in structured form, which directly maps to this scenario.

Azure Vision (B) can perform OCR and basic image analysis, but OCR alone typically returns text without robust invoice-specific field interpretation (e.g., reliably identifying “Invoice ID” vs. “Order ID,” totals vs. subtotals, vendor vs. ship-to). Document Intelligence is optimized for advanced document structure extraction and is therefore the “best” single recommendation.

Azure AI Search (C) focuses on indexing and retrieval/knowledge mining across a corpus; it’s not the primary service for extracting invoice fields for downstream processing. Azure Machine Learning (D) could be used to build a custom model, but that adds cost and time compared with a prebuilt invoice extractor designed for this document type.

The correct selections are Yes, No, Yes. Prompt engineering is the practice of designing clear and effective inputs that guide a generative AI model toward relevant, accurate, and useful output. Guidelines, constraints, role instructions, tone requirements, and output-format rules are all common prompt-engineering techniques, so statement A is true. Statement B is false because examples are normally considered examples or few-shot demonstrations, not the instruction itself. The instruction tells the model what task to perform, while examples demonstrate the preferred pattern or output style. Statement C is true because context supplies the background information, source material, business scenario, audience, or constraints the model should use when generating the answer. Strong prompts usually combine instruction, context, constraints, and examples.

The task is high-volume content generation with consistent structure and immediate publishing: product descriptions that reliably include chosen product attributes (brand, specs, materials, dimensions, use cases) and can be produced quickly by non-technical staff. The best fit is a fine-tuned LLM (D) because fine-tuning can standardize tone, format, and completeness against your catalog schema, reducing variability and minimizing manual editing before posting. With a fine-tuned model, you can strongly enforce style guidelines (length, voice, prohibited claims), and you can template prompts so staff only supply product fields and get publish-ready copy.

Option A is not best: Azure Machine Learning is excellent for predictive models but is unnecessary for straightforward text generation. B (Researcher) is optimized for multistep research across work data + web, not deterministic product copy generation. C (interactive agent) can help collect requirements, but it’s more complexity than needed; the core need is consistent text generation from structured product data, which fine-tuning addresses directly while keeping user interaction simple (fill fields → generate description).

Enterprise AI adoption succeeds when it is cross-functional from the start . Option A is best practice because AI impacts legal risk, privacy, security, compliance, workforce processes, and business strategy—not just technology. Including leadership ensures alignment to priorities and funding; including business units ensures use cases and success metrics are real; including legal/compliance ensures responsible AI and regulatory obligations are addressed early. This prevents rework and reduces the chance of deploying solutions that are misaligned with policy or unacceptable risk.

Options B and C delay governance and business alignment, which often leads to “build first, govern later” failure modes—solutions that work technically but cannot be approved or scaled due to privacy/security gaps or unclear accountability. Option D over-optimizes for vendor selection without ensuring the organization has defined responsible AI requirements, target use cases, and operating model. Procurement is important, but it is not the primary driver of a successful adoption team. The most sustainable approach is a representative adoption team that integrates business, technical, and governance stakeholders from day one.

To reduce Azure OpenAI costs with minimal quality loss, you target the biggest cost drivers: token usage and model price per token (or throughput unit). C (Optimize the prompts) is a best practice because shorter, clearer prompts reduce unnecessary input tokens and often reduce output length by tightening instructions and formatting. Prompt optimization can preserve or even improve quality by removing ambiguity, adding constraints, and using compact context (for example, only the most relevant grounding passages). Lower token consumption directly lowers cost while maintaining response usefulness.

D (Switch to an alternate model) is also effective because different models have different price/performance tradeoffs. Moving from a premium model to a more cost-efficient model (or a smaller variant) can significantly reduce spend. You can minimize quality impact by validating outputs on representative scenarios and using a tiered approach (cheap model by default, expensive model only for complex cases).

The other options are less aligned to the goal. A (Fine-tune) typically increases cost (training and ongoing evaluation) and is not the first-line cost reducer. B (Content moderation) is primarily a safety control; it can add overhead and doesn’t directly reduce token costs. E (Decrease hosting hours) applies to capacity-based hosting scenarios, but the question states a prebuilt Azure OpenAI model for content generation—cost reduction is best achieved by prompt/token optimization and selecting the right model.

Answer Area

Retrieval Augmented Generation RAG requires model fine-tuning. Answer: No

Retrieval Augmented Generation RAG is helpful when you need a generative AI solution that can access current, verifiable information. Answer: Yes

Retrieval Augmented Generation RAG enables you to get more relevant responses based on your organization’s documents without retraining the base model. Answer: Yes

RAG is an architecture pattern that improves generative AI responses by retrieving relevant information from external knowledge sources (for example, a document index, database, or knowledge base) and injecting that information into the model’s prompt/context at runtime.

No — RAG does not inherently require fine-tuning. Fine-tuning changes the model weights. RAG, instead, keeps the base model as-is and augments it with retrieved context. Fine-tuning can be complementary (for style, domain tone, or specialized tasks), but it is not required for RAG to work.

Yes — RAG is especially valuable when you need current and verifiable information because the retrieval layer can pull the latest approved content (updated policies, product specs, incident runbooks) and provide it to the model. This reduces hallucinations and makes answers traceable to known sources.

Yes — A major benefit of RAG is improved relevance to organizational documents without retraining. Instead of rebuilding the model whenever documents change, you update the underlying content store/index; the model then generates responses grounded in the retrieved passages, producing answers that align with your organization’s latest information and terminology.

Answer Area

Microsoft 365 Copilot connectors enable you to index data from multiple sources to make the data available in Copilot. Answer: Yes

You can build a custom Microsoft 365 Copilot connector when the available connectors do NOT meet your data integration requirements. Answer: Yes

To use Microsoft 365 Copilot connectors, you need a Microsoft Copilot Studio license. Answer: No

Yes — Microsoft 365 Copilot connectors (including synced connectors) are designed to bring external data into Microsoft Graph so it can be semantically indexed and surfaced in Microsoft 365 Copilot experiences. Microsoft explicitly states that synced connectors ingest/crawl content into Microsoft Graph where it’s indexed and then available for Copilot prompts and citations.

Yes — When Microsoft-provided connectors don’t meet integration needs, organizations can create custom connectors (often referred to as Microsoft Graph connectors / custom connector development) to connect other data sources. This is a common extensibility path to index line-of-business repositories and make that content discoverable via Copilot and Microsoft Search.

No — Using Microsoft 365 Copilot connectors does not require a Copilot Studio license. Connectors are generally configured and managed in Microsoft 365 admin/search experiences, and Microsoft’s licensing guidance indicates that users can view connector data in Microsoft 365 Copilot and Microsoft Search with valid Microsoft 365/Office 365 licensing—Copilot Studio licensing is about building agents in Copilot Studio, not a prerequisite to use connectors.

model inaccuracy

The scenario describes a model producing plausible-sounding content that is factually wrong —a common generative AI failure mode often referred to as a “hallucination.” Since “hallucination” is not offered in the dropdown, the best matching choice is model inaccuracy because the core problem is that the model’s output is incorrect even though it appears confident and coherent.

The other options do not fit the definition of the behavior: data leakage is about sensitive information being exposed (for example, proprietary prompts, secrets, or personal data). Prompt injection is an attack technique where a user tries to override system instructions or cause unsafe actions. Overreliance describes a human/organizational risk —trusting the model too much—rather than the model’s intrinsic behavior of generating incorrect facts. Overreliance can be a consequence of this behavior, but it is not what the behavior itself is called.

In practice, you mitigate this kind of inaccuracy by grounding responses in trusted sources (for example, RAG), constraining prompts with explicit requirements, using verification steps (citations, cross-checking, tool-based validation), and adding human review for high-impact use cases.

improves the accuracy and reliability of the predictions and outputs of AI.

High-quality grounding data improves a generative AI solution by anchoring responses to trusted, relevant, and up-to-date information , which increases the likelihood that outputs are accurate, consistent, and aligned with the organization’s expectations. This is why the best completion is “ improves the accuracy and reliability of the predictions and outputs of AI .” When the model is given authoritative context (for example, approved policy text, product specifications, knowledge base articles, or controlled enterprise content), it has less need to “guess” based on general patterns in its training data. That reduces hallucinations and improves response relevance to the user’s question and the business domain.

It does not “ensure that all responses are factually accurate” because grounding reduces errors but cannot eliminate them completely—retrieval can return incomplete or irrelevant passages, user prompts can be ambiguous, and the model can still misinterpret context. It also does not inherently “increase performance of an AI model” in the sense of speed/throughput or model capability; grounding is an architecture and data strategy that improves output quality, not compute efficiency. Finally, grounding is not about “increasing storage required to host an AI model.” While you may store documents in an index or repository, the core benefit is improved response quality through better context, not larger model hosting requirements.

Answer Area

A generative AI model guarantees factually accurate responses if the model is trained on a large dataset. Answer: No

Content filtering and responsible AI safeguards help a generative AI model generate safe and inoffensive content. Answer: Yes

A generative AI model always produces fair and unbiased results when the training data has been properly prepared and reviewed for fairness. Answer: No

No — A larger training dataset can improve coverage and fluency, but it does not guarantee factual accuracy. Generative models can still hallucinate, mix concepts, or produce plausible-but-incorrect statements because they generate likely text rather than verifying truth. This is why solution designs commonly add grounding/retrieval, validation, and human review for high-stakes outputs.

Yes — Content filtering and Responsible AI controls are specifically used to reduce harmful, unsafe, or policy-violating outputs . In practice, safeguards include input/output filters, safety classifiers, and governance controls that help enforce safety policies and minimize offensive content. These controls don’t make outputs “perfect,” but they materially reduce risk and are a standard part of production AI deployments.

No — Even with careful data preparation and fairness reviews, models can still produce biased outcomes due to residual bias in data, label/measurement issues, deployment context, and shifting real-world distributions. “Always fair and unbiased” is an absolute claim that is not achievable in real systems; fairness is managed through continuous evaluation, monitoring, and mitigations—not assumed as guaranteed.