AB-731 Questions and Answers

The requirement is specific: users must build and use declarative agents that can access work data (tenant data / organizational context). Microsoft’s licensing guidance for Copilot extensibility ties use of declarative agents to having the appropriate Copilot entitlement that enables tenant grounding and organizational data access. In Microsoft’s cost and licensing considerations for declarative agents, Microsoft states that to use a declarative agent, users must have a Microsoft 365 Copilot add-on license (or an equivalent Copilot Chat add-on path tied to eligible licensing). Therefore, among the provided options, the best recommendation is A.

Option B (Copilot Studio user license) is primarily about authoring/building agents in Copilot Studio, but it is not, by itself, the licensing prerequisite that grants end users the right to use those agents with full Microsoft 365 Copilot capabilities and work-data grounding inside the Microsoft 365 Copilot environment. Publishing/building can be separate from the end-user entitlement to use the agent with organizational context.

Option C (Copilot Chat pay-as-you-go) can enable usage-based access to declarative agents in some configurations, but the question asks for the best license recommendation for users who need work-data access through declarative agents. The Microsoft 365 Copilot add-on is the straightforward, fully supported entitlement for that scenario.

Most generative AI language model pricing is based on token consumption, which measures the amount of text processed by the model. Tokens are sub-word units used internally by language models (for example, parts of words, whole words, or punctuation). When you send a prompt, the model consumes input tokens (your prompt + any system instructions + retrieved grounding context). When it generates a response, it consumes output tokens (the generated completion). Costs typically scale with the total input + output tokens processed, which is why long prompts, large grounding passages, and lengthy responses increase spend. This also explains why prompt optimization, response length limits, caching, and careful grounding are common cost-control techniques in enterprise solutions.

By contrast, “documents” is too coarse (a document can be 1 page or 500 pages). “Requests” is not the primary unit for most LLM pricing models because request sizes vary dramatically. “Words” is not used because the model’s actual compute unit is tokens, and tokenization differs across languages and text patterns. Therefore, the most accurate completion is tokens.

Answer Area

A manufacturer can use Azure Vision in Foundry Tools to identify product defects on an assembly line. Answer: Yes

A logistics company can use Azure Vision in Foundry Tools to recognize package shipping labels. Answer: Yes

The HR department at your company can only use Azure Vision in Foundry Tools to extract written content from Microsoft Word files. Answer: No

Azure Vision in Foundry Tools provides computer vision capabilities to analyze images, including identifying visual features and reading text with OCR. Because it is designed to “analyze images” and support vision scenarios, it can be applied to manufacturing quality inspection use cases where the goal is to detect anomalies/defects from images captured on a production line. This aligns with statement 1 being Yes.

Statement 2 is also Yes because recognizing shipping labels is fundamentally text extraction from images (often plus some layout/field parsing). Azure Vision supports optical character recognition (OCR) to read printed text from images, and Microsoft documentation explicitly notes OCR can extract text from images such as product labels and similar real-world text surfaces—making shipping labels a direct fit.

Statement 3 is No because it is incorrectly restrictive. Azure Vision is not limited to extracting written content from Word documents, nor is OCR restricted to Word files. Vision capabilities apply broadly to images (and, depending on the capability, various document/image inputs) for tasks like image analysis and text recognition. HR could use it for many scenarios such as extracting text from scanned images, photos, or other visual inputs—not “only” Word files.

Answer Area

Allowing AI models to make autonomous decisions supports the Microsoft responsible AI principle of accountability. Answer: No

Regularly testing AI models for fairness and inclusiveness helps ensure they align with Microsoft’s Responsible AI principles. Answer: Yes

Protecting user data and limiting access to personal information supports the Microsoft responsible AI principles of privacy and security. Answer: Yes

Microsoft’s Responsible AI principles emphasize that people and organizations must remain accountable for AI systems and their outcomes. Accountability is strengthened by governance, human oversight, clear ownership, auditability, and processes to review and address issues—not by letting models make unchecked autonomous decisions. Therefore, statement 1 is No: increasing autonomy can actually increase risk unless paired with human-in-the-loop controls and clear escalation paths, because accountability requires clear responsibility for decisions and impacts.

Statement 2 is Yes because fairness and inclusiveness are explicitly supported through ongoing evaluation. Regular testing helps detect disparate impact, performance gaps across user groups, and unintended bias introduced by data drift or changes in usage patterns. It’s not a one-time activity; it’s continuous assurance that the system behaves appropriately as conditions change.

Statement 3 is Yes because privacy and security are directly supported by protecting personal/sensitive data, enforcing least privilege access, and implementing controls such as data loss prevention, encryption, access logging, and strong identity governance. Limiting access to personal information reduces exposure and supports compliance obligations while aligning with privacy-by-design and secure-by-design expectations for AI-enabled solutions.

The correct answer is A. Microsoft Security Copilot. The requirement is clearly a security operations scenario: analysts must investigate incidents across endpoint, identity, cloud, and security operations data. Microsoft Security Copilot is designed for security teams and supports natural-language investigation, alert summarization, incident context, affected-resource identification, and recommended response actions. Microsoft 365 Copilot is focused on productivity tasks such as drafting, summarizing, and analyzing content in Microsoft 365 apps. Azure Document Intelligence extracts structured information from documents such as forms and invoices. Microsoft Copilot Studio is used to build and customize agents for business workflows. Because the scenario centers on security incident investigation and response guidance, Microsoft Security Copilot is the correct solution.

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.

Answer Area

Extracting structured data from forms and invoices: Answer: Azure Document Intelligence in Foundry Tools

Summarizing written content from business reports: Answer: Azure Language in Foundry Tools

Generating descriptive text for uploaded images: Answer: Azure Vision in Foundry Tools

These three tasks align to three different Azure AI capability families: document processing, language understanding/generation, and computer vision.

Forms and invoices are semi-structured documents where the business need is to extract specific fields (IDs, names, totals, dates) reliably into structured output. Azure Document Intelligence is designed for intelligent document processing and includes prebuilt models (such as invoices) as well as custom extraction options, making it the correct choice for structured data extraction from documents.

Summarizing written business reports is an NLP task focused on compressing long text into key points, themes, and action items. Azure Language provides language processing capabilities (including summarization features within language service capabilities), so it is the best fit for summarization scenarios.

Generating descriptive text for images (image captioning/description) is a computer vision task. Azure Vision can analyze uploaded images and return descriptions/captions and other visual insights, which directly matches the requirement to produce descriptive text from images.

crafting clear instructions to guide generative AI solutions in generating context-appropriate content.

Prompt engineering is fundamentally about how you communicate intent to a generative AI model so it produces outputs that meet business expectations. The best completion is “crafting clear instructions to guide generative AI solutions in generating context-appropriate content” because it captures the practical, day-to-day discipline: shaping the input (prompt) with the right task framing, constraints, context, and output format.

In real deployments, prompt engineering includes specifying the role and objective (for example, “act as a customer support agent”), providing the necessary context (product details, policy excerpts, audience), adding explicit requirements (tone, length, must/must-not statements), and defining structured output (JSON fields, bullet sections, headings). It can also include adding examples (few-shot prompting), clarifying what to do when information is missing, and instructing the model to cite only provided sources or to ask follow-up questions. These techniques reduce ambiguity, improve consistency, and lower the risk of hallucinations or off-brand responses.

The other options are not accurate definitions. “Integrating AI-powered tools into business workflows” describes solution adoption/integration, not prompt engineering. “Identifying and fixing errors in AI-generated content” is review/editing or quality assurance. “Designing, developing, and training generative AI models” is model development/ML engineering. Prompt engineering operates without changing model weights; it’s about steering model behavior through well-constructed instructions and context.

Grounding is an AI solution pattern used to improve response quality by ensuring the model’s output is based on trusted, relevant information provided at inference time, rather than relying only on what the model “remembers” from training. Therefore, C is correct: grounding anchors responses in specific data sources .

In practical deployments, grounding commonly uses retrieval (often called Retrieval Augmented Generation, or RAG) where the system first finds relevant content from approved sources—such as internal policy documents, product documentation, knowledge bases, or databases—and then includes that content in the prompt context sent to the model. Microsoft’s guidance describes grounding data as information supplied at inference time to help responses become more accurate and relevant because the model is guided by authoritative, up-to-date content that may not have been part of original training.

The other options do not define grounding. A relates to inclusion practices and diversity considerations, which are important for responsible AI but are not what grounding means. B describes transparency/explainability concepts. D relates to model evaluation/communication of limitations. Grounding is specifically about tying outputs to known sources, which reduces hallucinations and improves business trust in the generated responses.

The strongest privacy risk mitigation for analyzing customer feedback is to minimize personal data exposure while preserving the analytical value of the text. A is best because anonymizing (or de-identifying) the dataset removes direct identifiers (names, emails, phone numbers, addresses, account IDs) and reduces the likelihood of privacy breaches, unauthorized re-identification, or inadvertent leakage in model outputs. This aligns with privacy-by-design and the general principle of data minimization: only retain the information necessary for the business purpose.

B is usually impractical and undermines business value and auditability; organizations often need retention windows for validation, traceability, and improvement. C is not the best privacy mitigation: keeping data attributable to individuals increases privacy exposure; while deletion-on-request is important for compliance, it’s not the primary mechanism to reduce privacy risk during analysis. D is explicitly poor practice; privacy reviews should occur throughout the lifecycle (requirements, design, data acquisition, testing, deployment, monitoring), not only at the end. Therefore, anonymizing/removing PII at the source is the best first-line approach.

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.

For a user to access organizational data from a mobile device, the user needs a Microsoft 365 Copilot license. No

To reason over your organizational data by using Microsoft Graph, you need a Microsoft 365 Copilot license. Yes

To use the Analyst agent, you need a Microsoft 365 Copilot license. Yes

Top of Form

Bottom of Form

The key distinction here is between Copilot Chat capabilities available with a standard Microsoft 365 subscription and the full Microsoft 365 Copilot add-on that enables richer, in-context experiences grounded in organizational data.

Mobile access to organizational data does not inherently require a Microsoft 365 Copilot license. Microsoft’s Microsoft 365 Copilot app (and related mobile experiences) can provide Copilot Chat for work/school accounts with a Microsoft 365 license, so simply accessing organizational content on a mobile device is not the same as having the paid Copilot add-on. The statement claims a Copilot license is required just to access org data from mobile, which is too broad—there are mobile Microsoft 365 apps that access org data without the Copilot add-on.

Reasoning over organizational data via Microsoft Graph is a core value proposition of Microsoft 365 Copilot. Microsoft documents explain that Microsoft 365 Copilot connects LLMs to your organization’s content and context through Microsoft Graph and generates responses “anchored” in organizational data. That deeper integration is tied to the Microsoft 365 Copilot experience (an add-on license).

Analyst is a “reasoning agent” within Microsoft 365 Copilot and Microsoft states that users with a Microsoft 365 Copilot license can use Analyst (with defined usage limits). Therefore, the Analyst agent requires the Microsoft 365 Copilot license.

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.

uses structured data and provides insights by using text, charts, tables, and other visuals.

The Analyst agent in Microsoft 365 Copilot is positioned as a “data analysis” reasoning agent that helps users work through structured information (for example, tables, spreadsheets, and other dataset-like inputs) and then produces analytical outputs. The best completion is the option stating it “uses structured data and provides insights by using text, charts, tables, and other visuals,” because that describes the hallmark outcome of analyst-style work: summarizing patterns, highlighting key drivers, and presenting results in formats that business users can act on. Analyst-style assistance typically includes exploring the data, identifying trends and anomalies, comparing segments, and explaining findings clearly—often accompanied by tables and visual representations that make the insights easier to consume.

The other dropdown options align to different use cases: “compiles background research for a new market or initiative” describes a research-oriented agent, “generate audio summaries” is a media summarization function, and “answer employee FAQs” describes a conversational knowledge assistant. Analyst is the one most directly associated with structured-data interpretation and producing a mix of narrative plus analytical artifacts (tables/charts) to communicate conclusions.

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.

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 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

Microsoft 365 Copilot helps users create and analyze content in Microsoft 365 apps. Answer: Yes

Microsoft Copilot Studio can only be used to customize Microsoft 365 Copilot. Answer: No

Microsoft Security Copilot uses AI to assign sensitivity labels to documents. Answer: No

Yes — Microsoft 365 Copilot is built into Microsoft 365 apps (such as Word, Excel, PowerPoint, Outlook, and Teams) to help users draft, summarize, rewrite, and analyze work content. This includes creating documents and presentations, summarizing emails and meetings, and analyzing information in productivity workflows. That is its primary value proposition, so the statement is true.

No — Copilot Studio is not limited to customizing Microsoft 365 Copilot. It is used to build and manage agents (conversational experiences) and extend Copilot experiences by connecting to data and actions, creating custom topics/behaviors, and integrating business processes. While it can be used to extend Microsoft 365 Copilot (for example, via declarative agents and other extensibility paths), it is broader than “only customizing Microsoft 365 Copilot,” so the statement is false.

No — Assigning sensitivity labels to documents is primarily a Microsoft Purview Information Protection capability (manual labeling, default labeling, auto-labeling) rather than a core function of Microsoft Security Copilot. Security Copilot is focused on security operations (incident investigation, threat hunting, response guidance). Although AI can support security workflows, the specific act of assigning sensitivity labels to documents is not what Security Copilot is designed to do by default, making the statement false.

Answer Area

Microsoft Foundry provides a unified platform for developers and data professionals to create custom end-to-end AI solutions. Answer: Yes

Microsoft Foundry provides a unified platform for low-code developers and business users to create custom end-to-end AI solutions. Answer: No

You need a Microsoft 365 Copilot license to access Microsoft Foundry services. Answer: No

Yes — Microsoft Foundry is positioned by Microsoft as a unified AI platform for building, deploying, and scaling AI apps and agents, with enterprise governance in a single environment. Microsoft explicitly describes Foundry as enabling developers (and, in broader descriptions, data professionals/enterprises) to build and operate AI solutions end-to-end, which aligns with the statement.

No — While Foundry can streamline AI development workflows and may include experiences that reduce complexity, the statement specifically targets low-code developers and business users creating custom end-to-end AI solutions. In Microsoft’s ecosystem, that “low-code/business-user” agent/app-building lane is more directly associated with tools like Copilot Studio/Power Platform, whereas Foundry is primarily presented as the platform for developers and technical teams building and governing AI solutions. Therefore, as written, the statement is not the best characterization.

No — Access to Microsoft Foundry services is not gated by a Microsoft 365 Copilot license. Foundry is part of the Azure AI platform experience (formerly Azure AI Studio) and is accessed through Azure, using Azure subscription-based service consumption. Microsoft 365 Copilot licensing is for Microsoft 365 Copilot experiences, not a prerequisite to use Foundry services.

guide AI strategy, ensure responsible AI oversight, and promote alignment across business units.

A trustworthy AI program requires more than technical implementation; it requires enterprise governance: clear ownership, risk management, policy, and cross-functional coordination. An AI governance council’s primary role is to provide strategic direction and oversight so AI initiatives align with business goals while meeting Responsible/Trustworthy AI expectations (fairness, reliability and safety, privacy and security, transparency, accountability, and inclusiveness).

Therefore, the best completion is that the council should guide AI strategy, ensure responsible AI oversight, and promote alignment across business units. This captures why councils are created: to avoid siloed deployments, define guardrails and approval processes, standardize evaluation/monitoring practices, and coordinate stakeholders such as legal, compliance, security, data governance, HR, and business leadership. The council also helps prioritize use cases, establish policies for data use and access, set documentation requirements, and require ongoing monitoring and incident response for AI systems in production.

The other options are narrower operational responsibilities. Configuring and deploying models in Azure is typically owned by engineering/cloud teams. Day-to-day model training and labeling is handled by data science/ML teams. The council sits above those activities to ensure the organization’s AI work is consistent, accountable, and strategically aligned.

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.

Answer Area

Microsoft 365 Copilot enables users to search across emails, files, chats, meetings, and connected apps, by using natural language queries. Answer: Yes

Microsoft 365 Copilot provides data protection, and helps ensure that user prompts and chat data are secure. Answer: Yes

Microsoft 365 Copilot is included in all Microsoft 365 subscriptions. Answer: No

Yes — Microsoft 365 Copilot is grounded in Microsoft 365 content through Microsoft Graph and is designed to help users find and summarize information across their work context (emails, files, chats, meetings). With extensions/connectors, Copilot can also incorporate information from connected apps, allowing users to query using natural language and get summarized, actionable outputs.

Yes — A key enterprise benefit of Microsoft 365 Copilot is that it operates within the Microsoft 365 security, identity, and compliance boundary. It respects existing permissions (users only get content they are authorized to access) and supports organizational controls intended to protect prompts and generated content. This is part of the business value compared to consumer tools: IT can apply policies, auditing, and compliance controls to reduce data risk.

No — Microsoft 365 Copilot is not automatically included in every Microsoft 365 subscription. In most business scenarios it is licensed as an add-on (or separate Copilot entitlement) for eligible Microsoft 365 plans, meaning it requires explicit licensing rather than being universally bundled with all subscriptions.

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.