A is incorrect: Information Barriers restrict communication and collaboration between specific groups of users within Microsoft 365, not AI application data access. DSPM for AI is the correct capability for gaining visibility into sensitive data shared with AI apps and enabling data security protection policies. Reference: https://learn.microsoft.com/en-us/purview/ai-microsoft-purview

B is incorrect: Microsoft Purview eDiscovery is designed for content search, legal hold, and investigation of communications including AI interactions, not for continuous endpoint scanning of configuration files. While eDiscovery can search AI prompts and responses for litigation, DSPM for AI is the recommended front door for AI data risk discovery. Reference: https://learn.microsoft.com/en-us/purview/dspm-for-ai

C is incorrect: The Microsoft Purview Unified Catalog is designed for data governance, helping organizations discover and manage data assets for analytics and AI projects. It does not provide visibility into sensitive data shared in AI interactions or offer one-click data security policies for monitoring AI usage patterns. Reference: https://learn.microsoft.com/en-us/purview/purview

D is correct: Microsoft Purview DSPM for AI provides a centralized dashboard to discover data security risks associated with AI usage, including sensitive information shared in user prompts and responses. It offers one-click policies for protection and compliance, personalized recommendations, and data risk assessments for oversharing detection. Reference: https://learn.microsoft.com/en-us/purview/ai-microsoft-purview

A is incorrect: Provisioning at constant peak throughput of 50,000 RU/s results in paying for full capacity continuously, even during off-peak hours when only 5,000 RU/s is needed. This wastes approximately 90% of provisioned capacity during low-traffic periods and significantly increases total cost of ownership compared to autoscale. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/how-pricing-works

B is incorrect: A serverless account can only run in a single Azure region, and it is not possible to add more regions after account creation. This constraint prevents meeting the requirement to serve users across three geographic regions. Additionally, serverless containers do not offer guarantees of predictable throughput or latency. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/serverless

C is incorrect: Serverless accounts are restricted to a single region each and do not support the automatic data replication and consistency guarantees of multi-region Cosmos DB accounts. This approach creates data silos requiring custom synchronization logic and cannot provide the guaranteed latency SLAs the scenario requires. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/serverless

D is correct: Autoscale provisioned throughput automatically and instantly scales capacity for variable workloads while maintaining SLAs. It supports multi-region distribution required for three geographic regions and scales between 10% of the configured maximum and the maximum RU/s, efficiently handling the 10x traffic variation described in the scenario. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/throughput-serverless

A is incorrect: Creating a separate resource adds unnecessary management overhead. Copilot Studio provides the designMode custom dimension specifically to distinguish test conversations from production traffic within a single resource. Reference: https://learn.microsoft.com/en-us/dynamics365/guidance/resources/copilot-studio-appinsights

B is correct: Copilot Studio agent telemetry data is stored in the customEvents table with activity-specific data in the customDimensions field. Filtering on the designMode dimension set to False excludes canvas test conversations from production analysis. Reference: https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-bot-framework-composer-capture-telemetry

C is incorrect: The Failures view analyzes failed HTTP requests and dependencies, but Copilot Studio agent events are logged as customEvents, not as standard HTTP requests. Filtering by HTTP codes would miss agent-specific telemetry entirely. Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/app/failures-performance-transactions

D is incorrect: Copilot Studio agent telemetry is stored in the customEvents table, not the requests table. Test conversations are identified by the designMode custom dimension rather than by user agent strings. Reference: https://learn.microsoft.com/en-us/dynamics365/guidance/resources/copilot-studio-appinsights

A is incorrect: Migrating data to SharePoint does not resolve the issue of cryptic column names and introduces unnecessary complexity to the architecture. Dataverse synonyms and glossary terms directly address the AI's interpretation challenges within the existing setup.

B is incorrect: Renaming columns directly modifies the underlying schema, which can disrupt existing applications, integrations, and customizations. The preferred method to clarify column content for AI is through synonyms, which avoid schema alteration.

C is incorrect: Simply adding more Dataverse tables does not help the agent comprehend the cryptic column names in the existing tables. The root issue is the AI's interpretation of current data, not a deficit in data volume. Synonyms and glossary terms directly target this interpretation problem.

D is correct: Adding synonyms helps the AI understand the meaning of cryptic column names, while glossary definitions clarify business-specific terminology. These enhancements provide essential grounding data that significantly improves the quality of the agent's generated responses.

A is incorrect: Setting k to 5 severely limits the semantic ranker to just 5 candidate documents, significantly reducing its ability to rerank effectively. While this improves raw query latency, the quality loss from under-serving the semantic ranker outweighs the latency benefit for agent grounding scenarios. Reference: https://learn.microsoft.com/en-us/azure/search/hybrid-search-how-to-query

B is incorrect: Setting k to 1 returns a single vector result, completely eliminating the benefit of semantic reranking. The semantic ranker requires multiple candidate documents to perform meaningful relevance comparison and reordering for accurate agent grounding. Reference: https://learn.microsoft.com/en-us/azure/search/hybrid-search-how-to-query

C is incorrect: The semantic ranker only processes the top 50 results regardless of how many are returned. Setting k to 1000 increases latency and resource consumption without improving semantic reranking quality, since the ranker caps its input at 50 documents. Reference: https://learn.microsoft.com/en-us/azure/search/semantic-search-overview

D is correct: The semantic ranker uses up to 50 matches as input. Microsoft documentation states that specifying less than 50 deprives the semantic ranking models of necessary inputs. Setting k to 50 ensures the semantic ranker has the full set of candidate documents to evaluate for relevance, producing the best reranking quality for agent consumption. Reference: https://learn.microsoft.com/en-us/azure/search/hybrid-search-how-to-query

A is incorrect: Activity log alerts monitor Azure resource management operations such as resource creation or modification, not application-level telemetry data. Copilot Studio content filter exceptions are logged in Application Insights custom events and require a log search alert with a KQL query. Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-types

B is correct: A log search alert rule evaluates a KQL query at a set frequency. Querying customEvents where customDimensions contains 'ContentFiltered' detects Responsible AI exceptions. The rule can be configured with a five-minute aggregation granularity and connected to an action group for team notification. Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-log-alert-rule

C is incorrect: Application Insights does not expose a built-in ContentFilteredCount metric for Copilot Studio agents. Responsible AI content filter events are logged as custom events with ContentFiltered in customDimensions, requiring a log search alert rule with a KQL query to detect them. Reference: https://learn.microsoft.com/en-us/microsoft-copilot-studio/troubleshoot-agent-response-filtered-by-responsible-ai

D is incorrect: Polling the Copilot Studio analytics dashboard via Power Automate is unreliable, not scalable, and cannot detect specific ContentFiltered exceptions. A log search alert rule with a KQL query provides native evaluation at set intervals with proper action group integration for notifications. Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/tutorial-log-alert

A is incorrect: Manual export and import does not preserve lineage or metadata, introduces human error, and is not scalable. Azure Machine Learning registries provide automated cross-workspace sharing with full traceability from training jobs to deployment endpoints. Reference: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-registries

B is incorrect: Exposing development endpoints to production traffic violates environment isolation principles and security policies. Production deployments should use separate workspaces with proper access controls, enabled through registry-based model promotion. Reference: https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-registries

C is correct: Azure Machine Learning registries act as central repositories that decouple models, components, and environments from individual workspaces. They support multiregion replication and enable model promotion from development to production across workspaces and regions while preserving lineage. Reference: https://learn.microsoft.com/en-us/azure/machine-learning/concept-machine-learning-registries-mlops

D is incorrect: Shared blob storage does not provide model versioning, metadata tracking, or lineage capabilities. Azure Machine Learning registries are purpose-built for cross-workspace model management with version control and organizational governance. Reference: https://learn.microsoft.com/en-us/azure/machine-learning/concept-machine-learning-registries-mlops

A is incorrect: Conflicting managed solution definitions do not cause solutions to enter a suspended state. Dataverse resolves conflicts automatically using 'last one wins' or merge logic depending on the component type, without requiring manual intervention from administrators. Reference: https://learn.microsoft.com/en-us/power-platform/alm/solution-layers-alm

B is incorrect: Dataverse does not merge all component types. Only model-driven app, form, and site map component types support merge behavior. Copilot Studio agent topics are non-merge components, so conflicting definitions follow 'last one wins' logic rather than being merged at the property level. Reference: https://learn.microsoft.com/en-us/power-platform/alm/how-managed-solutions-merged

C is incorrect: The first installed managed solution does not automatically retain priority. In Dataverse, subsequent managed solutions stack above earlier ones, and for non-merge components the most recently installed solution defines runtime behavior. The base layer only takes effect if upper layers are removed by uninstalling solutions. Reference: https://learn.microsoft.com/en-us/power-platform/alm/solution-layers-alm

D is correct: In Dataverse, when multiple managed solutions are installed, the last one installed is stacked above the previously installed solutions. For non-merge component types like Copilot Studio topics, the runtime behavior follows 'last one wins' resolution logic, meaning Solution B's definition takes precedence over Solution A's definition. Reference: https://learn.microsoft.com/en-us/power-platform/alm/solution-layers-alm

A is incorrect: Microsoft 365 Copilot licensing does not impose per-session API plugin call limits. Declarative agents can use multiple plugins simultaneously. The actual constraint is the sequential processing architecture that prevents complex multi-step iterative workflows from executing reliably. Reference: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/overview-declarative-agent

B is incorrect: Microsoft Graph throttling applies rate limits but does not block all calls after one response. The failure is due to declarative agents' sequential processing model that cannot support complex decision trees, iterative processing, or multiple conditional branches. Reference: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/overview-custom-engine-agent

C is correct: Declarative agents follow a sequential processing model where Microsoft manages orchestration. This architecture does not support chained operations with grounding data, looped operation plans, or routing to multiple language models. Complex multi-step workflows require a custom engine agent approach. Reference: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/declarative-agent-architecture

D is incorrect: While instruction length has practical limits, the failure to complete multi-step iterative workflows is caused by the architectural constraint of sequential processing, not instruction truncation. The agent simply cannot perform looped operations or multi-model routing by design. Reference: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/declarative-agent-architecture

A is incorrect: Azure Functions cannot directly query Unity Catalog tables via T-SQL, and this approach bypasses the native profiling infrastructure. Custom metrics in data profiling are computed alongside standard statistics and tracked in the same metric tables. Reference: https://learn.microsoft.com/en-us/azure/databricks/data-quality-monitoring/data-profiling/custom-metrics

B is incorrect: Power BI can visualize data quality but operates outside the Databricks profiling framework. Custom metrics defined within data profiling integrate with existing dashboards, alerts, and drift tracking without requiring an external reporting tool. Reference: https://learn.microsoft.com/en-us/azure/databricks/data-quality-monitoring/data-profiling/custom-metrics

C is correct: Azure Databricks data profiling supports custom metrics that extend built-in statistics. You define aggregate metrics using SQL expressions through the MonitorMetric API, and results are stored alongside standard metrics in the profile metrics table. Reference: https://learn.microsoft.com/en-us/azure/databricks/data-quality-monitoring/data-profiling/custom-metrics

D is incorrect: Manual CSV exports and spreadsheet calculations are not scalable, repeatable, or automated. Custom aggregate metrics defined through the MonitorMetric API are computed automatically on each profile refresh. Reference: https://learn.microsoft.com/en-us/azure/databricks/data-quality-monitoring/data-profiling/custom-metrics