AB-731 Questions and Answers

Microsoft Copilot Studio is built for creating and managing custom agents that handle employee self-service and business process automation. The two capabilities that align directly to this purpose are D and E .

D is correct because Copilot Studio lets you build agents that connect to enterprise data and systems and then perform actions on behalf of users. This is the foundation for automation and self-service: the agent can answer questions using connected knowledge sources and can also trigger workflows (for example, submitting a request, creating a ticket, checking status, or updating records) through connectors and actions. These integrations allow the agent to move beyond “chat” into real operational outcomes, which is exactly what business process automation requires.

E is correct because Copilot Studio provides the controls needed to customize how an agent behaves and responds. This includes defining conversational topics/flows, setting instructions and guardrails, shaping tone and response style, configuring fallback behavior, and controlling how generative answers are produced (for example, using approved knowledge sources). Customization ensures the agent behaves consistently with company policies and provides reliable employee experiences.

The other choices represent different Microsoft products: A is aligned to security operations tooling (Security Copilot), B relates to information protection/governance (Purview), and C is a Microsoft 365 Copilot capability inside Word/PowerPoint rather than a Copilot Studio feature.

Construction blueprints in PDFs often contain a mix of text, symbols, linework, and diagrams . The requirements include understanding both visual layout (where systems are located) and textual annotations , producing summaries, and answering Q & A. That combination requires a multimodal generative AI approach—models that can reason over images and text together. Therefore, A is best.

OCR alone (B) can extract printed text, but it won’t reliably interpret diagram geometry, symbols, or spatial relationships (e.g., “electrical riser is on the east core near gridline B-4”). Text completion (C) is too generic and doesn’t address image understanding. Document summarization (D) is only one requirement (summary) and still depends on first extracting/understanding both visual and textual elements.

A multimodal solution can ingest the PDF pages as images (or rendered page images) plus extracted text, then answer questions grounded in both modalities. In practice, you may combine OCR and layout extraction with a multimodal LLM so the model can reference drawing regions, legends, callouts, and system diagrams to produce accurate explanations and field extractions.

Answer Area

Retrieval Augmented Generation (RAG) architectures require that a large language model (LLM) be retrained on proprietary data. Answer: No

Retrieval-Augmented Generation (RAG) grounds a language model to produce more factual and context-relevant responses. Answer: Yes

Retrieval Augmented Generation (RAG) retrieves information from external knowledge sources at runtime instead of relying solely on the knowledge of a generative AI model. Answer: Yes

1) No — RAG does not require retraining or fine-tuning the base LLM on proprietary data. The defining idea of RAG is to keep the model as-is and instead supply it with relevant context retrieved from trusted sources at inference time. Fine-tuning can be optional for style or specialized behavior, but it is not a requirement for RAG.

2) Yes — RAG is a grounding approach. By retrieving authoritative passages (policies, manuals, product specs, internal knowledge bases) and injecting them into the prompt context, the model’s answer is constrained by evidence that is relevant to the user’s question. This improves factuality and domain relevance and helps reduce hallucinations.

3) Yes — RAG explicitly depends on runtime retrieval from external knowledge sources, such as indexed documents, databases, or enterprise repositories. The retrieval layer finds the best matching content for the query, and the generation layer uses that retrieved content to craft the response. This is why RAG is valuable when information changes frequently: you update the source documents/index rather than retraining the LLM.

Overall, RAG is best understood as an architecture pattern that combines search/retrieval + generation , improving accuracy and freshness without the cost and risk of retraining the underlying model each time the knowledge base changes.

Answer Area

You can use Azure Language in Foundry Tools to analyze the sentiment of customer reviews. Answer: Yes

You can use Azure Language in Foundry Tools to translate internal reports into multiple languages. Answer: No

You can use Azure Language in Foundry Tools to extract text from scanned documents. Answer: No

Azure Language is designed for natural language processing (NLP) over text that is already machine-readable. That includes capabilities like sentiment analysis , key phrase extraction, entity recognition, summarization, and classification. Therefore, statement 1 is Yes : sentiment analysis of customer reviews is a standard NLP workload where the service scores text as positive/negative/neutral (and often provides confidence scores), helping organizations quantify customer satisfaction and detect recurring issues.

Statement 2 is No because translation is typically handled by a dedicated translation capability (commonly delivered as a separate translator service) rather than the core “Language” NLP features. While translation is an AI language workload, it’s not what the Azure Language service is primarily used for in this context; the expected Microsoft service choice for multi-language translation is the translator capability, not Azure Language.

Statement 3 is No because extracting text from scanned documents is OCR (optical character recognition), which is a computer vision/document processing function. OCR is delivered through Azure Vision and/or Azure Document Intelligence , which can read printed/handwritten text from images and PDFs and return structured output. Azure Language can analyze extracted text after OCR, but it does not perform the image-to-text extraction step itself.

The problem is harmful output language (inappropriate or exclusionary/ableist content). The requirement says you must prevent those responses while minimizing costs . The most cost-effective and direct control is to add a content-moderation filter (B) to screen and block (or rewrite/escalate) responses that violate your safety or inclusion standards. Moderation can be applied at the output stage (and often also at input) without retraining the model, which keeps costs and delivery time low. It also provides an immediate safety layer even if the underlying model occasionally produces biased or exclusionary phrasing.

Option A is not reliable: a newer model version might reduce issues but does not guarantee elimination of ableist language, and you still need policy enforcement. Option C (retraining on only inclusive content) can help, but it is typically expensive (data curation, re-training, re-evaluation, regression testing, re-deployment) and not the “minimize costs” path—also it can reduce coverage/utility if overly restrictive. Option D is clearly wrong because it would amplify the harmful behavior.

In practice, the lowest-cost, high-impact approach is to implement moderation thresholds and handling actions (block, warn, regenerate with constraints, human review) and then, if needed, follow up later with deeper mitigations like prompt constraints, targeted fine-tuning, red-teaming, and continuous evaluation.

By default, Microsoft 365 Copilot is grounded in your organization’s Microsoft 365 data through Microsoft Graph , and it respects the user’s existing permissions. For “find and summarize information across internal documents,” the most direct default document repositories in Microsoft 365 are SharePoint (team sites and shared libraries) and OneDrive (a user’s work files). That is why C (Microsoft SharePoint) and D (Microsoft OneDrive) are the correct selections. Microsoft explicitly describes Copilot as accessing organizational content via Microsoft Graph, including user documents and related work content.

The other options are not “by default” sources. A (on-premises file share) is not automatically part of Microsoft Graph unless you integrate/migrate content or use connectors to make it discoverable in Microsoft 365 experiences. B (custom CRM) similarly requires an integration approach (for example, Microsoft 365 Copilot connectors / Graph connectors) to index and expose that data for Copilot to use. E (Microsoft Sway) is not a primary default content source for Copilot’s document grounding and is not typically referenced as a core internal document repository compared to SharePoint/OneDrive.

So, for immediate, out-of-the-box internal document discovery and summarization within Microsoft 365, SharePoint + OneDrive are the default answer.

The requirement has two key phrases: indexing information and knowledge mining by extracting insights from documents . The Microsoft service purpose-built for this is Azure AI Search (formerly Azure Cognitive Search), which provides a search index over your content and supports “AI enrichment” workflows to extract and structure insights from documents during indexing.

Azure AI Search can ingest content from common enterprise sources (files, blobs, databases), build searchable indexes, and enrich the indexed content using built-in skills or integrated AI capabilities—such as entity recognition, key phrase extraction, language detection, and OCR (depending on the pipeline). This is exactly what “knowledge mining” refers to: turning large volumes of unstructured documents into structured, searchable knowledge that applications and users can query.

The other choices are partial fits: Azure Vision focuses on image/video analysis, not general document indexing. Azure Document Intelligence is excellent for extracting fields/tables from forms and documents, but on its own it does not provide the full indexing/search and knowledge mining layer across a corpus. Microsoft Foundry is an overarching platform for building AI apps/agents; it can incorporate search, but the specific service that directly delivers indexing + knowledge mining is Azure AI Search .

Answer Area

A text-to-image generator can be used to translate content into other languages. Answer: No

A predictive analytics model can generate new marketing content for a company’s online ads. Answer: No

A generative AI chatbot can engage customers in personalized conversations and recommend products. Answer: Yes

No — A text-to-image generator’s primary function is to create images from text prompts , not translate text between languages. Translation is a natural language processing task typically handled by language models or dedicated translation services. A text-to-image model could illustrate translated content (e.g., generate an image based on a translated prompt), but it is not the tool used to perform the translation itself.

No — Predictive analytics models are designed to predict outcomes (forecasts, probabilities, classifications) from historical patterns, such as predicting click-through rate, churn, or next-quarter demand. They are not designed to create new ad copy or marketing creatives. Generating new marketing content is a generative AI capability (text generation), not predictive analytics.

Yes — A generative AI chatbot is well-suited to interactive, natural-language conversations . With access to product catalogs and business rules, it can ask clarifying questions, tailor responses to customer needs, and recommend products (for example, suggesting tents based on group size, season, and budget). This combines conversational generation with retrieval/recommendation logic behind the scenes, enabling personalized customer engagement at scale.

Microsoft Foundry is positioned as a unified platform experience for building, optimizing, and governing AI applications and agents. Microsoft explicitly emphasizes “fleetwide security and governance” and the ability to build and manage AI in a unified environment, which directly supports statement 1 being Yes : it is designed to help organizations build and operate generative AI solutions with centralized governance controls (for example, environment setup, data isolation, access control, and operational management).

For statement 2, Foundry supports scaling as demand increases . Microsoft documentation for Foundry-related model usage notes that as usage grows, Foundry can automatically increase quotas by moving users to higher tiers (and allows requesting additional quota). This is a concrete scalability mechanism tied to increased workload demand, so the statement is Yes .

For statement 3, Foundry is not limited to text-only generative AI. Microsoft provides “Azure Vision in Foundry Tools,” which delivers computer vision capabilities such as analyzing images, reading text (OCR), and other image-processing features. That means Foundry can be used for image recognition/computer vision workloads, so the statement is Yes .

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.

The requirement is explicit: users must have access to the Researcher agent in Microsoft 365 Copilot and use it to search across organizational content stored in SharePoint . Microsoft’s licensing guidance for Researcher indicates that Researcher is available to Microsoft 365 business and enterprise users who have a Microsoft 365 Copilot add-on license (and also to certain consumer “Microsoft 365 Premium” subscriptions).

That maps directly to option C . The Researcher agent is part of the Microsoft 365 Copilot experience for work tenants; it is not enabled merely by having a baseline Microsoft 365 subscription entitlement (B). Baseline subscriptions can provide access to Microsoft 365 apps and content repositories (like SharePoint/OneDrive), but the Researcher agent itself is a Copilot capability that requires the Copilot add-on to unlock.

Option A (pay-as-you-go) and D (usage-based consumption license in Azure) describe consumption models that apply to Azure services or agent metering in some scenarios, but they are not the standard licensing requirement to enable the built-in Researcher agent for Microsoft 365 Copilot users. When the goal is to enable Researcher inside Microsoft 365 Copilot for staff, the practical and correct recommendation is to assign the Microsoft 365 Copilot per-user add-on license to the users who need it, ensuring their SharePoint access is already properly permissioned and governed.

Answer Area

Larger datasets can increase the cost of a generative AI solution that uses an Azure Machine Learning workspace. Answer: Yes

The cost of consuming Azure OpenAI models is primarily identified by the number of input and output tokens processed. Answer: Yes

The cost of custom generative AI solutions always remains the same regardless of the model version or capability used. Answer: No

Yes — In Azure Machine Learning, cost is driven by the resources you consume to store, process, and train. Larger datasets typically require more storage, more data transfer, and more compute time for preprocessing, training, evaluation, and experimentation. Even if you are not training foundation models, handling larger corpora can increase pipeline duration and the number/size of compute instances used, which increases overall cost.

Yes — For Azure OpenAI usage under Standard (on-demand), pricing is primarily tied to token-based consumption (input tokens + output tokens). The more context you send and the longer the generated responses, the more tokens you consume, and the higher the cost. This is why prompt optimization, response length controls, and grounding strategies matter for cost management.

No — Costs vary with model choice and capability. Different model families and versions have different price points, and larger/more capable models generally cost more per token or per unit of throughput. Additionally, architecture choices (RAG, vector search, caching), usage patterns, and throughput requirements can significantly change total cost—so it is never “always the same.”

The requirement is an interactive generative AI experience that can converse with customers and ask clarifying questions (for example: “What climate are you hiking in?”, “How many people will share the tent?”, “What’s your budget?”, “Do you prioritize weight or comfort?”). The best solution component for that conversational, question-and-answer interaction is a chatbot (A), powered by a generative AI model.

A chatbot provides the dialog framework: maintaining conversational context across turns, prompting the user for missing requirements, and responding in natural language. This makes it suitable for customer support, guided shopping assistance, troubleshooting, and pre-sales Q & A—especially when customers don’t know exactly what they need and benefit from a guided conversation.

The other options don’t match the core requirement. Predictive AI (B) forecasts outcomes (like demand or churn) and isn’t inherently conversational. Computer vision (C) analyzes images (like recognizing products from photos) and doesn’t address asking questions in dialogue. A recommendation engine (D) can be useful in ecommerce, but it typically suggests items based on behavior or attributes; it doesn’t by itself provide a conversational flow that asks users questions and adapts responses in natural language. In practice, you can combine a chatbot with a recommendation engine behind the scenes—but the “include in the solution” component that directly satisfies interactive questioning is the chatbot.

A pretrained generative AI model is trained initially on a large, broad, and diverse dataset so it learns general language (or multimodal) patterns and capabilities. Fine-tuning then takes that pretrained base and performs additional training on a smaller, task- or domain-specific dataset to specialize behavior—improving performance for a particular use case, tone, style, or domain knowledge representation. That is exactly what option C states, making it the correct answer.

Option A is incorrect because both pretraining and fine-tuning may use labeled or unlabeled data depending on the technique; the distinction is not “labeled vs. unlabeled.” Option B is incorrect because a pretrained model is not “faster to train” due to fewer parameters; pretraining is typically the most compute-intensive phase precisely because it’s done at large scale, while fine-tuning is smaller but still trains the same model architecture. Option D is reversed: the pretrained model is the general-purpose foundation, while the fine-tuned model is the specialized variant for a specific task or dataset.

Answer Area

Prompt engineering changes how a generative AI model was trained. Answer: No

Prompt engineering focuses on designing clear, concise, and context-rich instructions. Answer: Yes

Effective prompt engineering involves maximizing the number of tokens used in each request. Answer: No

No — Prompt engineering does not modify model weights or retrain the model. It is an inference-time technique : you steer outputs by improving the instructions and context you send to the model. Changing how a model was trained would involve pretraining, fine-tuning, or other training methods—separate from prompt engineering.

Yes — The primary goal of prompt engineering is to reduce ambiguity and variability by providing clear instructions , the right context , and explicit output constraints . This often includes specifying role and task, providing necessary facts or grounding text, defining format (bullets, JSON, headings), and adding examples (few-shot) when helpful. Well-constructed prompts improve consistency, relevance, and usefulness of outputs.

No — Good prompt engineering does not mean “use as many tokens as possible.” In fact, using unnecessary tokens can increase cost and may degrade quality by adding noise. Effective prompts are typically as short as possible but as long as necessary : enough context to achieve accuracy and alignment, but not bloated. Token discipline matters because most pricing is token-based and long contexts can dilute attention over what’s most important.

Answer Area

Azure Vision in Foundry Tools can extract and analyze key phrases from PDF files. Answer: No

Azure Vision in Foundry Tools can generate images based on natural language descriptions. Answer: No

Azure Document Intelligence in Foundry Tools can be used to automate the processing of invoices and credit notes. Answer: Yes

No — Azure Vision in Foundry Tools focuses on computer vision tasks such as image analysis and OCR (reading text from images and documents). While it can extract text from scanned PDFs via OCR, key phrase extraction is a natural language processing capability provided by Azure Language in Foundry Tools , not Azure Vision. Key phrase extraction analyzes text to identify main concepts, which is a different service family than vision.

No — Azure Vision can analyze existing images (for example, generate captions/descriptions of an image), but generating new images from a text prompt is a generative model capability (for example, DALL·E through Azure OpenAI/Azure AI Foundry model endpoints), not an Azure Vision feature. Vision describes what it “sees”; it doesn’t synthesize new images from natural language.

Yes — Azure Document Intelligence in Foundry Tools is designed for intelligent document processing , including automating extraction of structured fields from financial documents. Microsoft provides prebuilt models for invoices and supports custom extraction for similar document types, which makes it suitable for automating workflows involving invoices and credit-note style documents (field extraction, validation, routing).

Microsoft Foundry is positioned as a unified, enterprise-grade platform that helps organizations build, deploy, scale, and govern AI apps and agents—especially generative AI solutions that need to work with business context and internal data. That directly aligns with A : Foundry provides a scalable platform for developing and deploying generative AI solutions. Microsoft describes Foundry as an interoperable platform that makes it easier to build, deploy, and scale AI apps and agents, while also providing centralized security and governance features for organizations.

B is incorrect because Foundry does not remove model choice/configuration; in fact, it supports selecting among models and using tools/frameworks to build solutions. You still choose appropriate model(s), configure endpoints, and design grounding and safety controls.

C and D are not the best characterization of Foundry’s primary benefit. While Foundry offers “friendly interfaces,” Microsoft primarily positions it for developers, model builders, and enterprise AI operations —not as a low-code platform for business users (that role is more commonly filled by Copilot Studio/Power Platform).

promote the ethical and accountable use of AI.

Microsoft’s Responsible AI principles exist to guide organizations toward trustworthy, ethical, and accountable development and use of AI systems. Among the provided options, “ promote the ethical and accountable use of AI ” is the most accurate and comprehensive statement because it reflects the purpose of the principles themselves: ensuring AI is built and deployed in a way that respects people, reduces harm, and assigns clear responsibility for outcomes.

The other choices are either too absolute or too narrow. “Ensure that AI models deliver consistent and equitable results” is aspirational but not guaranteed—responsible AI practices reduce bias and improve reliability, but they cannot ensure perfect consistency or equity across all contexts. “Help organizations increase trust in fully autonomous AI systems” is not the intent; responsible AI emphasizes oversight and accountability, not pushing toward full autonomy. “Standardize model development practices across AI teams” can be a side benefit of governance, but it’s not the primary reason to adopt responsible AI principles.

In practice, adopting these principles leads to concrete actions: defining governance and accountability, performing fairness and safety evaluations, protecting privacy and security, being transparent with users, and monitoring systems after deployment. These actions build stakeholder trust and enable sustainable adoption, but the foundational reason is that the principles provide a framework for ethical and accountable AI use.