Free Microsoft AB-650 Practice Exam with Questions & Answers

Microsoft Entra Conditional Access integrates with Microsoft Entra ID Protection to evaluate risky authentication attempts and enforce additional security requirements based on detected sign-in risk.

The Contoso technical requirement states that Group3 users accessing Microsoft 365 resources from anonymous IP addresses must complete multifactor authentication (MFA).

First selection: Sign-in risk.

Microsoft Entra ID Protection recognizes sign-ins from anonymous IP addresses, including anonymous VPNs and Tor exit nodes, as potential security risks.

Administrators can configure the Sign-in risk condition in CAPolicy1 to evaluate authentication attempts based on their calculated risk level. Microsoft recommends considering medium and high sign-in risk for MFA enforcement, depending on the organization ' s security requirements.

Second selection: Grant.

The Grant access control determines which authentication requirements must be satisfied before access is permitted.

Administrators should select Grant access and configure the built-in Multifactor authentication strength, or the corresponding Require multifactor authentication control where available.

Because CAPolicy1 already targets Group3 and all resources, these selections apply risk-based MFA requirements to the intended users and Microsoft 365 resources.

Technical qualification: Sign-in risk policies operate on calculated risk levels, not exclusively on anonymous IP addresses. Consequently, they may also trigger for other risky sign-ins and cannot guarantee that every anonymous-IP connection is challenged.

Microsoft Entra administrative units support dynamic device membership based on device attributes. AU1 uses the following membership rule:

(device.deviceTrustType -eq " Workplace " ) -and

(device.deviceOSType -in [ " Windows " , " Android " ])

Statement 1: No.

Admin1 holds the Global Administrator role. However, AU1 uses dynamic membership, which prevents administrators from manually adding or removing members. Membership is determined exclusively by the configured rule.

Additionally, Device1 is Microsoft Entra joined, corresponding to deviceTrustType = AzureAD, rather than Workplace. Therefore, Device1 does not satisfy the rule.

Statement 2: Yes.

Device2 runs Windows 11 and is Microsoft Entra registered.

Microsoft Entra registered devices have a deviceTrustType value of Workplace, and Windows matches the permitted operating system list. Therefore, Device2 satisfies both conditions and is automatically included in AU1.

Statement 3: Yes.

The planned Android devices must be Microsoft Entra registered. Registered Android devices satisfy the Workplace trust condition and, when their recorded operating system value is Android, also satisfy the OS condition.

Consequently, they are automatically added to AU1 through dynamic membership processing. Group1 membership itself does not determine AU1 membership.

Administrators should verify the actual deviceOSType value because some Android Enterprise registrations use more specific operating system identifiers.

Microsoft References:

Manage dynamic membership in administrative units .

Microsoft Entra dynamic membership rules and device attributes .

Microsoft Purview Data Loss Prevention (DLP) provides controls to prevent Microsoft 365 Copilot from processing sensitive organizational content when generating responses.

Option D is correct because the Contoso technical requirement explicitly states that Microsoft 365 Copilot responses must not use content from project documents stored on SharePoint Site1.

Microsoft Purview supports a dedicated Microsoft 365 Copilot and Copilot Chat DLP policy location. Administrators can configure a DLP rule using the Content contains → Sensitivity labels condition and the Prevent Copilot from processing content action.

This prevents Copilot from processing files with the specified sensitivity labels or incorporating their contents into generated responses, even when users have SharePoint permissions.

For Contoso, the project documents can be identified using their distinctive project-code format, PR-123456789, and classified with an appropriate sensitivity label. The DLP policy can then exclude those labeled documents from Copilot processing.

Option A is incorrect as a complete solution because sensitivity labels and auto-labeling policies classify and protect documents but do not independently enforce the required Copilot processing restriction.

Option B is incorrect because Insider Risk Management detects potentially risky user activities.

Option C is incorrect because Information Barriers restrict communication and collaboration between designated user segments.

Technical consideration: The DLP policy requires an appropriate sensitivity label to be applied to the project documents. DLP rules for Copilot cannot directly exclude stored files merely by matching their project-code pattern.

Therefore, a DLP policy is the required enforcement mechanism.

Microsoft Purview Information Protection provides data classification, sensitivity labeling, and protection capabilities for organizational information. However, Information Protection alone does not provide the dedicated investigation workflow required to identify individual AI agent interactions containing confidential information in prompts or responses.

The more appropriate solution is Microsoft Purview Data Security Posture Management (DSPM), using its AI observability and Activity explorer capabilities.

Microsoft DSPM supports visibility into AI agent activities, including Microsoft Agent 365. It can identify interactions involving sensitive information through integrated data classification, audit telemetry, sensitive information types, and trainable classifiers.

Administrators can navigate to the Microsoft Purview portal, open DSPM, and use Discover → Activity explorer → AI activities to investigate AI interactions. The AI observability page also provides agent-specific visibility into potentially sensitive interactions and associated risks.

Microsoft Purview Information Protection contributes classification and labeling capabilities to this process, but simply using Information Protection does not independently deliver the required agent-interaction investigation.

Therefore, the proposed solution does not fully satisfy the requirement, making Option B (No) the appropriate answer.

Microsoft References:

https://learn.microsoft.com/en-us/purview/ai-agent-365

https://learn.microsoft.com/en-us/purview/data-security-posture-management-learn-about

Microsoft Defender for Office 365 Plan 2 provides Automated Investigation and Response (AIR) capabilities to investigate malicious email messages and recommend or execute remediation actions.

Option D is correct because Microsoft explicitly identifies Soft delete as the only available remediation action when configuring automatic remediation for AIR message clusters.

By default, AIR remediation actions require approval from the Security Operations (SecOps) team. However, administrators can enable automatic remediation for selected message cluster types, allowing malicious messages to be remediated without manual approval.

Administrators can configure this feature in the Microsoft Defender portal by navigating to Settings → Email & collaboration → MDO automation settings.

The Message clusters section supports three categories:

Similar files

Similar URLs

Multiple similar attributes

Under Remediation action, administrators select Soft delete. AIR then automatically removes qualifying malicious messages from user mailboxes without requiring SecOps approval.

Soft deletion moves messages into the Recoverable Items structure, allowing recovery according to applicable mailbox retention settings.

Option A moves messages to Deleted Items, while Option B moves them to Junk Email. Neither is supported as the configurable automatic AIR remediation action.

Option C permanently removes messages and is not supported for this automatic remediation configuration.

Microsoft also specifies that clusters containing more than 10,000 messages require manual review rather than automatic remediation.

Therefore, Soft delete is the only correct option.

Microsoft Entra pass-through authentication (PTA) enables users to authenticate to Microsoft 365 using their existing on-premises Active Directory credentials while ensuring that password validation occurs against the on-premises Active Directory environment.

With pass-through authentication, Microsoft Entra ID receives the cloud sign-in request and communicates with a pass-through authentication agent installed on an on-premises, domain-joined Windows Server.

The agent validates the submitted credentials against Active Directory Domain Services and returns the authentication result to Microsoft Entra ID.

This approach allows organizations to maintain password validation against their existing domain controllers while providing users with access to Microsoft 365 cloud services.

Option B is incorrect because Microsoft Entra seamless single sign-on reduces authentication prompts for domain-joined users but does not independently determine where password validation occurs.

Option C is incorrect because certificate-based authentication uses X.509 certificates rather than authenticating users through their existing domain passwords.

Option D is incorrect because password hash synchronization enables Microsoft Entra ID to validate passwords in the cloud using synchronized password hashes. It does not satisfy the requirement that password authentication occur against the on-premises domain.

Pass-through authentication therefore meets both requirements.

Microsoft References:

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta

The Microsoft 365 Copilot Agent usage report provides centralized reporting on the adoption and activity of agents used through Microsoft 365 Copilot Chat and supported Microsoft 365 applications.

Option B is correct because the report supports usage analysis over the previous 7 or 30 days and provides agent-specific activity information.

Administrators can access the report through the Microsoft 365 admin center by navigating to Reports, Usage, Microsoft 365 Copilot, and Agents.

The report includes information about active agents, active users, agent responses, and usage trends. Its daily time-series reporting helps administrators examine usage patterns, while agent-level details support comparisons between Agent1 and Agent2.

Option A is incorrect because Microsoft Defender for Cloud Apps app governance primarily focuses on application permissions, OAuth applications, and associated security risks rather than Copilot agent activity reporting.

Option C is incorrect because billing and usage information primarily addresses consumption and associated charges rather than providing the complete agent adoption and activity reporting requested.

Option D is incorrect because Microsoft Purview Audit provides event-level audit records. Although relevant activities may be recorded, it is not the most direct reporting solution for comparing agent usage.

Therefore, the Microsoft 365 Copilot Agent usage report is the appropriate selection.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-agents-new

Scope: RG1; Analysis settings: Cost analysis

Microsoft Cost Management provides cost analysis capabilities for tracking Azure consumption, comparing billing periods, and identifying services responsible for changes in expenditure.

First selection: RG1.

The Copilot pay-as-you-go billing policy BP1 is associated with resource group RG1. Microsoft 365 Copilot usage charges are billed through the connected Azure subscription and resource group.

Selecting RG1 isolates the relevant charges from unrelated Azure resources, including the virtual machines located in RG2.

Although BP1 is the Microsoft 365 billing policy, it is not itself a standard Azure Cost Management scope. Therefore, RG1 is the correct selection.

Second selection: Cost analysis.

Cost analysis enables administrators to review actual consumption charges over selected time periods, including calendar months.

To investigate month-over-month differences, administrators can compare the current and previous billing months, configure monthly granularity, and group costs by service name, meter, or another supported dimension.

Grouping expenses by meter or service helps identify the usage categories responsible for the largest increases or decreases.

Budgets establish spending thresholds and notifications, while Cost alerts surface configured alerts. Neither provides the required detailed comparison and cost breakdown.

Therefore, RG1 and Cost analysis satisfy the two requirements.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/copilot/pay-as-you-go/setup

https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/customize-cost-analysis-views

Administrative unit members: The Branch1 users and Group1; Role to assign to Helpdesk1: User Administrator

Microsoft Entra administrative units enable organizations to delegate administrative permissions to specific subsets of directory objects, avoiding tenant-wide administrative assignments.

First selection: The Branch1 users and Group1.

The administrative unit must contain both the individual Branch1 user objects and the Group1 security group.

Including Branch1 users enables delegated administrators to manage those users within the administrative unit ' s scope. Including Group1 enables administrators to manage the group ' s properties and membership.

Microsoft specifically distinguishes between adding a security group and adding its members to an administrative unit. Adding Group1 does not automatically add its users. Therefore, selecting Group1 alone would not satisfy the password-reset requirement.

Second selection: User Administrator.

The User Administrator role provides permissions to manage supported user properties, reset passwords for eligible nonprivileged users, and manage group memberships.

When assigned at the administrative-unit scope, the role restricts its administrative operations to the applicable objects within that unit.

The Helpdesk Administrator role supports password-related helpdesk tasks but does not grant the broader group membership management capability required.

The Groups Administrator role focuses on group management without the necessary user password-reset capability.

Privileged Role Administrator provides excessive permissions for the scenario.

Therefore, the administrative unit must contain the Branch1 users and Group1, with Helpdesk1 assigned the scoped User Administrator role.

Microsoft References:

https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/administrative-units

https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-members-add

Group1: The Microsoft 365 Copilot usage report; Group2: The Microsoft 365 Copilot Chat usage report

Microsoft 365 provides separate reporting capabilities for licensed Copilot functionality and the broadly available Copilot Chat experience.

First selection: Microsoft 365 Copilot usage report.

Group1 contains users assigned Microsoft 365 Copilot licenses who interact with Copilot across Microsoft 365 applications and agents.

The Microsoft 365 Copilot usage report provides adoption and engagement information about these licensed experiences.

It includes enabled users, active users, usage by application, user activity information, and supported prompt-count metrics.

Administrators can use this report to evaluate whether licensed employees are actively using Copilot capabilities.

Second selection: Microsoft 365 Copilot Chat usage report.

Group2 users do not have Microsoft 365 Copilot licenses but use the Copilot Chat experience available through Microsoft 365.

The Copilot Chat usage report tracks conversational AI adoption, including active users, total prompts submitted, average prompts per user, and individual activity trends.

This makes it the appropriate report for measuring engagement among users who rely on Copilot Chat without the paid Copilot license.

The Microsoft 365 apps usage report measures general application usage, while the Copilot readiness report focuses on eligibility and deployment preparation.

Therefore, the licensed group requires the Copilot usage report, while the unlicensed group requires the Copilot Chat usage report.

Reporting clarification: Microsoft ' s current report documentation describes standard 7-, 28-, 90-, and 180-day periods. The video specifies 30 days, but the latest reporting interface may use a 28-day period instead.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage

https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-copilot-usage