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

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.

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.

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".

Comprehensive Detailed Explanation with References

Step 1 – Review File2 contents

File2 contains 3 IP addresses.

Step 2 – Review DLP rules and priorities

RuleConditionPolicy TipStop Processing?Priority

Rule11 or more IP addressesTip1No0

Rule23 or more IP addressesTip2Yes1

Rule32 or more IP addressesTip3No2

Step 3 – Rule evaluation order

Advanced DLP rules are processed by priority order (lowest number first).

Rule1 (Priority 0) will trigger because File2 has at least 1 IP address.

This applies Tip1.

However, Rule1 has Stop Processing = No, so evaluation continues.

Rule2 (Priority 1) will also trigger because File2 has 3 IP addresses (≥3).

This applies Tip2.

Rule2 has Stop Processing = Yes, so evaluation stops after this.

Rule3 (Priority 2) will not be evaluated because Rule2 stopped processing.

Step 4 – Final outcome

File2 matches Rule1 (Tip1), but since Rule2 fires afterward with Stop Processing = Yes, only Tip2 is applied.

Step 5 – Microsoft Reference

From Microsoft docs: “When a rule is configured to stop processing, subsequent rules are not evaluated and only the policy tip from the last triggered rule with stop processing applies.”

If User1 sends an email externally with five credit card numbers, Policy1 applies. → Yes

If User1 sends an email externally with five credit card numbers, Policy2 also applies. → No (stopped by Policy1).

If User2 sends an email externally with five credit card numbers, Policy2 applies. → Yes

🔹 Policy1

Order: 0 (highest priority).

Scope: Exchange email for the Finance distribution group.

Conditions: Content shared externally AND contains ≥ 5 credit card numbers.

Actions: Encrypt with “Encrypt email” option.

Additional options: Stop processing additional DLP policies and rules.

🔹 Policy2

Order: 1 (lower priority).

Scope: All Exchange email.

Conditions: Content shared externally AND contains ≥ 5 credit card numbers.

Actions: Restrict/block OR encrypt depending on configuration, notify admin.

Additional options: None.

🔹 User-by-user Analysis

User1 (Finance group):

Policy1 applies first (priority 0).

If User1 sends email externally with ≥ 5 CCNs, Policy1 encrypts the email and stops further processing.

Therefore, Policy2 never applies to User1.

User2 (Sales group):

Not in Finance, so Policy1 does not apply.

Policy2 applies (all Exchange email).

If User2 sends email externally with ≥ 5 CCNs, Policy2 action is enforced (restrict/block or encrypt).

Current setup:

DLP1 (priority 0, Rule1) → Stop processing additional rules enabled → means if Rule1 matches, later rules (including Rule2 with Tip2) will never be evaluated.

Requirement: Ensure that if all rules match, the user sees Tip2 (Rule2’s policy tip).

To fix this: Move DLP2 above DLP1 in priority (i.e., set DLP2 = priority 0). Then Rule2 will be evaluated first, and its policy tip (Tip2) will be displayed.

Why not others?

B. Prevent additional processing of the policies if there is a match for Rule2: That would stop processing later, but DLP1 would still block earlier due to its higher priority.

C. Change the priority of DLP2 to 3: That pushes it even lower, making it worse.

D. Enable additional processing for Rule1: Rule1 already has stop processing enabled. Changing that does not ensure Rule2 runs before Rule1, because priority is evaluated first.

User1: Since the Microsoft Purview browser extension is installed on Device1, AI-related activity performed by User1 (generating an image using a generative AI website) can be reviewed in Activity explorer in DSPM for AI.

User2: Since Device2 does not have the Microsoft Purview browser extension installed, AI-related activity cannot be tracked in DSPM for AI. Instead, Audit log search should be used to review activity such as using Microsoft 365 Copilot.

User3: Since Device3 has the Microsoft Purview browser extension installed, AI-related activity (browsing sample content on a generative AI website) can be reviewed using Activity explorer in DSPM for AI.

Step 1 – Problem statement

User1 has the Compliance Administrator role but cannot view the regular expression in the built-in IP Address sensitive info type.

This is expected because:

Microsoft provides a large set of built-in sensitive info types (SITs).

For these built-in SITs, the underlying regular expressions, keywords, or detection logic are not exposed to administrators for security reasons.

As a result, even with Compliance Administrator privileges, User1 cannot directly see or modify the regex in the built-in IP Address SIT.

Step 2 – Microsoft solution

To view or modify the regex:

You must create a copy of the built-in SIT.

Once copied, the new custom SIT allows you to edit and view the regex and supporting elements.

This is the only supported way to customize or examine the detection logic.

📖 Reference: Create a custom sensitive information type

“You can't directly modify the definitions of built-in sensitive information types, but you can create a copy of an existing SIT and then edit it.”

Step 3 – Why not the other options?

A. Reviewer role group → Reviewers are for records management/discovery, not SIT regex visibility.

C. Test function → Allows you to test SIT detection but does not reveal the regex.

D. Global Reader role → Read-only access, does not expose regex definitions either.

When configuring an advanced DLP rule in Microsoft Purview Data Loss Prevention (DLP), you can use a Sensitive Information Type (SIT) condition to detect and classify specific types of sensitive data, such as credit card numbers, Social Security numbers, or custom sensitive data patterns. This allows you to apply protection and trigger actions based on the identified content.

Step 1 – Review the configuration

Sensitivity label name: Contoso Confidential

Scope: Files and emails

Access control:

Encrypts documents/emails.

Permissions assigned to AuthenticatedUsers with Co-Author rights.

Offline access allowed only for 7 days.

Auto-labeling = None (not configured).

Content marking: Footer applied.

Step 2 – Analyze each statement

Statement 1: If a user account is disabled, the user will be immediately prevented from opening a file protected by Contoso Confidential.

Sensitivity labels with encryption enforce Azure AD authentication every time a user tries to access a file.

If the account is disabled in Azure AD, access is blocked immediately.

Answer: Yes

Statement 2: Guest users will be able to open documents protected by Contoso Confidential.

Access control was configured only for AuthenticatedUsers (internal users).

Guest or external users are not included in this group.

Therefore, guest users cannot open the protected documents.

Answer: No

Statement 3: Contoso Confidential will be applied automatically to the files stored in Microsoft SharePoint Online.

Auto-labeling for files and emails = None.

That means labeling must be applied manually by users, not automatically.

Answer: No

Final Verified Answers

If a user account is disabled, the user will be immediately prevented from opening a file protected by Contoso Confidential → Yes

Guest users will be able to open documents protected by Contoso Confidential → No

Contoso Confidential will be applied automatically to the files stored in Microsoft SharePoint Online → No

Step 1 – Requirement

You want to create a custom sensitive info type named Sensitive1.

This SIT will be created from a document fingerprint of Template1.docx.

You then want to use Sensitive1 in DLP policies.

Step 2 – Where do you create custom Sensitive Info Types?

Custom SITs (including document fingerprinting) can only be created in the Microsoft Purview compliance portal.

They cannot be created in the Exchange admin center, SharePoint admin center, or directly in PowerShell.

Answer for creation: The Microsoft Purview portal

You need one Sensitive Information Type (SIT) per distinct information pattern. The minimum set that covers both SharePoint and Exchange is:

Credit Card Number (builtin) – used for documents and email.

UK National Health Service Number (builtin) – used for documents and email.

EU/UK Physical Address (builtin “EU PII: Physical address”).

User credentials (builtin “Credentials”/“User credentials”).

Custom keywordbased SIT for the sensitive project names (“Project Tailspin”, “Project Contoso”, “Project Falcon”) – can be one SIT using a keyword list.

SITs are reusable across locations, so you don’t count duplicates for email and documents.

The Set-MailboxFolderPermission -Identity "User1" -User User1@contoso.com -AccessRights Owner command is incorrect. This assigns folder permissions but does not enable auditing. It does not track who accessed the mailbox or deleted emails.

To test Microsoft Purview Advanced Message Encryption (which relies on Azure Information Rights Management), you use the Test-IRMConfiguration cmdlet. It verifies configuration, template availability, and encryption/decryption status.

Test-OAuthConnectivity → tests OAuth authentication.

Test-ClientAccessRule → tests client access rules.

Test-Mailflow → tests mail routing.

Box 1: Insider Risk Management policies in Microsoft Purview can be configured to detect risky behavior, such as accessing phishing websites. These policies monitor user activity, generate alerts, and help organizations investigate potential security threats.

Box 2: Microsoft Defender Browser Protection extension helps in detecting unsafe or phishing websites and integrating this detection with Insider Risk Management policies. This extension works with Microsoft Edge and Google Chrome to identify risky browsing activity and trigger alerts.

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

Goal: maximize signin security for users who will test the AIP client (User1), install/configure the Microsoft Rights Management connector (User2), and act as the AIP scanner service account (User3).

Excluding users from MFA lowers security and is not recommended.

Passwordless with FIDO2 security keys (passkeys) provides strong phishingresistant authentication and is fully supported for Azure AD signins, including admin tasks and service scenarios that require interactive signin during setup.

Therefore, enabling all three for FIDO2 passkey authentication best meets the “maximize security” requirement.

To ensure that Microsoft Purview Insider Risk Management can detect file deletions, USB copies, and print actions on sensitive information, you must onboard the Windows 11 devices to Microsoft Purview.

Device onboarding enables endpoint activity monitoring, allowing Purview to track and log user activities such as file deletions, USB transfers, and printing of sensitive files. Once onboarded, the Insider Risk Management policy can analyze these activities and generate risk alerts when sensitive information types (SITs) are involved.

Since all employee assessments follow a specific template (AssessmentTemplate.docx), the best way to identify these documents for Data Loss Prevention (DLP) is to create a document fingerprint of that template.

Document fingerprinting allows Microsoft 365 DLP policies to recognize documents based on their structure and format, even when content inside varies (such as different employee names and results). By creating a fingerprint of AssessmentTemplate.docx, any copy derived from that template will be automatically detected by the DLP policy and blocked from being emailed externally.

Steps to implement:

● Create a document fingerprint of AssessmentTemplate.docx using PowerShell and the Microsoft Purview compliance portal.

● Apply a DLP policy to prevent external sharing of documents matching this fingerprint.

● Test the policy by attempting to email an assessment externally.

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.

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.”

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.

Marking Tailspin_scanner.exe as "Unsanctioned" in Microsoft Defender for Cloud Apps only blocks its usage in cloud-based activities (such as accessing SharePoint, OneDrive, or Exchange Online). However, it does not prevent a locally installed application on Windows 11 devices from accessing sensitive files.

To block Tailspin_scanner.exe from accessing sensitive documents while allowing it to access other files, the correct solution is to use Microsoft Purview Endpoint Data Loss Prevention (Endpoint DLP) and add Tailspin_scanner.exe to the Restricted Apps list.

Endpoint DLP allows you to block specific applications from accessing sensitive files while keeping general access available. Restricted Apps List in Endpoint DLP ensures that Tailspin_scanner.exe cannot open, copy, or process protected documents, but it can still function normally for non-sensitive content.

Microsoft 365 Endpoint data loss prevention (Endpoint DLP) is supported only on Windows 10 and Windows 11 devices. It does not support macOS or iOS at this time.

From the provided table:

● Device1 (Windows 11) - Supported

● Device2 (Windows 10) - Supported

● Device3 (iOS) - Not supported

● Device4 (macOS) - Not supported

Thus, only Device1 and Device2 support Endpoint DLP.

In Defender for Cloud Apps file policies, Access level is the filter used to detect how a file is exposed (e.g., Public on the internet, External, Internal, Private). Choosing Access level = External matches files that are shared with users outside your organization—exactly the “shared externally” condition.

Ref: Microsoft Defender for Cloud Apps – Create/Use file policies (File filters: Access level), Microsoft Learn.

See: Microsoft Defender for Cloud Apps > Policies > File policies documentation describing file filters including Access level and its values (Public, External, Internal, Private).

To target files that carry an MIP/AIP classification such as Internal Only, you use the Sensitivity label file filter. Defender for Cloud Apps ingests Microsoft Purview Information Protection labels and lets you build file policies that trigger when a specific label is applied.

Ref: Integrate Microsoft Information Protection with Microsoft Defender for Cloud Apps and File policies – Sensitivity label filter, Microsoft Learn.

These docs explain that MCAS can filter and govern files by Sensitivity label and apply governance based on labels such as Internal Only, Confidential, etc.

Why not the other options?

Collaborators filters by specific users/domains; it’s useful to find files shared with a particular external user but not for the generic “shared externally” condition.

Matched policy is for files already flagged by another policy/DLP engine and does not detect “Internal Only” labeling by itself.