SC-100 common mistakes
SC-100 · Understand the traps and how to avoid them.
When a case study contains a constraint phrase such as 'minimize cost', 'use existing licenses', or 'least administrative effort', the candidate still selects the most feature-rich option (for example a full SIEM tier or the highest Entra ID tier) because it is technically the most complete.
Candidates study product capability lists and evaluate options on 'which does the most', while the exam scores on 'which satisfies every stated requirement without breaking a constraint'. The constraint sentence is usually a single clause buried in the requirements table.
What to do instead
Before reading the answer choices, rewrite the requirements list into hard constraints (cost ceiling, existing SKUs, admin effort, timeline). Then eliminate any option that adds a new license, new agent, or new operational process not required by the scenario.
Designs access decisions around network location - for example treating 'connected via corporate VPN' or 'inside the datacenter network' as sufficient reason to grant access to an application or data store.
Perimeter thinking is the legacy mental model most candidates carry in from on-premises security, and network segmentation questions feel like the natural answer to any access question.
What to do instead
For every access design, verify the control evaluates identity, device health/compliance, and risk signals rather than location. If an option's only gate is a network boundary, treat it as a distractor and look for the Conditional Access plus device compliance combination.
Satisfies a multi-requirement case study with a single product (for example 'deploy Defender for Cloud' or 'deploy Sentinel') instead of a layered architecture spanning identity, endpoint, data, network, and security operations.
SC-100 case studies list requirements across several layers; candidates anchor on the one requirement they recognize best and stop designing once that requirement is covered.
What to do instead
Build a one-line mapping of requirement to layer (identity / endpoint / data / network / SecOps) before choosing answers, and confirm the proposed solution touches every layer that appears in the requirements list.
Confuses Microsoft Sentinel with Microsoft Defender XDR - for example assigning long-term multi-source log retention, cross-vendor correlation, or custom automation playbooks to Defender XDR, or assigning native email/endpoint/identity signal correlation to Sentinel.
Both ingest security signals and both offer incident and automation features, so the boundary blurs unless the candidate has memorized the division of responsibility.
What to do instead
Anchor on the boundary: Sentinel is the cloud-native SIEM/SOAR for centralized ingestion and retention of logs from any source (including third-party and on-premises), analytics rules, and playbooks. Defender XDR correlates native signals across Defender for Endpoint, Identity, Office 365, and Cloud Apps into unified incidents. Read the requirement for keywords 'third-party', 'multicloud', 'long-term retention' (Sentinel) versus 'native Microsoft signal correlation' (Defender XDR).
Designs privileged access with Conditional Access alone and omits Entra ID Governance components, so requirements for just-in-time elevation, periodic access reviews, or time-bound group membership go unmet.
Conditional Access is the most rehearsed identity control, so it becomes the default answer for any identity scenario even when the requirement is about the lifecycle of access rather than the conditions of sign-in.
What to do instead
Map requirement keywords directly: 'temporary/just-in-time/eligible' means Privileged Identity Management; 'periodic review/attestation' means access reviews; 'who should have access and for how long' means entitlement management; 'joiner/mover/leaver automation' means lifecycle workflows.
Answers a regulatory or audit requirement (for example 'demonstrate compliance with ISO 27001 or PCI DSS' or 'retain and search records for litigation') with a manual governance process, policy documentation, or a custom script instead of the built-in Microsoft compliance capability.
Compliance questions read like process questions, so candidates describe governance activities rather than the platform feature that produces the assessment and evidence.
What to do instead
Memorize the compliance tool-to-job mapping: Defender for Cloud regulatory compliance standards for continuous assessment of cloud posture against a benchmark; Microsoft Purview Compliance Manager for improvement actions and assessment scoring; Purview Audit, retention, and eDiscovery for evidence and legal hold.
Designs multicloud or hybrid infrastructure protection without the required connectivity layer - assuming Defender for Cloud automatically covers on-premises servers or AWS/GCP workloads with no Azure Arc onboarding or native cloud connector.
Defender for Cloud is described in Azure-centric language, so candidates picture it as an Azure-only control plane and forget that coverage of non-Azure estate depends on an explicit onboarding step.
What to do instead
Whenever the scenario mentions on-premises servers or another cloud, check that the design includes Azure Arc-enabled servers for non-Azure machines and the native AWS/GCP connectors (with the appropriate authentication role or service principal) for those environments.
Treats all Defender for Cloud plans as equivalent - answering a runtime threat detection or server EDR requirement with the foundational CSPM posture assessment, or assuming Defender for Cloud supplies endpoint detection and response natively without the Defender for Endpoint integration.
The product name is the same across posture management and workload protection, and the plan names differ only by suffix (Defender for Servers, Storage, SQL, Containers), so the granularity is easy to skip.
What to do instead
Separate the two jobs explicitly: continuous secure-score and misconfiguration assessment is CSPM; runtime protection for a specific resource type requires the matching workload protection plan, with server EDR provided through the Defender for Endpoint integration.
Answers a data classification or data protection requirement with storage-level encryption, network restriction, and RBAC only, without sensitivity labels, label-based encryption, or DLP policies that persist with the data as it travels.
Candidates default to the infrastructure controls they know best (encryption at rest, firewalls, role assignments) even though those controls do not follow the content once it leaves the protected store.
What to do instead
When the requirement mentions 'classify', 'label', 'track', or 'protect data wherever it goes', the answer must include Microsoft Purview sensitivity labels (optionally with encryption and auto-labeling) plus DLP policies that act on those labels across locations.
Mis-selects among Microsoft Purview solutions - for example answering an executive data-exfiltration-by-departing-employee scenario with eDiscovery, or answering a litigation-hold requirement with DLP, or answering a harassing-language-in-chat requirement with Insider Risk Management.
The Purview workloads share the same portal and overlapping signals, and the scenario wording is often a single sentence of intent with no product vocabulary in it.
What to do instead
Match on intent verbs: 'find and preserve for legal case' means eDiscovery; 'prevent sharing of sensitive content' means DLP; 'detect risky user behavior patterns such as bulk download before resignation' means Insider Risk Management; 'detect policy-violating or offensive communications' means Communication Compliance; 'restrict conflicts of interest between groups' means Information Barriers.