SC-200 common mistakes
SC-200 · Understand the traps and how to avoid them.
Treating Microsoft Sentinel analytics rules as fire-and-forget, so candidates cannot explain why a given incident was or was not generated, or which entity mappings feed the incident.
Candidates memorize the rule-creation wizard screens but never learn how entity mapping, alert grouping, and rule scheduling interact, so they cannot reason about missed or merged detections.
What to do instead
Before the exam, build a small lab tenant and create one scheduled rule, deliberately vary the query window, entity mapping, and incident grouping settings, then observe the resulting incident in the queue. Practice stating aloud which settings produced the observed behavior.
Confusing data connectors with data collection rules (DCRs) and diagnostic settings, and picking a connector when the scenario asks how to route or transform events.
All three appear in ingestion discussions and the portal surfaces overlap, so candidates default to 'connector' for every ingestion question.
What to do instead
Map each tool to its job: connectors bring data in from sources, DCRs define collection and transformation for Azure Monitor/AMA pipelines, and diagnostic settings route platform logs to a destination. Drill with scenario stems that name the source and the required transformation.
Ignoring role-based access control and Microsoft Sentinel roles when answering workspace or incident-handling questions, assuming Contributor is always sufficient.
Candidates focus on features and skip the permissions layer, so they miss questions where least privilege or a specific Sentinel role is the deciding factor.
What to do instead
Study the Sentinel role set and the Azure RBAC roles relevant to Log Analytics workspaces, then practice matching a task (triage, automation runbook execution, playbook deployment) to the minimum role that permits it.
Selecting a playbook action that requires a connection or permission the scenario does not grant, such as assuming a playbook can act on a resource without a managed identity or API connection.
Candidates learn playbook triggers but not the authentication and connector prerequisites, so they choose an automation that would fail at runtime.
What to do instead
For each common playbook pattern (block user, isolate device, post to Teams, enrich with threat intel), write down the required connector, identity, and permission. Review that list before answering automation questions.
Misclassifying incident severity and status transitions, for example closing an incident as Resolved without addressing the classification, or treating 'New' and 'Active' as interchangeable.
The incident lifecycle fields look cosmetic, so candidates skim them and pick the wrong state for a described workflow.
What to do instead
Learn the incident state model and the classification options, then walk through a full lifecycle in the portal: assign, set to Active, add a comment, resolve with a classification and reason. Note which fields are mandatory at each step.
Answering containment questions with the most aggressive action available (for example, full device isolation or account deletion) when the scenario calls for a proportionate first step.
Candidates equate 'respond' with 'act hard', and exam stems often describe a suspicious but unconfirmed signal where a softer action is correct.
What to do instead
Practice ranking response actions by impact: investigate and collect evidence, then restrict, then isolate, then remediate. For each scenario, justify why the chosen action is the least disruptive step that contains the confirmed risk.
Skipping evidence gathering and chain-of-custody considerations, jumping straight to remediation and losing the ability to answer questions about investigation packages or evidence preservation.
Remediation feels like the satisfying end of an incident, so candidates underweight the investigative steps that precede it.
What to do instead
Rehearse a standard incident sequence: confirm scope, collect and preserve evidence, contain, eradicate, recover, then document. Identify which Microsoft Defender and Sentinel features support each step, including live response and investigation artifacts.
Treating advanced hunting queries as generic KQL and ignoring the schema differences between Defender XDR tables and Sentinel/Log Analytics tables.
Candidates practice KQL on one table set and then assume table names and fields are identical across portals, so they choose queries that would not run in the named environment.
What to do instead
Maintain a short reference of the key tables in each environment (device, email, identity, and alert tables in advanced hunting versus the equivalent Log Analytics tables) and practice writing the same hunt in both contexts.
Building a hunting hypothesis as a broad keyword search rather than a testable statement about attacker behavior mapped to a technique.
Candidates treat hunting as 'search logs for something bad', which produces noisy queries and cannot be evaluated against a described scenario.
What to do instead
Practice writing hunts in the form: hypothesis, technique, data source, query, expected benign explanation, and escalation criteria. Review a handful of common techniques and identify the telemetry each would leave behind.
Confusing custom detections with hunting queries, and assuming a saved hunting query automatically generates alerts or incidents.
Both are authored in KQL and stored in the same interface area, so candidates assume saving a query is equivalent to creating a detection.
What to do instead
Learn the distinct purpose and lifecycle of each: hunting queries are exploratory and analyst-driven, custom detections are scheduled and produce alerts. Practice converting a validated hunting query into a detection and note every setting that must change.