Troubleshooting practice questions

An administrator needs to open a Microsoft 365 support request because all users are experiencing intermittent service outages for Exchange Online. Before contacting support, which two pieces of information should the administrator have ready to ensure efficient troubleshooting? (Choose two.)

Trap 1: Number of affected users

The number of affected users is a business-impact metric that support may factor into severity or SLA response times, but it is not required to open a ticket. During initial triage, the engineer can proceed with the Tenant ID and a detailed problem description, then ask for the user count if needed. Specifically, this number can be updated later via an incident change request, so it should never block submission of the support request.

Trap 2: Network bandwidth graph from the past 24 hours

A network bandwidth graph is a specialized diagnostic artifact that support will explicitly request only after initial checks point to connectivity, jitter, or throughput as a root-cause candidate. Prematurely attaching it can mislead triage, because most M365 issues are due to identity or service-side states rather than local bandwidth. It is also not a standard field in the Microsoft 365 admin center support request form, so supplying it provides no benefit to the initial routing.

A
Tenant ID (or Microsoft 365 tenant domain name)
Tenant ID (or the Microsoft 365 tenant domain name such as contoso.onmicrosoft.com) is the primary key Microsoft Support uses to locate your specific tenancy in their backend systems. It lets support immediately verify service health, tenant-level configurations, and any recent changes or incidents affecting that environment. Without this identifier, they cannot authenticate the tenant context, route the request correctly, or correlate your issue with backend telemetry.
B
Number of affected users
Why it fails: The number of affected users is a business-impact metric that support may factor into severity or SLA response times, but it is not required to open a ticket. During initial triage, the engineer can proceed with the Tenant ID and a detailed problem description, then ask for the user count if needed. Specifically, this number can be updated later via an incident change request, so it should never block submission of the support request.
C
Detailed description of the problem and troubleshooting steps attempted
A well-written problem description with the exact error text, affected workload, timestamps, and any troubleshooting already performed (e.g., reboot, channel repair, Microsoft Remote Connectivity Analyzer results) is a mandatory-quality element for effective support. It primes the engineer with a hypothesis and lets them determine whether the issue belongs to Exchange Online, Teams, SharePoint, or a client misconfiguration. This specificity prevents generic loops and is one of the strongest accelerators to first-response resolution.
D
Network bandwidth graph from the past 24 hours
Why it fails: A network bandwidth graph is a specialized diagnostic artifact that support will explicitly request only after initial checks point to connectivity, jitter, or throughput as a root-cause candidate. Prematurely attaching it can mislead triage, because most M365 issues are due to identity or service-side states rather than local bandwidth. It is also not a standard field in the Microsoft 365 admin center support request form, so supplying it provides no benefit to the initial routing.

Question 2hardmultiple choice

You are troubleshooting why a user cannot access a SharePoint Online site. The user is assigned a Conditional Access policy that requires compliant device, and the device is enrolled in Microsoft Intune but shows as non-compliant. What is the most likely cause?

Trap 1: The device is not enrolled in Microsoft Intune

The device is actually enrolled in Microsoft Intune; enrollment is not the cause of the access block. Conditional Access evaluates the device's compliance state after enrollment, and the compliance policy flagged the device as non-compliant due to missing security updates. If the device were unenrolled, the Conditional Access policy would still block, but for a different reason—lack of a managed identity—whereas here the Intune management record exists and shows non-compliance.

Trap 2: The Conditional Access policy is not applied to SharePoint Online

The Conditional Access policy does target SharePoint Online; the cloud apps assignment includes it, so the policy is evaluated during the access request. The access attempt is blocked because the grant control 'Require device to be marked as compliant' fails, not because the policy is scoped away. If the policy did not include SharePoint Online, no block would occur, but this scenario specifies that the policy applies to the service in question.

Trap 3: The user does not have an Intune license

The user must have an Intune license because the device is enrolled and its compliance status is being evaluated—enrollment requires an Intune license assigned to the user. The block is not due to missing licensing; it is the device's non-compliant state from missing security updates that fails the Conditional Access grant control. Licensing issues would typically prevent enrollment or policy assignment, not trigger a specific compliance-based access denial after enrollment.

A
The device is non-compliant due to missing security updates
The device is non-compliant because Microsoft Intune compliance policies evaluate security update installation as a required health condition. Missing security updates cause the compliance state to become 'non-compliant', which triggers the Conditional Access policy's 'Require device to be marked as compliant' grant control and blocks access to SharePoint Online. The user's license and the policy's application scope are irrelevant because the failure is specifically the device's compliance state.
B
The device is not enrolled in Microsoft Intune
Why it fails: The device is actually enrolled in Microsoft Intune; enrollment is not the cause of the access block. Conditional Access evaluates the device's compliance state after enrollment, and the compliance policy flagged the device as non-compliant due to missing security updates. If the device were unenrolled, the Conditional Access policy would still block, but for a different reason—lack of a managed identity—whereas here the Intune management record exists and shows non-compliance.
C
The Conditional Access policy is not applied to SharePoint Online
Why it fails: The Conditional Access policy does target SharePoint Online; the cloud apps assignment includes it, so the policy is evaluated during the access request. The access attempt is blocked because the grant control 'Require device to be marked as compliant' fails, not because the policy is scoped away. If the policy did not include SharePoint Online, no block would occur, but this scenario specifies that the policy applies to the service in question.
D
The user does not have an Intune license
Why it fails: The user must have an Intune license because the device is enrolled and its compliance status is being evaluated—enrollment requires an Intune license assigned to the user. The block is not due to missing licensing; it is the device's non-compliant state from missing security updates that fails the Conditional Access grant control. Licensing issues would typically prevent enrollment or policy assignment, not trigger a specific compliance-based access denial after enrollment.

Question 3hardmultiple choice

A company uses dynamic groups based on department attribute. A user moved from Sales to Marketing but the group membership did not update after 48 hours. What should the admin do first?

Trap 1: Delete and recreate the group

Deleting and recreating the group is unnecessarily destructive and does not address the root cause. The group's object ID, Microsoft Entra ID role assignments, license assignments, and access packages tied to that group would be lost, and the newly created group would still rely on the same asynchronous dynamic membership evaluation. If the original group failed to evaluate the department attribute correctly, a clean copy will likely exhibit the same delay unless a manual reprocessing is performed.

Trap 2: Run a PowerShell script to update membership

PowerShell cannot be used to manually add or remove members from a mail-enabled security group or Microsoft 365 group that is governed by a dynamic membership rule. The Set-AzureADGroup and Add-AzureADGroupMember cmdlets fail or throw a DirectoryObjectNotFound/NotSupported error because membership is owned and calculated by the Microsoft Entra ID rule engine, not by client-side scripts. There is no supported PowerShell cmdlet that forces a dynamic group evaluation; that capability is available only through the manual Refresh action in the portal or the corresponding Graph API operation.

Trap 3: Wait another 24 hours

The default dynamic membership evaluation process can take up to 48 hours in large tenants because Microsoft Entra ID batching and incremental processing depend on many factors. Waiting another 24 hours might happen to coincide with the next evaluation cycle, but it is not a deterministic troubleshooting step and does not force a recalculation when an attribute change was missed or the membership hasn't been processed. An administrator can use the manual Refresh option to trigger immediate processing and verify whether the department attribute is actually synchronized to Entra ID.

A
Delete and recreate the group
Why it fails: Deleting and recreating the group is unnecessarily destructive and does not address the root cause. The group's object ID, Microsoft Entra ID role assignments, license assignments, and access packages tied to that group would be lost, and the newly created group would still rely on the same asynchronous dynamic membership evaluation. If the original group failed to evaluate the department attribute correctly, a clean copy will likely exhibit the same delay unless a manual reprocessing is performed.
B
Run a PowerShell script to update membership
Why it fails: PowerShell cannot be used to manually add or remove members from a mail-enabled security group or Microsoft 365 group that is governed by a dynamic membership rule. The Set-AzureADGroup and Add-AzureADGroupMember cmdlets fail or throw a DirectoryObjectNotFound/NotSupported error because membership is owned and calculated by the Microsoft Entra ID rule engine, not by client-side scripts. There is no supported PowerShell cmdlet that forces a dynamic group evaluation; that capability is available only through the manual Refresh action in the portal or the corresponding Graph API operation.
C
Wait another 24 hours
Why it fails: The default dynamic membership evaluation process can take up to 48 hours in large tenants because Microsoft Entra ID batching and incremental processing depend on many factors. Waiting another 24 hours might happen to coincide with the next evaluation cycle, but it is not a deterministic troubleshooting step and does not force a recalculation when an attribute change was missed or the membership hasn't been processed. An administrator can use the manual Refresh option to trigger immediate processing and verify whether the department attribute is actually synchronized to Entra ID.
D
Manually refresh the dynamic group in Microsoft Entra ID
In the Microsoft Entra admin center, navigate to Groups, open the specific dynamic group, and select the Manual Refresh (or Reprocess) action from the Dynamic membership rules pane to immediately trigger recalculation. This operation forces Microsoft Entra ID to re-run the membership query against current user attribute values, including the department field, and to add or remove members accordingly. This is the supported way to resolve stale dynamic group membership without recreating the group or using unsupported PowerShell commands.

Question 4easymultiple choice

A company has a hybrid identity setup. A new employee is created in on-premises AD but does not appear in Azure AD after sync. What should the admin check first?

Trap 1: Organizational unit filtering

Organizational unit filtering restricts which on-premises Active Directory containers are synchronized to Microsoft Entra ID. If the new employee's account resides in an OU that is deselected in Microsoft Entra Connect's OU filter, the object will never be provisioned, regardless of other settings. However, this scenario is just one possible sync misconfiguration; the immediate diagnostic step is to verify the overall sync status to see whether the last synchronization cycle completed and whether any errors occurred.

Trap 2: DNS configuration

DNS configuration is unrelated to user object provisioning in a hybrid identity environment. DNS records are used for name resolution of federated services such as Active Directory Federation Services, but they do not influence whether Microsoft Entra Connect creates or updates cloud user accounts. Even with incorrect DNS, the synchronization service can still connect to Exchange Online or Microsoft Entra ID via the standard endpoints, so DNS errors would not prevent a new employee from appearing.

Trap 3: License assignment

License assignment controls access to Microsoft 365 workloads but has no effect on whether a user object is synchronized to Microsoft Entra ID. A synced user exists in the cloud directory even without a license; licensing only enables services like Exchange Online or Teams. Therefore, the absence of a license might explain why the employee cannot sign in to a specific service, but it does not explain why the account is missing entirely from the Microsoft Entra ID user list.

A
Organizational unit filtering
Why it fails: Organizational unit filtering restricts which on-premises Active Directory containers are synchronized to Microsoft Entra ID. If the new employee's account resides in an OU that is deselected in Microsoft Entra Connect's OU filter, the object will never be provisioned, regardless of other settings. However, this scenario is just one possible sync misconfiguration; the immediate diagnostic step is to verify the overall sync status to see whether the last synchronization cycle completed and whether any errors occurred.
B
DNS configuration
Why it fails: DNS configuration is unrelated to user object provisioning in a hybrid identity environment. DNS records are used for name resolution of federated services such as Active Directory Federation Services, but they do not influence whether Microsoft Entra Connect creates or updates cloud user accounts. Even with incorrect DNS, the synchronization service can still connect to Exchange Online or Microsoft Entra ID via the standard endpoints, so DNS errors would not prevent a new employee from appearing.
C
License assignment
Why it fails: License assignment controls access to Microsoft 365 workloads but has no effect on whether a user object is synchronized to Microsoft Entra ID. A synced user exists in the cloud directory even without a license; licensing only enables services like Exchange Online or Teams. Therefore, the absence of a license might explain why the employee cannot sign in to a specific service, but it does not explain why the account is missing entirely from the Microsoft Entra ID user list.
D
Microsoft Entra Connect synchronization status
Microsoft Entra Connect synchronization status is the primary suspect when a newly created on-premises user does not appear in Microsoft 365. The synchronization service runs on a recurring schedule; if the last delta sync failed, the scheduler is paused, or the service itself is stopped, the new user will not be replicated to Microsoft Entra ID. Verifying the sync cycle, checking the event logs for errors, and forcing a delta sync are the correct initial troubleshooting steps before examining any other configuration.

Question 5hardmultiple choice

You are troubleshooting an issue where users from a partner organization cannot access a shared app in your Microsoft Entra ID tenant. The partner uses Microsoft Entra ID with a custom domain. You have configured cross-tenant access settings. Which setting is most likely misconfigured?

Trap 1: Outbound cross-tenant access settings for the partner's tenant ID

Outbound cross-tenant access settings for the partner's tenant ID govern what your organization's users can access in the partner tenant (e.g., MFA or device-compliance requirements imposed on your users when they authenticate to partner apps). They do not control whether partner users can sign in to your applications, so examining them cannot reveal why inbound partner access is failing.

Trap 2: The app's user assignment and provisioning configuration

While the app's user assignment and provisioning configuration can affect which users appear in the app or whether accounts are synced, cross-tenant access settings are evaluated first at the Microsoft Entra ID tenant boundary for an external identity. Even if the partner user is assigned to the app, a blocked default inbound cross-tenant access policy will reject the authentication before app-level assignment is considered.

Trap 3: The partner's inbound cross-tenant access settings for your tenant

The partner's inbound cross-tenant access settings for your tenant define the policies your users must satisfy when they access resources in the partner tenant—for example, whether the partner trusts your MFA claims. The issue involves partner users attempting to access your apps, so the relevant configuration is your inbound settings for the partner tenant, not the partner's inbound settings for your tenant.

A
Outbound cross-tenant access settings for the partner's tenant ID
Why it fails: Outbound cross-tenant access settings for the partner's tenant ID govern what your organization's users can access in the partner tenant (e.g., MFA or device-compliance requirements imposed on your users when they authenticate to partner apps). They do not control whether partner users can sign in to your applications, so examining them cannot reveal why inbound partner access is failing.
B
The app's user assignment and provisioning configuration
Why it fails: While the app's user assignment and provisioning configuration can affect which users appear in the app or whether accounts are synced, cross-tenant access settings are evaluated first at the Microsoft Entra ID tenant boundary for an external identity. Even if the partner user is assigned to the app, a blocked default inbound cross-tenant access policy will reject the authentication before app-level assignment is considered.
C
Default inbound cross-tenant access settings for the partner's tenant ID
Default inbound cross-tenant access settings for the partner's tenant ID are the correct place to check because these settings determine whether external partner users are allowed to authenticate into your tenant and access your applications. Microsoft Entra ID evaluates cross-tenant access policies individually for each external tenant, and the default inbound policy applies unless a tenant-specific override exists, so a block here would prevent partner users from signing in.
D
The partner's inbound cross-tenant access settings for your tenant
Why it fails: The partner's inbound cross-tenant access settings for your tenant define the policies your users must satisfy when they access resources in the partner tenant—for example, whether the partner trusts your MFA claims. The issue involves partner users attempting to access your apps, so the relevant configuration is your inbound settings for the partner tenant, not the partner's inbound settings for your tenant.

Question 6mediummultiple choice

Your organization uses Microsoft Defender for Endpoint. A user reports that their device is not receiving security updates. You need to ensure that the device is properly onboarded to Defender for Endpoint. Which log should you check first?

Trap 1: Event Viewer Application logs

The Event Viewer Application log records errors and warnings from installed applications (e.g., .NET, SQL Server) but does not capture the MDE sensor's onboarding or update process. Defender for Endpoint writes its diagnostic information to dedicated client log files under C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Logs, not to the Application event log. While some MDE-related errors might surface in Event Viewer, the log lacks the detailed onboarding state and telemetry needed for troubleshooting.

Trap 2: System logs

The System event log tracks kernel-level events such as boot/shutdown, service control manager messages, and driver failures. MDE onboarding is an application-layer registration that does not emit its operational detail to the System log; the sensor's own logging captures the actual onboarding and update activity. Thus, the System log only shows that the Defender service may have started or stopped, but not the onboarding credential validation or sensor health.

Trap 3: Windows Update logs

Windows Update logs (e.g., WindowsUpdate.log or the Get-WindowsUpdateLog output) capture the installation of operating system updates and Microsoft Update components, but Defender for Endpoint's anti-malware definitions are delivered through a separate update channel. The MDE sensor does not rely on Windows Update for its onboarding or daily signature updates, so any Defender-related update failures will not appear in the Windows Update log. Consulting these logs would lead to a dead end because they contain no MDE-specific telemetry.

A
Event Viewer Application logs
Why it fails: The Event Viewer Application log records errors and warnings from installed applications (e.g., .NET, SQL Server) but does not capture the MDE sensor's onboarding or update process. Defender for Endpoint writes its diagnostic information to dedicated client log files under C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Logs, not to the Application event log. While some MDE-related errors might surface in Event Viewer, the log lacks the detailed onboarding state and telemetry needed for troubleshooting.
B
System logs
Why it fails: The System event log tracks kernel-level events such as boot/shutdown, service control manager messages, and driver failures. MDE onboarding is an application-layer registration that does not emit its operational detail to the System log; the sensor's own logging captures the actual onboarding and update activity. Thus, the System log only shows that the Defender service may have started or stopped, but not the onboarding credential validation or sensor health.
C
Microsoft Defender for Endpoint client logs
The Microsoft Defender for Endpoint client logs are the authoritative source for troubleshooting onboarding and update issues. These logs, located in C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Logs, include files like MicrosoftDefenderATPOnboarding.log and MicrosoftDefenderATPUpdate.log that record sensor registration, machine ID assignment, and signature update failures. If an onboarding attempt is failing, the client log will contain the specific error code and allow verification of the correct log collection.
D
Windows Update logs
Why it fails: Windows Update logs (e.g., WindowsUpdate.log or the Get-WindowsUpdateLog output) capture the installation of operating system updates and Microsoft Update components, but Defender for Endpoint's anti-malware definitions are delivered through a separate update channel. The MDE sensor does not rely on Windows Update for its onboarding or daily signature updates, so any Defender-related update failures will not appear in the Windows Update log. Consulting these logs would lead to a dead end because they contain no MDE-specific telemetry.

Question 7mediummultiple choice

Your organization uses Microsoft Entra ID. You want to enforce Multi-Factor Authentication (MFA) for all users. You have already configured Conditional Access policies. However, some users are still able to sign in without MFA. What should you check first?

Trap 1: Ensure all users have registered for MFA.

MFA registration only establishes that a user has a registered authentication method; it does not determine whether a Conditional Access policy applies to them. A user can be fully registered for MFA and still be unaffected if the policy's user assignment doesn't include them. Therefore, ensuring registration is a necessary but insufficient step for enforcing MFA across the organization.

Trap 2: Verify that the Conditional Access policy is enabled.

Checking whether the policy is enabled is a basic status check, but an enabled policy still enforces only for the users and groups defined in its assignments. If the policy is active yet users aren't being prompted for MFA, the cause is almost always the assignment scope, not the enabled flag. Thus, verifying enabled status alone will not resolve the issue.

Trap 3: Check if there are any exclusions configured.

Exclusions in a Conditional Access policy intentionally exempt specific users, but the scenario given does not indicate any exclusions exist. Even if exclusions were present, the policy still needs the intended users to be included in the assignment. So checking exclusions is a secondary step, not the root cause in the described situation.

A
Ensure all users have registered for MFA.
Why it fails: MFA registration only establishes that a user has a registered authentication method; it does not determine whether a Conditional Access policy applies to them. A user can be fully registered for MFA and still be unaffected if the policy's user assignment doesn't include them. Therefore, ensuring registration is a necessary but insufficient step for enforcing MFA across the organization.
B
Verify that the Conditional Access policy is enabled.
Why it fails: Checking whether the policy is enabled is a basic status check, but an enabled policy still enforces only for the users and groups defined in its assignments. If the policy is active yet users aren't being prompted for MFA, the cause is almost always the assignment scope, not the enabled flag. Thus, verifying enabled status alone will not resolve the issue.
C
Confirm that all users are included in the policy's user assignment.
The user assignment is the principal scope control in a Conditional Access policy. For MFA to apply to every user, the policy's 'Include' list must target 'All users' or a group containing all users. If some users are omitted, they will bypass the policy entirely regardless of other settings. Confirming this assignment is the critical diagnostic step.
D
Check if there are any exclusions configured.
Why it fails: Exclusions in a Conditional Access policy intentionally exempt specific users, but the scenario given does not indicate any exclusions exist. Even if exclusions were present, the policy still needs the intended users to be included in the assignment. So checking exclusions is a secondary step, not the root cause in the described situation.