MS-102 Admin Playbook: 4 Real-World Microsoft 365 Scenarios (with Click-by-Click Fixes)

Scenario questions are rarely about memorizing a single setting. They test whether you can pick the right control plane, apply least privilege, and prove the change worked. Below are four common scenarios rewritten into an admin-ready playbook.

---

Question 1: Azure AD Connect Sync Scope (Including Disabled Users)

1) Quick answer (one line)

By default, groups and both enabled and disabled user objects within synced scope will synchronize to Microsoft Entra ID.

2) What this scenario is testing

This tests whether you understand what Azure AD Connect synchronizes by default. A common misconception is that disabled on-premises accounts do not sync. In practice, disabled accounts often still sync because the object may be required for Microsoft 365 workloads (for example, shared resources), and sync is governed primarily by sync scope and filtering, not “enabled vs disabled” status.

3) Step-by-step instructions (click-by-click)

Goal: Confirm which objects are in sync scope and validate they appear in Microsoft Entra ID.

1. On the Azure AD Connect server, open Azure AD Connect.
2. Select Configure.
3. Choose Customize synchronization options.
4. Sign in with an account that can read directory configuration.
5. On Domain and OU filtering, confirm the OU(s) containing:
   • The security group
   • The enabled user
   • The disabled user
     are selected.
6. On Optional features, keep defaults unless your org requires changes.
7. Complete the wizard.

Trigger a sync (optional but common for verification):

• On the Azure AD Connect server, open PowerShell (Admin) and run:

Start-ADSyncSyncCycle -PolicyType Delta

4) Verification steps (prove it worked)

In Microsoft Entra admin center:

1. Go to Identity > Users > All users
   • Search for the enabled user and the disabled user.
2. Open the disabled user and confirm it exists. (It may show as blocked from sign-in depending on state.)
3. Go to Identity > Groups > All groups
   • Search for the security group.

If objects do not appear, the issue is almost always scope/filtering (OU filtering, attribute-based filtering, or connector errors), not the enabled/disabled state.

5) Common pitfalls

• OU not selected during Azure AD Connect setup.
• Filtering applied (domain/OU filtering, attribute-based filtering, or group-based filtering) and forgotten later.
• Expecting disabled users to be excluded automatically.
• Not waiting for sync cycle or not forcing a delta sync during testing.

6) Rollback (undo or reduce impact)

• Re-run Azure AD Connect > Configure > Customize synchronization options and remove the OU(s) from scope.
• If you must stop syncing broadly (high impact), disable directory synchronization at the tenant level only with proper change control (this is typically not a quick rollback).

---

Question 2: Give One User Early Access to Microsoft 365 Features (Targeted Release)

1) Quick answer (one line)

Configure Release preferences for Targeted release (selected users), and only a Global Administrator should change it.

2) What this scenario is testing

This tests whether you know where Targeted release is configured and who is allowed to configure it under least privilege. Early access to features is controlled through Release preferences in the Microsoft 365 admin center, and it is typically restricted to high-privilege roles (most commonly Global Administrator).

3) Step-by-step instructions (click-by-click)

Goal: Enable early access for a single user while minimizing blast radius.

1. Sign in as a Global Administrator.
2. Go to the Microsoft 365 admin center.
3. Navigate to Settings > Org settings.
4. Open Organization profile.
5. Select Release preferences.
6. Choose Targeted release for selected users.
7. Add the specific user who needs early access.
8. Save.

4) Verification steps (prove it worked)

1. Return to Settings > Org settings > Organization profile > Release preferences and confirm:
   • Targeted release is enabled
   • The intended user is listed
2. For practical validation, have the user sign in and confirm new features appear over time (many targeted-release features roll out progressively).

5) Common pitfalls

• Selecting Targeted release for everyone instead of selected users.
• Assuming “Service Support Administrator” or “Cloud Application Administrator” can manage release preferences (often they cannot).
• Expecting changes to appear immediately. Rollouts can be gradual.

6) Rollback (undo or reduce impact)

• Go back to Release preferences and either:
  • Remove the user from the selected list, or
  • Switch back to Standard release
    This is low-risk and typically reverts future feature exposure.

---

Question 3: Identify Who Created a Role Using an IP Address (Audit Search)

1) Quick answer (one line)

In the audit search, use Show results for all activities and filter/search using the Detail field to locate the IP-related event.

2) What this scenario is testing

This tests whether you can use unified audit logging to investigate administrative actions when you only have partial indicators (like an IP). In many audit experiences, the IP is not a primary filter in the UI you expect, so you rely on broad activity search and then narrow results using record details (operation metadata that includes client IP and actor).

3) Step-by-step instructions (click-by-click)

Goal: Find the audit record for a role creation and identify the administrator responsible.

1. Go to the Microsoft Purview compliance portal.
2. Navigate to Audit (sometimes under Solutions > Audit).
3. Set a date/time range covering when the change likely occurred.
4. For activities, select Show results for all activities.
5. Run the search.
6. Use filtering/inspection to narrow results:
   • Search within results for the role name (example: Role1)
   • Inspect matching events and focus on Detail fields (this is where you typically find client IP, workload, operation, parameters, etc.)

4) Verification steps (prove it worked)

Open the relevant audit record and confirm it contains:

• Actor/User (the admin identity)
• Operation (role created / role modified)
• Client IP address (matches your known IP)
• Timestamp and workload context

Document the event (export results if required by your process).

5) Common pitfalls

• Filtering too narrowly by activity category and missing the event.
• Searching only in Exchange tooling when the relevant record is in unified audit logs.
• Using the wrong field. The IP is frequently found inside Detail, not always as a top-level filter.

6) Rollback (undo or reduce impact)

Rollback depends on what was created:

• If it was an Exchange admin role/role group, remove or revert it in the appropriate admin tool (commonly the Exchange admin center) under change control.
• If it granted privileges, immediately remove assigned members and capture evidence before making further changes.

---

Question 4: Time-Bound Admin Access with Approval (Privileged Identity Management)

1) Quick answer (one line)

Use Microsoft Entra Privileged Identity Management (PIM) to make the role eligible, require approval, and limit activation to 8 hours.

2) What this scenario is testing

This tests whether you can implement just-in-time privileged access instead of permanent role assignment. The scenario explicitly calls for: (1) admin access, (2) time-bound duration (8 hours), and (3) approval before access is granted. That combination maps directly to PIM activation controls for Microsoft Entra roles.

3) Step-by-step instructions (click-by-click)

Goal: Make the user eligible for the least-privileged role needed (commonly Exchange Administrator for Exchange Online settings), with approval and an 8-hour limit.

A. Enable role eligibility for the user

1. Go to Microsoft Entra admin center.
2. Navigate to Identity > Identity governance > Privileged Identity Management.
3. Open Azure AD roles (or Microsoft Entra roles, depending on UI naming).
4. Go to Roles.
5. Select the role you need (example: Exchange Administrator).
6. Go to Assignments > Add assignments.
7. Choose:
   • Assignment type: Eligible
   • Member: the user
8. Complete the assignment.

B. Configure activation requirements (approval + duration)

1. In Privileged Identity Management > Azure AD roles > Roles
2. Select the same role (example: Exchange Administrator).
3. Open Settings (or Role settings).
4. Edit the role activation settings:
   • Require approval to activate: Enabled
   • Maximum activation duration: 8 hours
   • Optional good practice: require justification, MFA, and ticket info (if your org uses it)
5. Save.

C. Set approvers

• In the same role settings area, configure the Approvers (specific group or admins responsible for approvals).

4) Verification steps (prove it worked)

1. Sign in as the target user.
2. Go to Microsoft Entra admin center > Privileged Identity Management > My roles.
3. Confirm the role shows as Eligible.
4. Attempt Activate:
   • Confirm approval is required
   • Confirm the maximum duration offered does not exceed 8 hours
5. Approver completes approval.
6. Confirm the role becomes active and the user can now perform the needed Exchange Online admin action.

5) Common pitfalls

• Assigning the role as Active instead of Eligible.
• Forgetting to configure approval and duration, resulting in self-activation without governance.
• Choosing an overly broad role (Global Administrator) when a narrower role (Exchange Administrator) satisfies the task.
• Missing licensing prerequisites for PIM in your tenant.

6) Rollback (undo or reduce impact)

• Remove the eligible assignment:
  • PIM > Azure AD roles > Assignments > find the user > Remove
• Reduce privileges further by switching to a narrower role if you overscoped.
• Tighten activation settings (shorter duration, stricter approval, require MFA/justification).

---

Wrap-up: How to Approach Scenario-Based MS-102 Questions

When you see a scenario, translate it into three decisions:

1. Control plane: Which portal is the source of truth?
   • Identity and roles: Microsoft Entra admin center
   • Compliance auditing: Microsoft Purview compliance portal
   • Feature rollout preferences: typically Microsoft 365 admin center
2. Security posture: Apply least privilege and just-in-time access where possible.
   • If you see “temporary” + “approval” + “admin role,” think PIM.
3. Evidence: Always include a verification plan.
   • UI confirmation, audit entries, and a practical “can the user do the task now” check are your fastest proof points.