Free Practice Questions for the Microsoft 365 Certified: Microsoft 365 and AI Services Administrator Associate AB-650 Exam (2026 Updated)

Microsoft Agent 365 provides centralized governance settings in the Microsoft 365 admin center to control who can interact with AI agents and who can distribute agents throughout the organization.

First selection: User access.

The User access setting determines which users or security groups are permitted to access and interact with agents.

Administrators can navigate to Microsoft 365 admin center → Agents → Settings → User access.

Under the access configuration, administrators should select Specific users or groups and assign Group1.

This restricts agent interaction to members of Group1 and prevents users outside the approved group from accessing agents through the governed experience.

Second selection: Sharing.

The Sharing setting determines which users can distribute agents created through Microsoft Copilot Agent Builder.

Administrators should navigate to Agents → Settings → Sharing, select Specific users or groups, and assign Group2.

This permits members of Group2 to distribute agents organization-wide while preventing other users from using organization-wide sharing.

The remaining settings serve different purposes. Agent Management Rules automate governance actions, Allowed agent types controls permitted publisher categories, and Policy template provides predefined governance configurations.

Therefore, User access controls agent interaction, while Sharing controls organization-wide distribution.

The Microsoft 365 Copilot usage report provides organizational insights into how licensed users adopt and interact with Microsoft 365 Copilot across supported Microsoft 365 applications.

Option C is correct because the report is specifically designed to measure Copilot adoption, engagement, and utilization among enabled users.

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

The report provides metrics such as enabled users, active users, active-user rates, and adoption trends across Microsoft 365 workloads, including Word, Excel, PowerPoint, Outlook, and Teams.

It also provides historical trend views that management can use to evaluate whether licensed employees are adopting Copilot over time.

Option A is incorrect because the Copilot Chat usage report focuses on conversational activity in Copilot Chat rather than providing the broader licensed Copilot adoption reporting requested.

Option B is incorrect because Copilot credits reporting focuses on usage-based consumption and associated billing rather than adoption patterns among licensed users.

Option D is incorrect because the Microsoft 365 apps usage report measures application activity more generally, rather than Copilot-specific adoption.

Therefore, the Microsoft 365 Copilot usage report provides the appropriate management evidence.

Microsoft References:

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

Ensure that User1 can invite the contoso.com users to Teams: Assign the Guest Inviter role to User1.; Ensure that only the contoso.com users can be invited as guests to the Microsoft Entra tenant: From the External collaboration settings, edit the Collaboration restrictions settings.

Microsoft Entra External ID provides separate administrative controls for guest invitation permissions and permitted external collaboration domains.

First selection: Assign the Guest Inviter role to User1.

The tenant currently permits guest invitations only from users assigned specific administrative roles. Assigning the Guest Inviter role allows User1 to invite external collaborators without granting broader privileges such as Global Administrator or User Administrator.

This satisfies the principle of least privilege because User1 receives the permission necessary to perform guest invitations without unnecessary administrative authority.

Second selection: Edit the Collaboration restrictions settings.

Microsoft Entra External collaboration settings provide domain-based controls for external invitations. To restrict guest invitations to contoso.com, administrators must configure Collaboration restrictions to allow invitations only to specified domains and add contoso.com to the permitted domain list.

This prevents invitations to users from other external domains while allowing authorized inviters, including User1, to invite users from contoso.com.

Cross-tenant outbound access settings do not provide the required tenant-wide invitation domain allowlist. Guest user access restrictions control what existing guests can see in the directory rather than which domains can be invited.

Both configurations are necessary to satisfy the stated requirements.

Microsoft References:

https://learn.microsoft.com/en-us/entra/external-id/external-collaboration-settings-configure

https://learn.microsoft.com/en-us/entra/external-id/allow-deny-list

Microsoft 365 provides Message Center and Service Health notification mechanisms for communicating organizational service changes and operational issues.

First selection: Message Center Preferences. The Microsoft 365 Message Center publishes information about important product changes, feature releases, service updates, and administrative actions. Administrators can configure email preferences to receive notifications about major updates. This directly meets Group1 ' s requirement.

Second selection: Service Health alerts. Service Health supports email notifications for incidents and advisories affecting Microsoft 365 services. Administrators can configure notifications for selected services and designate recipient email addresses. This is the likely intended selection for Group2 if maintenance events means operational service disruptions or advisories.

Microsoft documentation qualification: Planned maintenance is treated differently. Microsoft ' s current documentation explicitly states that planned maintenance announcements appear in Message Center rather than the Service Health dashboard. Therefore, if Group2 requires notifications specifically about planned maintenance, Message Center is the appropriate source, and the proposed Service Health selection does not completely meet that requirement.

The distinction is important when implementing the configuration. Major product updates and planned maintenance communications belong to Message Center; active incidents and service advisories belong to Service Health.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/admin/manage/message-center

https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health

Microsoft 365 Copilot relies on secure WebSocket (WSS) connections to support real-time, bidirectional communication between client applications and Microsoft cloud services.

Option A is correct because the reported Network connectivity insight specifically identifies WebSocket connection failures for hosts within *.cloud.microsoft.

Microsoft documentation explains that this insight occurs when a network device or web proxy prevents successful WebSocket connections. Administrators should configure the affected proxy to permit WebSocket protocol connections, including the HTTP-to-WebSocket upgrade process, for the required Microsoft 365 endpoints.

Because the problem affects only Branch1, the configuration should be applied to the Branch1 web proxy policy. This resolves the connectivity issue without changing policies for other offices.

Option B is incorrect because the reported failure concerns WebSocket connectivity, not DNS resolution or regional endpoint selection.

Option C is incorrect as the best answer because TLS inspection can interfere with WebSocket connections, but the scenario does not establish that TLS inspection is the cause. Exempting endpoints from TLS inspection may be appropriate after further diagnosis, but allowing the required WebSocket protocol directly addresses Microsoft ' s reported insight.

Option D is incorrect because standard HTTPS connectivity already succeeds. Allowing HTTPS alone does not guarantee successful WebSocket protocol upgrades.

Therefore, the Branch1 proxy must allow WSS connections to the required Microsoft 365 hosts.

Microsoft References:

Microsoft 365 Network Insights .

Review Microsoft 365 network connection failures and WebSocket errors .

Report: Explorer (Threat Explorer); View on the Email entity page: Timeline

Microsoft Defender for Office 365 provides Threat Explorer for investigating malicious and suspicious email messages. The Email entity page supplies detailed information about individual messages, including their delivery and post-delivery events.

First selection: Explorer (Threat Explorer).

Threat Explorer enables security analysts to search for email messages using properties such as subject, sender, recipient, detection technology, and delivery status.

The analyst can open Threat Explorer in the Microsoft Defender portal, select the relevant email view, and filter messages by the subject provided in the phishing report. Matching messages can then be examined individually.

Second selection: Timeline.

After identifying the suspicious message, the administrator can open its Email entity page and select the Timeline view.

The Timeline view displays the chronological history of message delivery and subsequent actions. It includes original delivery events, changes caused by Zero-hour Auto Purge (ZAP), quarantine actions, and other recorded message events.

This information enables the administrator to determine where the message was originally delivered and what actions occurred afterward.

Threat Explorer is therefore the correct investigation tool for locating messages by subject, while the Timeline view provides the required delivery and post-delivery history.

Microsoft References:

https://learn.microsoft.com/en-us/defender-office-365/threat-explorer-real-time-detections-about

https://learn.microsoft.com/en-us/defender-office-365/mdo-email-entity-page

Microsoft Purview Endpoint Data Loss Prevention (Endpoint DLP) protects sensitive information on managed endpoint devices. To make endpoint-specific rule actions available when configuring advanced DLP rules, the policy must include the Devices location.

Endpoint DLP enables organizations to monitor and restrict how users interact with sensitive information on supported Windows and macOS devices. Its policy actions can control activities such as copying sensitive files to USB storage, printing documents, transferring files through network shares, and uploading information through supported applications or browsers.

When administrators select Devices as the DLP policy location, the relevant endpoint-specific conditions and actions become available for rule configuration.

Option A, Instances, relates to connected cloud application instances and does not activate endpoint DLP rule actions.

Option B, On-premises repositories, applies to information protection scenarios involving on-premises data repositories rather than endpoint activity controls.

Option D, OneDrive accounts, enables DLP protection for files stored in OneDrive for Business but does not provide the endpoint-specific controls required by the question.

Therefore, DLP1 must be applied to the Devices location to expose and configure endpoint rule actions.

Microsoft References:

https://learn.microsoft.com/en-us/purview/endpoint-dlp-create-policy-device-scoping

Microsoft Entra ID supports passwordless authentication through several technologies, including Microsoft Authenticator, Windows Hello for Business, and FIDO2 security keys.

First selection: Microsoft Authenticator.

Microsoft Authenticator supports passwordless phone sign-in using device-based cryptographic authentication. Instead of entering a password, users approve authentication requests through the mobile application, complete number matching, and verify their identity using a device PIN or biometric authentication.

Email OTP, SMS, and voice calls do not provide the same Microsoft Entra passwordless phone sign-in capability.

Second selection: Microsoft Entra admin center.

The Microsoft Entra admin center provides centralized configuration of authentication methods through Entra ID → Authentication methods → Policies.

An administrator with at least the Authentication Policy Administrator role can select Microsoft Authenticator, enable it for all users, and configure the authentication mode to support passwordless sign-in.

The Microsoft 365 admin center primarily manages Microsoft 365 services, users, subscriptions, and licensing. The Microsoft Defender portal focuses on security monitoring and threat protection. Neither is the dedicated administrative interface for configuring Microsoft Entra authentication methods.

Implementation consideration: Enabling the authentication method does not automatically register every user. Users must register Microsoft Authenticator and activate passwordless phone sign-in before using it. Administrators can use Temporary Access Pass to support onboarding.

Therefore, Microsoft Authenticator and the Microsoft Entra admin center are the correct selections.

Microsoft SharePoint Restricted Access Control (RAC) provides an additional authorization boundary for SharePoint sites. It restricts site and content access to members of designated Microsoft Entra security groups or Microsoft 365 groups while preserving existing SharePoint permissions.

Option C is correct because configuring Restricted Access Control for Site1 and specifying Group1 satisfies both conditions simultaneously. Users must belong to Group1 and already possess appropriate SharePoint permissions. Membership in Group1 alone does not grant access.

Users outside Group1 are denied access even if they have direct permissions or previously received sharing links. Restricted Access Control can be configured for an individual communication site without modifying its existing permission assignments.

Option A is incorrect because sharing restrictions primarily control sharing operations rather than comprehensively enforcing the existing-content access boundary required.

Option B is incorrect because Restricted Content Discovery limits content visibility in organization-wide search and Microsoft 365 Copilot but does not prevent users with existing permissions from directly accessing files.

Option D is incorrect because manually changing SharePoint permissions could achieve access restrictions but would violate the requirement to preserve existing permissions and minimize administrative effort.

Therefore, configuring Restricted Access Control specifically for Site1 is the appropriate solution.

Microsoft Reference: Microsoft Learn — Restrict SharePoint site access .

Microsoft 365 Agent Registry provides centralized visibility into agents available within an organization. Administrators can filter the inventory using properties such as publisher type, deployment channel, platform, and status.

Option D is correct because the requirements identify two independent filtering conditions: external publisher ownership and availability within Microsoft Teams.

The Publisher type: Third party filter identifies agents developed and distributed by external organizations rather than Microsoft or the organization ' s internal developers.

The Channel: Teams filter identifies agents deployed to Microsoft Teams, where authorized users can discover and interact with them.

Applying both filters restricts the resulting inventory to third-party agents associated with the Teams channel.

Administrators can export the filtered agent list from the Microsoft 365 admin center for auditing. The export includes relevant metadata such as the agent name, channel, publisher, publisher type, platform, and status.

Option A is incorrect because Microsoft 365 apps is not the same deployment channel as Teams.

Option B is incorrect because Your users identifies internally created or shared agents rather than third-party publishers.

Option C is incorrect because Your org identifies agents published by the organization.

Therefore, Teams and Third party are the required filter values.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry

Microsoft Entra Conditional Access evaluates resource assignments, client application conditions, and access controls when users authenticate to Microsoft 365.

Statement 1: Yes.

CA2 blocks Exchange ActiveSync and other legacy authentication clients accessing Exchange Online. Switching to Microsoft Outlook with modern authentication avoids the client-app condition targeted by CA2. However, CA1 still requires User2 to complete MFA before access is granted.

Statement 2: Yes.

CA1 targets all resources and all client applications, requiring MFA. Therefore, User1 must satisfy multifactor authentication when accessing Microsoft Teams through Microsoft Edge, unless the requirement has already been satisfied by the authentication session.

Statement 3: No.

CA3 targets SharePoint Online and requires devices to be marked compliant. Switching from Google Chrome to Microsoft Edge does not change the device ' s underlying compliance status.

Although Microsoft Edge supports device-based Conditional Access and can provide device identity information, switching browsers alone does not guarantee access. If the device is noncompliant, CA3 continues to deny access regardless of the browser.

Therefore, the intended answers are Yes, Yes, No.

Technical qualification: The exhibit does not identify User3 ' s device compliance status. If the device is compliant but Chrome cannot transmit its device identity correctly, Edge might resolve the failure. Thus, the final No should be interpreted as not guaranteed by switching browsers alone.

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