AB-650 Administering Microsoft 365 and AI Services Question and Answers

Top navigation bar logo and website link: An organization theme in Microsoft 365; Default sign-in page background: Company branding in Microsoft Entra

Microsoft 365 provides different branding mechanisms for the application interface and the Microsoft Entra authentication experience. Each requirement must be configured through the appropriate administrative service.

First selection: An organization theme in Microsoft 365.

An organization theme controls the appearance of the Microsoft 365 top navigation bar. Administrators can configure the default organizational theme, upload a company logo, and specify the URL that opens when users select the logo.

These options are managed through the Microsoft 365 admin center under Organization profile and organization themes.

Second selection: Company branding in Microsoft Entra.

Microsoft Entra company branding controls the appearance of authentication pages. It supports customizing sign-in page background images, logos, headers, colors, and other visual elements.

Configuring the default company branding ensures the background image is available to users authenticating through the organization ' s branded sign-in experience.

An application-specific branding theme would not satisfy the requirement for a default experience across all users. Similarly, a Microsoft 365 group theme applies to selected Microsoft 365 groups rather than the organization ' s default interface.

Therefore, organization themes and Microsoft Entra company branding are the two appropriate selections.

Microsoft References:

https://learn.microsoft.com/en-GB/microsoft-365/admin/setup/customize-your-organization-theme

https://learn.microsoft.com/en-us/entra/fundamentals/how-to-customize-branding

First dropdown: Get-MgGroupMember; Second dropdown: Update-MgUser; Third dropdown: -UserId

Microsoft Graph PowerShell provides cmdlets for managing Microsoft Entra groups and modifying user account attributes. This task requires retrieving members of an existing group and updating the EmployeeType property for each user.

First selection: Get-MgGroupMember. This cmdlet retrieves direct members of the specified Microsoft Entra group. The -GroupId parameter identifies the Contractors group using its unique identifier.

Second selection: Update-MgUser. This cmdlet updates Microsoft Entra user properties through Microsoft Graph. It supports the -EmployeeType parameter, which can be used to assign the value Part-time.

Third selection: -UserId. This parameter identifies the specific user object to modify. The foreach statement processes each returned member and applies the corresponding update.

Technical accuracy note: The video uses $person.ObjectId. Current Microsoft Graph PowerShell documentation normally exposes the member identifier as $person.Id. Additionally, the -All switch should be specified when retrieval of every group member is required across result pages.

A production-oriented implementation would therefore use the following structure, assuming the group contains user objects:

$members = Get-MgGroupMember -GroupId " < GroupId > " -All

foreach ($person in $members) { Update-MgUser -UserId $person.Id -EmployeeType " Part-time " }

The three dropdown answers remain correct; this implementation note distinguishes the original examination script from current Microsoft Graph behavior.

Microsoft References:

https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.groups/get-mggroupmember

https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users/update-mguser

First dropdown: Connect-MgGraph; Second dropdown: Get-MgSubscribedSku; Third dropdown: Set-MgUserLicense

Microsoft Graph PowerShell provides commands for connecting to Microsoft Graph, retrieving subscribed license products, and assigning licenses with individual service plans disabled.

First selection: Connect-MgGraph. This command establishes an authenticated Microsoft Graph PowerShell session using delegated permissions. Appropriate licensing administration permissions must be available to the signed-in administrator.

Second selection: Get-MgSubscribedSku. This command retrieves the subscribed licensing SKUs and their associated service plans. The required product is identified through its SKU part number, and its service plans can be examined to locate Microsoft Bookings.

Third selection: Set-MgUserLicense. This cmdlet assigns or removes licenses for a specified user. Administrators can use the -AddLicenses parameter to provide a license configuration containing the intended SKU identifier and disabled service-plan identifiers.

Important technical corrections: The original exhibit filters on EnterprisePack, which identifies Office 365 E3, whereas Microsoft 365 E3 ordinarily uses SPE_E3. The exhibited script also uses Select -ExcludeProperty ServicePlanID; to build a valid disabled-plan identifier collection, Microsoft documents Select -ExpandProperty ServicePlanId.

The three dropdown choices are correct, but these additional corrections are required if the script is to assign Microsoft 365 E3 and disable Bookings reliably in production.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/enterprise/assign-licenses-to-user-accounts-with-microsoft-365-powershell

Microsoft Entra Privileged Identity Management (PIM) provides just-in-time access to privileged administrator roles. It allows organizations to control when administrative privileges become active and enforce approval and authentication requirements.

First selection: Eligible assignment.

An eligible assignment requires engineers to explicitly activate the User Administrator role before receiving its administrative permissions.

Unlike an active assignment, which grants privileges immediately, an eligible assignment enables temporary privilege elevation only when required.

Permanent active and time-bound active assignments do not satisfy the mandatory activation requirement because their privileges are available throughout the assignment ' s active period.

Second selection: Require approval and multifactor authentication (MFA).

PIM role settings support requiring both MFA and designated approver authorization during role activation.

Administrators can configure these settings in Microsoft Entra admin center → ID Governance → Privileged Identity Management → Microsoft Entra roles → Roles → User Administrator → Role settings.

Enable the MFA requirement, select Require approval to activate, and designate the appropriate approver.

When an engineer requests activation, PIM evaluates the authentication requirements and routes the request for approval. The role becomes active only after the applicable requirements are satisfied and approval is granted.

Technical consideration: PIM can recognize MFA already completed during the current authentication session. Consequently, a fresh MFA prompt is not guaranteed for every activation.

Review the: Microsoft 365 Copilot credits report; Notify the department by: Adding a budget and alert recipients to the billing policy

Microsoft 365 provides consumption reports and billing policy controls for organizations using pay-as-you-go Microsoft Copilot services.

First selection: Microsoft 365 Copilot credits report.

The Microsoft Copilot Credits report provides detailed information about consumption associated with metered Copilot Chat and agent interactions.

Administrators can access the report through the Microsoft 365 admin center under Reports, Usage, Microsoft Copilot, and Credits.

The report includes credits consumed by individual users, agents, billing policies, and user-agent combinations. These breakdowns help identify unusually high consumption and determine which activities are contributing to increased costs.

Second selection: Adding a budget and alert recipients to the billing policy.

Microsoft 365 pay-as-you-go billing policies support configurable budgets and spending notifications.

Administrators can specify a budget threshold and designate finance personnel as notification recipients. When consumption reaches the configured notification milestones, Microsoft sends email alerts to the designated recipients.

This provides proactive cost visibility without requiring finance personnel to manually inspect consumption reports.

A critical distinction is that billing policy budgets provide notifications rather than hard spending limits. Reaching the budget threshold does not necessarily stop additional consumption or billing.

Therefore, the Credits report provides the consumption breakdown, while the billing policy budget and notification recipients provide threshold-based alerts.

Microsoft References:

https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/message-consumption

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

Microsoft Purview Data Loss Prevention (DLP) policies protect sensitive information across Microsoft 365 workloads, including Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Teams.

Option B is correct because the policy currently blocks sensitive files in SharePoint but does not prevent credit card information from being shared through email. This strongly indicates that the policy ' s locations do not include Exchange Online, or that Exchange Online is excluded from its scope.

Administrators must configure the DLP policy to include both Exchange email and SharePoint sites. The policy should identify the Credit Card Number sensitive information type and apply appropriate blocking actions to external sharing.

Option A is incorrect because user overrides determine whether users can bypass a DLP restriction. They do not enable protection for additional workloads.

Option C is incorrect because the policy already enforces restrictions in SharePoint, demonstrating that it is functioning for at least one location.

Option D is incorrect because the policy already detects credit card information in SharePoint. Changing the detection conditions alone does not extend enforcement to Exchange Online.

After adding Exchange Online, administrators should verify that the policy ' s rules block the relevant outbound email activity and that users cannot override the restriction.

Therefore, configuring the DLP policy locations is the appropriate solution.

Microsoft Reference: Microsoft Learn — Data Loss Prevention policy reference .

The Microsoft 365 admin center provides dedicated features for reporting service disruptions and requesting technical assistance. The correct selection depends on whether the administrator is reporting an operational service issue or seeking guidance from Microsoft Support.

First selection: Service health.

The Service health dashboard enables administrators to monitor incidents, service degradation, outages, and advisories affecting Microsoft 365 workloads, including Exchange Online, Microsoft Teams, and SharePoint Online.

Administrators can navigate to Health → Service health. If they experience a problem that Microsoft has not reported, they can select Report an issue and submit information about the affected service. Microsoft evaluates these reports and may publish an incident or advisory when a service-side problem is confirmed.

Second selection: New service request.

The New service request feature allows administrators to request assistance from Microsoft Support, including guidance about creating and configuring Microsoft Entra user accounts.

Administrators can navigate to Support → New service request, describe their question, review suggested troubleshooting information, and contact Microsoft Support when additional assistance is required.

Message center publishes service announcements and planned changes, while Product feedback collects suggestions and feedback about Microsoft products. Neither is the most appropriate option for the stated requirements.

Therefore, Service health and New service request are the correct selections.

Microsoft References:

Microsoft Learn — How to check Microsoft 365 service health .

Microsoft Learn — Get support for Microsoft 365 for business .

First target (Set-Mailbox): -GrantSendOnBehalfTo; Second target (Add-MailboxPermission): -AccessRights FullAccess

Exchange Online shared mailboxes support collaborative mailbox access through delegated permissions. The requirements involve two separate capabilities: modifying mailbox contents and sending messages while retaining sender identification.

First selection: -GrantSendOnBehalfTo.

This parameter grants Send on Behalf permissions. When a member of Group1 sends an email using Mailbox1, recipients can identify the individual sender because the message indicates that it was sent on behalf of the shared mailbox.

This differs from Send As permission, where the email appears to originate directly from the shared mailbox without identifying the delegate.

Second selection: -AccessRights FullAccess.

The Add-MailboxPermission cmdlet grants mailbox access permissions. Specifying FullAccess allows authorized group members to open Mailbox1 and create, read, modify, and delete mailbox items.

Full Access alone does not grant permission to send email from the mailbox. The separate Send on Behalf permission is therefore necessary.

The -AcceptMessagesOnlyFrom parameter restricts inbound senders, while -ForwardingAddress configures forwarding. Neither provides the requested delegated capabilities.

Together, Send on Behalf and Full Access meet the two functional requirements.

Microsoft References:

https://learn.microsoft.com/en-us/exchange/collaboration/shared-mailboxes/create-shared-mailboxes

List the AI app and agent inventory: AI observability; Review interactions: Activity explorer; Identify SharePoint exposure concerns: Data risk assessments

Microsoft Purview Data Security Posture Management (DSPM) combines AI activity visibility, sensitive-data investigations, and exposure assessments within a centralized data security framework.

First selection: AI observability. This capability provides an inventory of AI applications and agents, including their activity, risk characteristics, and sensitive interactions. Administrators can identify recently used agents and investigate potentially risky AI applications.

Second selection: Activity explorer. DSPM Activity explorer enables administrators to investigate events associated with sensitive information. Its AI activities view provides visibility into AI interactions, prompts and responses where supported, sensitive information detections, and data loss prevention policy matches. This makes it suitable for examining whether confidential SharePoint information was involved in an AI interaction.

Third selection: Data risk assessments. This capability identifies potential data exposure and oversharing risks. Administrators can assess sensitive content and investigate SharePoint locations where excessive access permissions or sharing configurations may expose information.

The remaining options perform different functions. Posture provides an overall data security dashboard, Remediation actions supports implementing security controls, and Reports provides summarized security information.

Consequently, AI observability, Activity explorer, and Data risk assessments are the correct selections for the three investigation requirements.

Microsoft References:

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

Modify the password protection policy: User1 only; Invite an external user: User1, User2, User3, and User4

Microsoft Entra ID uses role-based access control (RBAC) to authorize administrative operations. The two activities in this question have different permission requirements.

First selection: User1 only.

Modifying the tenant-wide password protection policy requires privileged authorization. The Global Administrator role held by User1 includes the permissions required to configure Microsoft Entra Password Protection, including the custom banned-password list and smart lockout settings.

The Authentication Policy Administrator role can also manage these settings, but none of the other listed users holds that role. User2 ' s Security Administrator role does not provide this specific permission, while User4 ' s Password Administrator role concerns password administration rather than configuration of the tenant-wide password protection policy.

Second selection: User1, User2, User3, and User4.

Microsoft Entra external collaboration settings allow users to invite external guests. Under the default configuration, organizational users can invite external users, including users without administrative roles.

User1 can invite guests as a Global Administrator, and User2 also has the Guest Inviter role. User3 and User4 can invite external users under the default invitation settings.

Therefore, all four users qualify for the second activity.

Microsoft References:

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

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

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