MS-102 common mistakes
MS-102 · Understand the traps and how to avoid them.
Adding a custom domain in the Microsoft 365 admin center and then immediately creating users, mailboxes, or starting a migration before the domain shows Verified and before MX/autodiscover/SPF records exist; also attempting to remove a domain while it is still a user's UPN suffix or primary SMTP address.
Exam items describe a half-onboarded tenant and the candidate pattern-matches to 'migrate mailboxes' or 'create users' because those are the visible goals. The dependency chain (verify TXT or MX → set default domain → create users → publish remaining DNS records → migrate) is easy to skip under time pressure, and the failure to remove a domain surfaces only as an error message in a scenario.
What to do instead
Drill the order explicitly: verify ownership with the TXT (or MX) record, confirm the domain status is Healthy, set the intended default domain, then provision users and run migration batches, then publish SPF/DKIM/DMARC. Before any domain removal, check that no UPN suffix or email address uses it and that it is not the default domain.
Assigning licenses to cloud users without setting Usage location, then responding to a failed assignment or blocked service by purchasing or reallocating more licenses instead of fixing the location or the dependent-service conflict.
Group-based licensing and direct assignment both fail with messages that look like capacity problems, and candidates read 'couldn't assign license' as an entitlement shortage. Usage location is a required property for services with regulatory gating, and disabling a prerequisite service (for example, disabling Exchange Online while a plan needs it) produces a similar-looking error.
What to do instead
Set Usage location on the user (or on the template) before assignment, and always read the actual error text: dependency errors name the service that must be re-enabled. Use the group-based licensing error blade to see per-user blocking reasons rather than adding SKUs.
Treating Conditional Access as 'most permissive wins' - assuming a user covered by an MFA-required policy can still reach an app that a separate block policy targets, or testing remediation only against a report-only policy and declaring the change live.
Candidates model policies as overrides in a priority list (as in some other policy engines) rather than as independent gates where every applicable policy must be satisfied. Report-only mode looks identical to On in the policy list, so the status column gets skimmed.
What to do instead
State the rule to yourself as 'all applicable policies are evaluated and the most restrictive outcome wins; explicit block ends evaluation.' Verify with the What If tool plus sign-in log details before flipping a policy from Report-only to On, and check the policy state column, not just the policy name.
Mixing up what each hybrid identity method actually provides - for example claiming pass-through authentication stores password hashes in the cloud for leaked-credential detection, assuming cloud-only accounts fall under Entra Connect sync scope, or expecting a password change on-premises to require re-running the configuration wizard.
The three sign-in methods are usually learned as a list of names rather than as distinct architectures, so attributes get attached to the wrong method. Leaked-credential detection is the classic trap because it is a security feature that candidates assume works with any sign-in method.
What to do instead
Memorize the method → capability matrix: password hash sync is the prerequisite for leaked-credential detection and enables cloud resilience; pass-through authentication keeps hashes on-premises and depends on lightweight agents for availability; federation moves authentication to an external STS. Use Entra Connect Health to confirm which method is actually active before answering.
Assuming a deleted cloud user is immediately and permanently gone, and not accounting for the recycle-bin window, for deletion followed by re-creation with a different immutable ID, or for on-premises sync restoring a cloud-deleted object on the next cycle.
The admin center removal completes instantly and the user disappears from the list, which reads as final. Candidates forget soft delete, forget that synced objects are authoritative on-premises, and forget that a recreated user with the same UPN does not inherit the old object's assignments or permissions.
What to do instead
Check the Deleted users blade and the 30-day restore window before troubleshooting 'missing user' scenarios, and for synced identities always make the change (or disable the object) in the on-premises directory first. When re-creating, re-assign licenses, group memberships, and roles deliberately.
Attributing a capability to the wrong Defender plan level - for example expecting Attack Simulation Training, automated investigation and response, or campaign views in Defender for Office 365 Plan 1, or expecting endpoint detection and response and threat and vulnerability management in Defender for Endpoint Plan 1.
Both product families use P1/P2 naming with overlapping-sounding feature names, so candidates remember 'Defender' generically and pick the plan that sounds adequate. Exam items often hinge solely on whether the stated feature is included.
What to do instead
Build a two-column table per family. Defender for Office 365: Plan 1 covers Safe Attachments, Safe Links, anti-phishing, and real-time detections; Plan 2 adds automated investigation and response, attack simulation training, threat trackers, and campaign views. Defender for Endpoint: Plan 1 covers next-generation protection and attack surface reduction; Plan 2 adds EDR, automated investigation and response, and vulnerability management.
Assuming every alert appears as its own incident, or that an alert from a workload is present at all - without checking whether the Microsoft Defender XDR incident correlation setting is on, whether an alert-tuning or suppression rule is hiding it, or whether the workload connector is enabled.
The incident queue is the first screen candidates picture, so a 'why is there no incident' scenario gets answered with 'check the alert policy' when the real cause is ingestion or correlation. Suppression rules and correlation settings are configuration, not detection logic, so they are studied last.
What to do instead
Triage in this order: confirm the workload is connected (Settings > data connectors), then check that the alert policy is enabled and its severity/entity mapping, then check alert tuning and suppression rules, then confirm incident correlation is enabled and the alert threshold. On the 'why so many separate incidents' side, the answer is correlation, not disabling alerts.
Expecting a newly created custom anti-phishing, Safe Links, or Safe Attachments policy to take effect for users who are in the Standard or Strict preset security policy, or assuming the last-created custom policy wins over an earlier one.
Candidates think of policies as a flat list where the newest edit is authoritative. Preset security policies are configured separately and, when a user is included, the preset settings apply and custom policies of that type do not - so a correctly built custom policy silently has no effect.
What to do instead
Check preset policy membership first (Standard and Strict user inclusion lists) and remember preset settings take precedence over custom policies for those users. Among custom policies, precedence follows policy order (lowest priority number wins), not creation time, so verify order before concluding a policy is broken.
Treating retention as an absolute guarantee that content cannot be deleted or that it disappears from eDiscovery - for example assuming a retain-only label destroys items after the period, or that a retention policy prevents a user from deleting an email before the period ends.
'Retention' is read as 'hold', so candidates conflate retain, retain-and-delete, and record/disposition behaviors. The principle of precedence is also assumed to be simple, when in practice a label-driven deletion can be blocked by a policy-driven retention or by a regulatory record.
What to do instead
Separate the three outcomes explicitly: retain only (deletion by the user is allowed, a copy persists for the period), retain then delete (the label or policy performs the deletion at the end), and records/regulatory records (immutability). Learn precedence: retention wins over deletion, the longest retention period wins, and a regulatory record beats everything.
Expecting Premium eDiscovery capabilities - custodian and non-custodian data source management, review sets, near-duplicate detection, email threading, themes - to be available in a Core eDiscovery case, or treating a case hold as equivalent to a tenant retention policy.
Both features live under the same Purview eDiscovery node, and the case UI looks nearly identical until you look for the premium controls. Candidates also conflate 'hold' with 'retention' because both keep content, without considering which locations and which item states each one covers.
What to do instead
Anchor on licensing-to-feature mapping: Core covers search, case management, and basic holds; Premium adds custodians, review sets, analytics, and predictive coding. When a scenario needs item-level analysis or custodian reporting, the answer is Premium. When a scenario needs blanket coverage across locations for all users indefinitely, the answer is a retention policy, not a case hold.