SC-401 common mistakes
SC-401 · Understand the traps and how to avoid them.
Setting a default sensitivity label in the label policy and then assuming every existing unlabeled document in SharePoint and OneDrive will become labeled.
The default label in a label policy is applied only when an item is created or edited by a labeling client; it is not a retroactive backfill. Candidates test with a brand-new file (which works), then explain the feature as if it protects the existing corpus, and the scenario questions about legacy content trip them up.
What to do instead
Separate the two mechanisms in your head: 'default label = new/edit time' and 'auto-labeling policy or manual/bulk labeling = existing content'. When a question asks about content already sitting in a site, answer with a service-side auto-labeling policy (run in simulation first), and verify coverage in Content explorer rather than assuming it.
Configuring a label with 'Assign permissions now' encryption for a single department group and never checking who can still open the file - then being surprised that co-authoring, external sharing, or a second user's access breaks.
Candidates focus on getting the encryption checkbox enabled and forget the three follow-on settings that decide usability: the permission scope, offline access, and co-authoring for encrypted files. Exam scenarios often hinge on a user who 'cannot open' or 'cannot edit' a labeled file.
What to do instead
For every encryption-label scenario, check in this order: (1) which identities/groups get which rights in the label, (2) whether offline access is allowed, (3) whether co-authoring for encrypted files is enabled for the workload. Validate by opening the file as a second test account, not just the author.
Assuming that labeling a Teams team or a SharePoint site (a container label) automatically stamps that label onto the files and messages inside it, or assuming a label configured for one workload protects all workloads.
The label policy wizard makes it look like one label covers everything, but app support is per-workload and container-to-item inheritance is a separate, configurable behavior. Candidates answer 'the files inherit the site's label' without checking whether inheritance is turned on.
What to do instead
Memorize that labels are per-workload (files and emails, meetings/chat, sites and groups, schemas, etc.) and that container-label inheritance to items must be explicitly enabled and verified. In scenarios, ask 'which workload is the content in?' before choosing label behavior, and test inheritance with a newly uploaded file.
Building a DLP rule, seeing it listed as active in the policy list, and concluding it is enforcing - while the policy is actually still in simulation or test mode with policy tips, so nothing is blocked and no alerts fire.
The deployment-status column and the mode setting are visually easy to skim past, and every new DLP policy starts non-enforcing. Questions phrased as 'users can still send the data and no alert was raised' are usually testing exactly this.
What to do instead
Always check the policy's mode explicitly: simulation, test with policy tips/notifications, or enforce. When a scenario describes enforcement not happening, list 'policy is not in enforce mode' as a candidate cause before blaming rule logic, sensitive info type definitions, or client support.
Writing a DLP rule keyed to a sensitive information type and expecting it to detect that data inside files that are already encrypted by a sensitivity label, on every workload.
Inspection of encrypted payloads differs by workload and by how the encryption was applied; endpoint DLP generally cannot read inside label-encrypted content. Candidates generalize from a working Exchange or SharePoint test to endpoints and then pick a rule that can never fire.
What to do instead
For each workload, confirm whether content inspection of encrypted items is possible. Where it is not, design the rule around a label-based or 'content is encrypted' condition instead of a sensitive information type, and validate with a deliberately encrypted test file rather than an unencrypted one.
Enabling the Devices location in a DLP policy and expecting endpoint protection, without first onboarding devices to the endpoint protection service and defining device groups.
Endpoint DLP depends on an external onboarding and device-group model; the DLP policy alone does nothing on unmanaged endpoints. Candidates treat 'Devices = On' as sufficient and then can't explain why copy-to-USB or print actions were never blocked.
What to do instead
Order the prerequisites explicitly in any endpoint scenario: devices onboarded and healthy, device groups defined, then the Devices location enabled in the DLP policy, then the specific DLP settings (unallowed apps, USB, network share) configured. Verify with a test device rather than the policy author's machine.
Applying a retention label to a document and expecting it to delete on schedule, or assuming the shorter/delete-only setting wins when a label and a retention policy both apply.
Candidates conflate labels with policies and never internalize the resolution principles (retention takes precedence over deletion; the longest retention period wins), nor the difference between a plain label, a record, and a regulatory record that blocks edits and deletion.
What to do instead
State the precedence rules out loud when reasoning: retain beats delete, longest period wins, and record types change what users can do to the item. Before answering, identify whether the scenario needs a retention policy (broad, location-based) or a retention label (item-level, with record behavior) and confirm the label was actually applied.
Investigating an incident scenario that depends on Activity explorer or Insider Risk Management while never confirming that auditing is enabled and that enough time has passed for events to appear.
Auditing is the substrate for activity-based features, and ingestion plus policy evaluation can lag by hours. Candidates see an empty Activity explorer, assume the action never happened, and choose an answer about misconfigured labels instead of missing audit data or latency.
What to do instead
Make 'is auditing on, and has the ingestion window elapsed?' your first question in any activity or insider-risk scenario. State the expected latency before drawing conclusions, and use audit log search to confirm the raw event exists even when the higher-level report looks empty.
Assuming an alert will be raised because a DLP or labeling rule exists, without configuring an alert policy or alert threshold - and then looking for that alert in the wrong portal.
Alerting is a separate configuration surface from the protection rule, with its own severity and threshold settings, and different alert types land in different consoles. Candidates conflate 'rule matched' with 'alert created' and misidentify where to triage.
What to do instead
For every detection scenario, name the alert configuration separately from the rule: alert on/off, severity, threshold (for example aggregate or single-event), and the alert queue you would triage in. Cross-check that the event appears in the activity view before concluding that alerting is broken.
Turning on an insider risk policy and expecting alerts, while prerequisites such as role group membership, audit, indicator selection, and any needed HR or third-party data feed are missing or still propagating.
Insider risk depends on a chain of prerequisites and per-indicator enablement, and new policies need time before they produce meaningful signals. Candidates treat the policy toggle as the whole setup and then choose 'the user did nothing' or 'the file is unlabeled' as the explanation for an empty queue.
What to do instead
Walk the prerequisite chain in order in any insider-risk question: permissions, auditing on, indicators enabled, policy scope correct, data connectors in place, and propagation time accounted for. If the queue is empty but should not be, suspect the chain, not the user's behavior.