SC-401 Administering Information Security in Microsoft 365 Question and Answers

Step 1 – Scenario

The requirement is to ensure Microsoft Purview Insider Risk Management can collect signals when a user copies files to a USB device using their default browser. The devices differ by browser type:

Device1 → Default browser = Microsoft Edge

Device2 → Default browser = Google Chrome

Step 2 – Signal collection methods in Insider Risk Management

Insider Risk Management uses Microsoft Purview Information Protection client and Purview browser extensions to collect activity signals.

For Microsoft Edge (Chromium-based), insider risk signals are collected via the Microsoft Purview Information Protection client.

For Google Chrome, signals are collected through the Microsoft Purview extension (available in the Chrome Web Store).

The Microsoft Defender Browser Protection extension is for web protection against malicious sites, not for insider risk activity signals, so it is irrelevant here.

Step 3 – Microsoft Reference

Microsoft documentation:

“For insider risk signals collection in Microsoft Edge, the Microsoft Purview client must be deployed. For Google Chrome, the Microsoft Purview extension is required.”

To ensure User1 can perform insider risk management tasks only for the users and devices in Office1, the first step is to create an administrative unit in Microsoft Entra ID (formerly Azure AD).

Administrative units allow you to scope permissions to specific users, devices, and locations. By creating an administrative unit for Office1 and assigning User1 to the Insider Risk Management Admins role group within that unit, User1 will only have access to users and devices in Office1.

To ensure Azure Storage Account keys are encrypted when sent via email, you need a Data Loss Prevention (DLP) policy that detects Azure Storage Account keys using a sensitive information type and automatically encrypts emails containing these keys.

Mail flow rules (transport rules) can detect sensitive info, but they are limited in encryption capabilities.

DLP policies provide more advanced protection and integration with Microsoft Purview for sensitive info detection.

An activity policy in Microsoft Defender for Cloud Apps (Microsoft Defender portal) allows you to track and alert on specific user actions, such as sharing sensitive documents externally from OneDrive. This policy can detect file-sharing activities and send alerts when files are shared with external users, which meets the requirement.

EDM does not store raw data; instead, it requires hashed versions of sensitive data for privacy and security. To upload the hashed data, Microsoft provides the EDM upload agent. This ensures that the data is securely processed and recognized by the EDM service in Microsoft 365.

Statement 1 - No. User1 is included in JIT protection. File1.docx is on Device1, which is onboarded to Microsoft Defender. However, File1.docx has not been evaluated for file classification, meaning JIT cannot enforce protection on it. If User2 signs in to Device2 and attempts to attach File2.pdf to an email, JIT will block the action.

Statement 2 - No. User2 is not configured for JIT protection (JIT does not apply to them). File2.pdf has been evaluated for classification, but since User2 is not included in JIT protection, no blocking occurs. If User3 attempts to copy File3.xlsx to a network share, JIT will generate an audit event.

Statement 3 - No. User3 is included in JIT protection. However, Device3 is not onboarded to Microsoft Defender, meaning JIT protection cannot enforce actions on it. File3.xlsx has not been evaluated, so even if the device were onboarded, JIT would not have classification data to act upon.

To meet the requirements, you need one DLP policy with two separate DLP rules to handle the different conditions:

1. First DLP Rule (For Group1 Members): If the user is a member of Group1 and attempts to copy a file with sensitive data to a USB storage device. Allow the file copy but log the event in the audit log.

2. Second DLP Rule (For All Other Users): If any user who is NOT in Group1 attempts to copy a file with sensitive data to a USB storage device. Block the file transfer.

To ensure Azure Storage Account keys are encrypted when sent via email, you need a Data Loss Prevention (DLP) policy that detects Azure Storage Account keys using a sensitive information type and automatically encrypts emails containing these keys.

Text patterns in mail flow rules are not as reliable as sensitive information types in DLP.

Mail flow rules lack advanced content detection and machine learning-based classification, making them less effective than DLP.

A Preservation Lock in Microsoft Purview Retention Policies enforces strict compliance and prevents certain modifications to ensure data is retained according to compliance requirements.

When a Preservation Lock is applied:

1. You cannot disable or delete the policy.

2. You cannot remove locations from the policy.

3. You cannot decrease the retention period.

4. You can add locations to the policy.

5. You can increase the retention period.

You can expand the retention policy to cover additional locations (e.g., more Exchange mailboxes, SharePoint sites). You can extend the retention duration (e.g., increase from 5 years to 10 years) since this aligns with stricter compliance.

Comprehensive Detailed Explanation with References

The command Set-AuditConfig -Workload Exchange is related to configuring auditing for workloads but does not enable mailbox auditing.

To capture and view who is accessing User1’s mailbox, mailbox auditing must be enabled at the mailbox level in Exchange Online.

Correct solution would be:

Set-Mailbox -Identity User1 -AuditEnabled $true

Mailbox auditing is enabled by default for all mailboxes in Microsoft 365 now, but if it is disabled, enabling auditing at the mailbox level is required. Running Set-AuditConfig -Workload Exchange alone does not accomplish this.

To automatically encrypt email messages using Microsoft Purview Message Encryption (OME), administrators must configure mail flow rules (also known as transport rules) in the Exchange admin center. These rules can be configured to check conditions, such as when a recipient is a specific user or when an email contains attachments, and then apply encryption automatically. Sharing policies, Safe Attachments policies, and retention label policies are not used for OME encryption.

In Microsoft Purview Data Lifecycle Management, different Microsoft 365 locations require separate retention policies because they fall under different storage and compliance models.

Teams Chats & Teams Channel Messages (1 Policy) require a separate retention policy because Teams messages are stored differently than Exchange and SharePoint content. One policy can cover both Teams chats and Teams channel messages. Exchange Email (1 Policy) requires its own separate policy since emails are managed differently than Teams or SharePoint content. SharePoint Sites & Microsoft 365 Groups (1 Policy) are both stored in SharePoint Online, so they can be managed under one policy.

Step 1 – Requirement

You need to configure a mail flow rule in Exchange Online to apply a Microsoft Purview Advanced Message Encryption (OME) branding template named OME1.

Step 2 – Mail Flow Rule Conditions

In Exchange Online, to trigger encryption based on sensitivity labels (classifications):

You use the condition " Apply this rule if: The sender … Includes the classification " .

This lets the rule detect when the sender applies a particular sensitivity label (classification) to the email.

Step 3 – Mail Flow Rule Action

To apply a custom branding template (such as OME1), you configure the action:

" Modify the message security " .

This is the action that allows applying encryption and assigning a specific OME template for branding.

for each of the following you can have a retention policy

1.EXO, SPO, ODfB, M365 groups

2.Teams channel messages, teams chat

3.Teams private channel messages

Comprehensive Detailed Explanation with References

When multiple advanced DLP rules match content, Microsoft 365 DLP evaluates based on:

Rule priority

Lower number = higher priority (0 highest).

Among Rule2 (priority 1), Rule3 (priority 2), and Rule4 (priority 3), Rule2 has the highest priority.

Conflict resolution (single vs multiple rules applied)

By default, only the highest-priority rule applies if multiple rules match. → That’s why in the first dropdown, the correct answer is Only Rule2 takes effect.

However, you can configure advanced DLP to allow multiple matching rules to take effect simultaneously. If this setting is enabled, then Rule2, Rule3, and Rule4 all apply. → That’s why in the second dropdown, the correct answer is Rule2, Rule3, and Rule4 take effect.

You need to define a custom sensitive information type that recognizes the unique 13-digit identifier format for customer records. Microsoft Purview DLP policies use these types to identify and protect sensitive data.

A Data Loss Prevention (DLP) policy is required to enforce the rules. It will allow emails with a single identifier but trigger an approval workflow when two or more identifiers are detected.

Step 1 – Scenario

Endpoint Data Loss Prevention (Endpoint DLP) is implemented in Microsoft 365.

Computers: Windows 11, joined to Microsoft Entra (Azure AD), with Microsoft 365 Apps installed.

Goal: Ensure Endpoint DLP policies can protect local content on these devices.

Step 2 – How Endpoint DLP works

Endpoint DLP builds on the same policy framework as Microsoft Purview DLP, but specifically extends coverage to Windows 10/11 devices.

Requirements:

Devices must be onboarded to Microsoft Purview (via Microsoft Defender for Endpoint or via Purview device onboarding).

Endpoint DLP does not require the Microsoft Purview Information Protection (MIP) client.

The MIP client is only required for sensitivity labeling and AIP functionality, not for Endpoint DLP.

Step 3 – Why the proposed solution is incorrect

Deploying the Microsoft Purview Information Protection client does not enable Endpoint DLP.

Endpoint DLP requires device onboarding into Microsoft Purview compliance.

Therefore, this solution does not meet the goal.

Step 4 – Microsoft Reference

Microsoft Docs states:

“To use Endpoint data loss prevention (Endpoint DLP), devices must be onboarded to the Microsoft Purview compliance portal. Installing the Microsoft Information Protection client is not required.”

Step 1 – Understanding the requirement

You want to retain specific audit log record types and activities for 3 years:

CopilotInteraction → All activities (1/1)

Compliance DLP endpoint → All activities (2/2)

Azure Active Directory → Only 2 out of 25 activities selected (Reset user password, Changed user password)

The goal is to minimize the number of audit retention policies while meeting the requirement to store only the selected record types and activities.

Step 2 – Audit retention policies in Microsoft Purview

Audit retention policies let you define which activities and record types are retained and for how long.

A single retention policy can include multiple record types and multiple activities.

Limitation: Each policy can only define one set of retention settings per included record types/activities.

If you want to retain different subsets of activities (e.g., only 2 out of 25 in Azure AD), you must create a separate policy for that.

📖 Reference: Set up audit (Premium) retention policies in Microsoft Purview

Step 3 – Applying to the scenario

CopilotInteraction: Since you need all activities, you can include them in one policy.

Compliance DLP endpoint: Since you also need all activities, they can be added to the same policy as CopilotInteraction.

✅ These two can be covered by 1 policy.

Azure Active Directory: You only need 2 out of 25 activities. Since this requires activity-level filtering, it must be placed in a separate policy.

Thus:

Policy 1 → CopilotInteraction (all) + Compliance DLP endpoint (all)

Policy 2 → Azure AD “Reset user password”

Policy 3 → Azure AD “Changed user password”

That equals 3 total policies.

Step 1 – Scenario

You need to create a Microsoft Purview Insider Risk Management policy that detects data theft from SharePoint Online by users who have submitted their resignation or are close to termination.

Step 2 – Understanding how insider risk management works

Insider Risk policies rely on signals that identify potential risk events. These signals include:

HR data (resignation dates, termination notices).

Office activity indicators (file downloads, sharing, printing).

Device indicators (file copy to USB, printing).

Physical access (badge-in/badge-out).

Step 3 – Why HR signals are required here

To detect resignation or termination risk events, Microsoft Purview must first know which users are flagged by HR.

This is done by configuring an HR data connector, which imports employee termination/resignation data from HR systems (Workday, SAP SuccessFactors, or CSV import).

Without this HR data connector, Purview has no knowledge of employees’ resignation or termination timelines, and the policy cannot function.

Step 4 – Why not the other options

B. Configure Office indicators: These detect risky activity (downloads, sharing), but cannot determine resignation status. They are used after HR signals identify at-risk users.

C. Configure a Physical badging connector: Useful for detecting anomalous physical access, but irrelevant to resignation-based detection.

D. Onboard devices to Microsoft Defender for Endpoint: Required for device activity signals, not for HR resignation detection.

Step 5 – Microsoft Reference

Microsoft documentation states: “To use HR resignation/termination triggers, you must configure an HR connector to import resignation and termination data into insider risk management.”

Comprehensive Detailed Explanation with References

We are given a sensitivity label with the following Access control settings:

Assign permissions now → meaning admins define permissions, not end users.

User access to content expires = Never.

Allow offline access = Always.

Permissions explicitly assigned:

LegalTeam@… → Co-Author

USSales@… → Reviewer

Dynamic watermarking and Double Key Encryption are not enabled.

Box 1: When creating a Microsoft Purview Insider Risk Management case, you must first select a risky user to investigate. The case will be built around this specific user’s activities, linking alerts and risk signals to the investigation.

Box 2: The Insider Risk Management role groups determine who can access and contribute to cases:

● Admin1 (Insider Risk Management Admins) → Full admin access.

● Admin2 (Insider Risk Management Analysts) → Analysts who review cases.

● Admin3 (Risk Management Investigators) → Investigators who work on cases.

● Admin4 (Insider Risk Management Auditors) → Auditors who oversee cases.

All these roles have default access to insider risk cases in Microsoft Purview, so all four admins are added as contributors.

Retention policy tags (MRM) for Exchange Online are applied by the Managed Folder Assistant (MFA). To apply a newly created Exchange retention policy to mailbox items immediately, you manually invoke MFA with Start-ManagedFolderAssistant for the mailbox or set of mailboxes. Creating DLP policies or label policies in Purview does not accelerate MRM processing.

To meet the requirement that all administrative users must be able to create Microsoft 365 sensitivity labels, we need to assign the Sensitivity Label Administrator role to the correct users.

Sensitivity Label Administrator Role Responsibilities

This role allows users to:

● Create and manage sensitivity labels in Microsoft Purview.

● Publish and configure auto-labeling policies.

● Modify label encryption and content marking settings.

Review of Admin Roles from the Table:

Users that must be assigned the Sensitivity Label Administrator role:

● Admin2 (Compliance Data Administrator)

● Admin3 (Compliance Administrator)

● Admin1 (Global Reader) (should be assigned this role to fulfill the requirement that all admins can create labels).

To detect and protect confidential documents, we need a custom rule to identify project codes that start with 999 (since they are classified as confidential).

Box 1: A Sensitive Info Type (SIT) allows Microsoft Purview DLP policies to recognize structured data (e.g., project codes). DLP policies require a sensitive info type to detect content based on patterns, keywords, or dictionary terms. A sensitivity label alone does not define detection logic—it is used for classification and protection after content is identified.

Box 2: Since project codes follow a structured 10-digit pattern, we should use a Regular Expression (Regex) to match project codes that start with 999.

Example Regex pattern:

999\d{7}

This pattern detects a 10-digit number starting with " 999 " .

The requirement states that all Microsoft 365 data for users must be retained for at least one year. In Microsoft 365, retention policies must be configured for each type of data storage.

Step 1: Identifying Where Data is Stored

From the case study, users store data in the following locations:

● SharePoint Online sites

● OneDrive accounts

● Exchange email

● Exchange public folders

● Teams chats

● Teams channel messages

Since these locations fall under two broad categories:

● Microsoft Exchange data (Emails, Public folders)

● SharePoint, OneDrive, and Teams data

Step 2: Required Retention Policies

1️. A single retention policy can cover:

● SharePoint Online

● OneDrive

● Microsoft Teams

2. A second retention policy is required for:

● Exchange (Emails & Public Folders)

Thus, the minimum number of retention policies required to meet the requirement is 2.

Microsoft 365 retention policies can be applied broadly across multiple services with just two policies:

● One for Exchange & Public Folders

● One for SharePoint, OneDrive, and Teams

There ' s no need for separate policies for each individual workload unless different retention durations are required, which is not stated in the requirement.

The goal is to automatically label documents in Site1 that contain credit card numbers. To achieve this, we need a sensitivity label with an auto-labeling policy based on a sensitive info type that detects credit card numbers.

Step 1: Create a Sensitive Info Type

● A sensitive info type is needed to detect credit card numbers in documents.

● Microsoft Purview includes built-in sensitive info types for credit card numbers, but we can also create a custom one if necessary.

Step 2: Create a Sensitivity Label

● A sensitivity label is required to classify and protect documents containing sensitive information.

● This label can apply encryption, watermarking, or access controls to credit card data.

Step 3: Create an Auto-Labeling Policy

● An auto-labeling policy ensures that the sensitivity label is applied automatically when credit card numbers are detected in Site1.

● This policy is configured to scan files and automatically apply the correct sensitivity label.

Understanding DLP Policy Impact on File Access

The DLP policy (DLPpolicy1) applies to Site2 and restricts access when:

● Content contains SWIFT Codes.

● Instance count is 2 or more.

File Analysis (Based on SWIFT Codes Count)

Files that remain accessible (not restricted by DLP):

● File1.docx (Contains only 1 SWIFT Code → Below restriction threshold)

User access after DLP policy is applied:

User1 (Site Owner):

● Has higher privileges and can override DLP restrictions (through admin intervention).

● Can access 2 files (File1.docx + override access to another file).

User2 (Site Visitor):

● Has read-only access but DLP blocks access to restricted files.

● Can only access 1 file (File1.docx), since all others are restricted.

Understanding Site4 ' s Retention Policies:

● Site4RetentionPolicy1 deletes items older than 2 years from creation. If a file was created on January 1, 2021, it would be deleted after January 1, 2023.

● Site4RetentionPolicy2 retains files for 4 years from creation. If a file was created on January 1, 2021, it will be kept until January 1, 2025, but not deleted after that (policy states " Do nothing " ).

Statement 1 - Yes, because Site4RetentionPolicy2 ensures files are retained for 4 years.

Statement 2 - Yes, because Site4RetentionPolicy2 retains the file for 4 years (until January 1, 2025).

Statement 3 - No, because retention is only for 4 years (until January 1, 2025). After that, the policy does " nothing, " meaning the file is no longer recoverable after that period.