AB-731 AI Transformation Leader Questions and Answers

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.

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

To use Microsoft 365 Copilot Chat, you must have a Microsoft 365 Copilot license. Answer: No

Microsoft 365 Copilot Chat provides context-aware assistance in Microsoft 365 apps. Answer: Yes

Microsoft 365 Copilot Chat can only access information in open files and read emails. Answer: No

No — Microsoft documents and pricing guidance indicate that Copilot Chat is available for eligible Microsoft Entra ID users with a qualifying Microsoft 365 subscription , and that capabilities can vary depending on whether users also have the Microsoft 365 Copilot add-on . In other words, Copilot Chat isn’t universally “Copilot-license required” in all cases; the add-on impacts which premium work features are enabled, but the baseline chat experience can be available without assigning the add-on to every user.

Yes — Microsoft describes Copilot Chat as a side-by-side experience in select Microsoft 365 apps (for example Word, Excel, PowerPoint, OneNote, Outlook) that is aware of the user’s open content , enabling context-aware help such as summarizing, drafting, and Q & A based on what the user is working on.

No — The word only makes this statement inaccurate. Copilot Chat can be grounded in more than just open files and emails (for example, it can also be grounded in the web, and—depending on licensing and configuration—can use agents/connectors for broader scoped tasks). So limiting it strictly to “open files and read emails” is too restrictive compared to how Microsoft positions the feature set.

The requirement is to analyze text and identify “people, locations, and companies” mentioned in news articles. This is a classic Named Entity Recognition (NER) / entity extraction scenario, which falls under natural language processing. Azure Language in Foundry Tools is the correct choice because it provides text analytics capabilities that detect and categorize entities in unstructured text—commonly including Person , Location , and Organization . This enables downstream experiences such as topic tagging, search filters (e.g., “all articles mentioning Company X”), trend dashboards (top people/places mentioned this week), and improved content discovery.

The other options do not match the requirement. Content Safety focuses on moderating harmful or policy-violating content (for example, hate, violence, self-harm, sexual content) and is not the primary tool for extracting named entities. Azure Vision is for analyzing images and performing OCR; it would only be relevant if the articles were images or scans, but the task here is entity extraction from text articles. Azure Speech is for speech-to-text, text-to-speech, and audio analysis; it would be used if your input were audio recordings rather than written articles.

Therefore, to identify key entities (people, locations, companies) from daily news article text, the best recommendation is Azure Language in Foundry Tools .

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.

Even when training data is already consistent and uniform, the first step in building a custom Azure Machine Learning model is still to prepare the training data. “Consistent” data reduces the amount of cleaning you may need, but preparation is broader than cleaning: you still must confirm the schema, validate data types, handle missing values (if any), ensure label quality (for supervised learning), select/engineer features, and split data into training/validation/test sets. Those actions determine whether training will be stable and whether evaluation metrics will be meaningful.

If you skip preparation and go directly to training (C), the model might learn from the wrong columns, inconsistent labels, or poorly partitioned data, producing misleading results. Evaluation (B) comes after training because you need a trained model to score and measure. Hyperparameter tuning (D) is an optimization activity that presupposes you already have a working training pipeline and a baseline model to improve. Deployment (E) is last, after you have validated performance and selected the model candidate.

Azure Machine Learning commonly operationalizes these steps through pipelines, where data preparation is a foundational stage that precedes training and evaluation (and can also be iterated as you refine features and quality).

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.

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.

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.

An AI governance council (often called an “AI Council”) exists primarily to set direction and provide cross-functional oversight so AI adoption stays aligned to the organization’s values, risk posture, and Responsible AI commitments. That maps most directly to D . Microsoft’s guidance on creating an AI Council describes leadership responsibilities such as defining and communicating the organization’s AI vision, values, and policies , reviewing and approving AI use cases/projects, and coordinating with enablement and technical readiness teams to understand risks, issues, and opportunities. It also emphasizes representation across distinct functions (for example: senior leadership, legal, compliance, risk, ethics, data, technology, business, HR) to ensure governance decisions reflect a broad, accountable perspective.

The other options describe activities that may be supporting outcomes of governance, but they are not the council’s primary purpose. A is narrow (IT policy enforcement/user monitoring) and is typically handled by security/compliance operations rather than the top-level governance body. B is user enablement/training (commonly owned by adoption/change management teams). C focuses on technical delivery and performance management (often owned by engineering/MLOps/service owners). The governance council’s central value is strategic guidance + oversight + cross-functional alignment to ensure Responsible AI adoption is consistent, accountable, and sustainable across the business.

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

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.

to create new content, such as text, images, or code.

Generative AI is defined by its ability to produce new outputs —content that did not previously exist in exactly that form—based on patterns learned from large datasets. That content can be text (emails, summaries, policies), images (design mockups, marketing visuals), code (snippets, scripts), audio, and more. Therefore, the correct completion is “to create new content, such as text, images, or code.”

The other options describe different AI categories. “Analyze trends and classify data sources” is primarily analytical/classification work, typically associated with traditional machine learning models (for example, clustering, categorization, fraud classification). “Make predictions based on historical data” is predictive AI (forecasting demand, predicting churn, estimating failure probability). While generative AI can assist those workflows by explaining results or drafting narratives, its primary purpose is not classification or forecasting—it is content synthesis.

In practical business value terms, this is why generative AI is commonly deployed for productivity tasks like drafting and rewriting content, summarizing long documents, generating customer communications, creating knowledge assistants, and producing structured outputs (tables, bullet lists, JSON) from unstructured prompts. The model’s differentiator is its ability to transform instructions and context into coherent, human-like content.

Answer Area

The marketing department at your company wants AI to summarize emails and create presentations. Answer: Use Microsoft 365 Copilot

The HR department at your company wants a conversational agent for policy questions and leave requests. Answer: Build with Microsoft Copilot Studio

The manufacturing department at your company wants AI to predict maintenance schedules. Answer: Build with Azure Machine Learning

The finance department at your company wants AI-powered access to enterprise resource planning ERP data by using familiar productivity tools. Answer: Extend with Microsoft 365 Copilot connectors

These scenarios map to four distinct solution patterns: out-of-the-box productivity assistance, low-code conversational agents, predictive ML, and enterprise data integration.

Marketing’s need to summarize emails and create presentations is a core “productivity copilot” use case. Microsoft 365 Copilot is embedded in Outlook, Word, PowerPoint, and Teams, so it directly supports summarization, drafting, and presentation generation without building a custom solution—making Use Microsoft 365 Copilot the best fit.

HR’s requirement is a conversational agent tailored to internal policies and workflows such as leave requests. That typically needs custom dialog, grounded knowledge sources, and possibly actions/workflows. Microsoft Copilot Studio is designed to build and manage such agents with organizational knowledge and business process integration, so Build with Microsoft Copilot Studio fits best.

Manufacturing’s predictive maintenance scheduling is classic predictive analytics: learning patterns from historical telemetry/maintenance data to forecast failures or optimal service windows. This is best addressed with Azure Machine Learning , which supports training, evaluating, and deploying custom predictive models.

Finance wants AI-powered access to ERP data “using familiar productivity tools,” which implies bringing external line-of-business data into the Microsoft 365 Copilot experience. That is precisely where Microsoft 365 Copilot connectors help—indexing and exposing enterprise data sources so Copilot can reference them in a governed way—so Extend with Microsoft 365 Copilot connectors is the best approach.

For a proof of concept , the key requirements are low commitment , quick start , and the ability to scale up or down as you learn what real usage looks like. Azure OpenAI Standard On-Demand pricing is designed for exactly that: you pay per token consumed (input and output) on a pay-as-you-go basis, which makes it ideal when demand is uncertain or variable—typical in early pilots and PoCs.

By contrast, Provisioned (PTUs) is best when you have well-defined, predictable throughput and latency requirements —usually a more mature, production workload. PTUs involve reserving model processing capacity to achieve consistent performance and more predictable costs, which is usually premature for a PoC where actual traffic patterns are not yet known.

Batch API is optimized for asynchronous high-volume jobs with a target turnaround (for example, up to 24 hours) and discounted pricing. That’s great for offline processing, but it does not match an interactive “agent” PoC that typically needs near-real-time responses and iterative testing.

Microsoft 365 Copilot is a separate SaaS licensing model and is not the Azure OpenAI pricing model for building your own agent solution.

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.

Generative AI’s defining characteristic is that it creates new content (text, images, code, summaries, drafts) in response to instructions—most commonly natural language prompts. Option C captures that general-purpose description in a stakeholder-friendly way: users provide prompts and the system generates responses or content. This framing is broad enough to cover common business value scenarios such as summarizing documents, drafting communications, creating marketing copy, generating reports, building assistants, and producing structured outputs from unstructured requests.

Option A is a single use case (translation), not the defining description. Option B describes predictive analytics/forecasting, which is a different AI category focused on outcomes and probabilities rather than content creation. Option D describes recommendation systems, typically driven by ranking/behavioral signals; while AI can enhance recommendations, that is not the core definition of generative AI. Therefore, the most accurate and relevant description for stakeholders is C.

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.

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.

Answer Area

Content filtering controls can prevent AI-generated responses from exposing confidential and sensitive information. Answer: Yes

AI-generated content can unintentionally reveal sensitive information if the generative AI model has access to unsecured data sources. Answer: Yes

To prevent data exposure, only the prompts used by users must be protected by using policies. Answer: No

Yes — Content filtering (and related safety controls) can help reduce the chance that responses contain policy-violating or sensitive outputs by detecting and blocking certain categories of content. While filtering is not a perfect guarantee, it is a recognized control to prevent or reduce exposure risk in outputs (for example, blocking regulated data patterns, disallowed content categories, or unsafe disclosures).

Yes — If a model (or the solution’s retrieval layer) can access poorly governed repositories—such as broadly shared folders, misconfigured SharePoint sites, or unsecured databases—then the system can surface sensitive information in responses even without malicious intent. This is why access control, data classification, and permission hygiene are critical prerequisites for deploying AI assistants grounded in organizational content.

No — Protecting only user prompts is insufficient. Data exposure can occur through multiple paths: retrieved documents, generated outputs, logs/telemetry, training/fine-tuning data, and connector/index configuration. Preventing exposure requires layered controls: data governance (labels, DLP, least privilege), secure connectors, output filtering, auditing, and user training—not prompt policy alone.