Microsoft 365 Admin Playbook: Real-World Scenarios for MS-102 Preparation

As a Microsoft 365 administrator, scenario-based questions test your ability to apply concepts in practical situations. This playbook breaks down common exam-style scenarios into actionable guidance. I’ve shuffled and renumbered them for variety.

Each includes the correct approach, why it matters, exact steps in current portals (as of late 2025), verification, pitfalls, and rollback.

Question 1: Configuring Attack Surface Reduction Rules to Block Potentially Obfuscated Scripts

Your Microsoft 365 E5 tenant has a Windows 10 device named Device1 onboarded to Microsoft Defender for Endpoint. Endpoint security policies appear in the table, with Policy3 (ATP Baseline) set to “Disable” for black execution of potentially obfuscated scripts.

Quick answer: The device applies only Policy1 and Policy2 settings; Policy3 does not apply due to lower precedence.

What this scenario is testing:
This tests understanding of policy precedence in Microsoft Intune endpoint security (Attack Surface Reduction profiles). ASR rules from different profiles can conflict. Intune resolves conflicts by applying the most secure setting, but profiles have priority order. Higher-priority profiles override lower ones for the same rule.

Step-by-step instructions:

1. Sign in to the Microsoft Intune admin center (intune.microsoft.com).
2. Navigate to Endpoint security > Attack surface reduction.
3. Select the existing ASR profile (or create a new one).
4. In the profile settings, locate Block execution of potentially obfuscated scripts.
5. Set it to Block (most secure option).
6. Assign the profile to the target device group.
7. If multiple profiles target the device, adjust priority: Select the profile > Properties > Priority > Move higher (lower number = higher priority).

Verification steps:

• On the device, open Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational.
• Look for event ID 1121 (block event) when testing an obfuscated script.
• In Intune, check Devices > select device > Device configuration to confirm applied profiles.

Common pitfalls:

• Forgetting that ASR profiles have explicit priority → Lower-priority profiles get ignored for conflicting rules.
• Testing in Audit mode first without switching to Block.
• Not excluding legitimate scripts (e.g., signed PowerShell).

Rollback:
Edit the profile and set the rule to Not configured or Audit, then reassign. Or delete the profile if temporary.

Question 2: Blocking Vulnerable Applications in Microsoft Defender for Endpoint

Company-owned Windows 11 devices onboard to Microsoft Defender for Endpoint. You need to block a vulnerable app until updated, and block executable based on file hash. Minimize administrative effort.

Quick answer: Select An allow or block file and A remediation request in Defender Vulnerability Management.

What this scenario is testing:
This evaluates knowledge of Microsoft Defender Vulnerability Management features for rapid risk mitigation. Blocking vulnerable versions reduces exposure while updates roll out.

Step-by-step instructions:

1. Sign in to the Microsoft 365 Defender portal (security.microsoft.com).
2. Go to Vulnerability management > Recommendations.
3. Select the recommendation for the vulnerable application.
4. Choose Request remediation > check Block vulnerable application (if available).
5. Submit the remediation request to Intune (or handle manually).
6. For hash-based blocking: In the recommendation flyout, note file hashes > go to Settings > Endpoints > Indicators > Add indicator > File hash > Block.

Verification steps:

• In Defender portal: Vulnerability management > Remediation > view blocked applications list.
• On a test device, attempt to run the vulnerable app → expect block notification.
• Check Indicators for auto-created file hash IOCs.

Common pitfalls:

• Missing the “Block” option (not supported for all apps).
• Forgetting to scope the block to specific device groups.
• Not monitoring remediation progress.

Rollback:
In Remediation > Blocked applications > unblock the app. Or delete the file hash indicators under Indicators.

Question 3: Deploying Windows Enterprise to Many Devices with Minimal Effort

You have 1000 computers running Windows 10 Pro, joined to Microsoft Entra ID. You purchase Microsoft 365 E5. You need to deploy Windows 10 Enterprise with minimal administrative effort.

Quick answer: From the Microsoft Intune admin center, create a Windows Autopilot deployment profile and assign it.

What this scenario is testing:
This assesses modern deployment strategies. Windows Autopilot enables zero-touch provisioning and edition upgrades via subscription activation, ideal for scale without imaging.

Step-by-step instructions:

1. Sign in to the Microsoft Intune admin center (intune.microsoft.com).
2. Go to Devices > Windows > Windows enrollment > Deployment Profiles > Create profile.
3. Configure settings (e.g., convert all targeted devices to Autopilot, user-driven mode).
4. Assign the profile to the device group containing the 1000 computers.
5. Instruct users to restart devices (subscription activation upgrades to Enterprise automatically).

Verification steps:

• On a device: Settings > Update & Security > Activation → confirm Windows 10 Enterprise.
• In Intune: Devices > check Autopilot deployment status.

Common pitfalls:

• Devices must be Entra joined and have M365 E3/E5 licenses for subscription activation.
• Not registering existing devices in Autopilot first (if needed).
• Confusing with full re-imaging.

Rollback:
No direct rollback needed (edition upgrade is one-way), but you can reset devices via Autopilot reset if issues arise.

Question 4: Minimum Conditional Access Policies for Complex Requirements

Microsoft 365 E5 subscription. Create Conditional Access policies meeting multiple requirements (e.g., MFA/compliant device/outside corporate network for all; block mobile sign-ins for one department; finance department only for App1; block outside certain countries for R&D).

Quick answer: Create 4 separate Conditional Access policies.

What this scenario is testing:
This tests Conditional Access design principles. One policy can’t handle unrelated conditions cleanly. Separate policies ensure granularity and avoid conflicts.

Step-by-step instructions:

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Navigate to Protection > Conditional Access > Policies > New policy.
3. Create individual policies for each distinct requirement (e.g., one for all users requiring MFA/compliance, one blocking mobile for specific group, etc.).
4. Target specific cloud apps, users/groups, conditions, and grant/block controls.

Verification steps:

• Use What If tool in Conditional Access to simulate sign-ins.
• Check sign-in logs in Entra ID for applied policies.

Common pitfalls:

• Overloading one policy with OR conditions → leads to unintended blocks.
• Forgetting exclusions (e.g., break-glass accounts).
• Not enabling in Report-only mode first.

Rollback:
Disable or delete the policies. Use Report-only mode during testing to minimize impact.

Question 5: Identifying Least Privileged Admin Roles

Microsoft 365 subscription with Entra ID tenant (contoso.com). Users table shows roles (e.g., Exchange Administrator, User Administrator, Global Administrator, None).

You need to identify which two users can perform two management tasks (e.g., reset passwords, add users).

Quick answer: The users with User Administrator and Global Administrator roles (or equivalent least privileged).

What this scenario is testing:
This examines role-based access control (RBAC) and least privilege in Microsoft Entra ID. Different built-in roles grant specific permissions.

Step-by-step instructions:

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Identity > Roles & admins > Roles and administrators.
3. Review assigned roles for users.
4. Reference Microsoft’s “Least privileged roles by task” documentation to confirm capabilities.

Verification steps:

• Attempt tasks as the users (or use What If in PIM).
• Check audit logs for successful actions.

Common pitfalls:

• Assuming Global Administrator is always needed → over-privileging.
• Missing that some tasks require multiple roles.

Rollback:
Remove excess role assignments via Roles & admins > select assignment > Remove.

Question 6: Enabling Sensitivity Labels for Microsoft 365 Groups

Microsoft 365 E5 tenant needs sensitivity labels support enabled for Microsoft 365 groups (and optionally SharePoint Online).

Quick answer: Enable sensitivity labels for containers via PowerShell.

What this scenario is testing:
This tests governance features for groups/sites using sensitivity labels from Microsoft Purview, replacing classic classifications.

Step-by-step instructions:

1. Create/publish sensitivity labels in the Microsoft Purview compliance portal (compliance.microsoft.com) with scope Groups & sites.
2. Connect to Security & Compliance PowerShell.
3. Run: Execute-AzureAdLabelSync (after enabling via Graph if needed).
4. For initial enablement (if required): Use Microsoft Graph PowerShell to set the tenant flag.

Verification steps:

• Create a new Microsoft 365 group → see sensitivity label picker.
• Existing groups: Labels appear after sync (up to 24 hours).

Common pitfalls:

• Forgetting to scope labels to Groups & sites.
• Not running label sync.

Rollback:
Disable via PowerShell or migrate back to classic classifications (not recommended).

Wrap-Up: Mastering Scenario-Based Questions

Scenario questions reward those who think like admins: prioritize least effort, most secure options, and least privilege. Always ask: What portal? What feature minimizes effort? What conflicts arise?

Practice in a lab tenant. Review official docs for portal paths—they evolve, but core concepts stay consistent.