Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains how to create and configure a Data Loss Prevention policy in Microsoft Purview. The policy is designed to identify sensitive information, notify users and administrators, generate alerts, and optionally restrict how protected content is shared or used.
For the SC-200 exam, the main objective is not simply memorizing the policy creation wizard. A Microsoft Security Operations Analyst should understand:
- How Microsoft Purview identifies sensitive data
- How DLP conditions and thresholds affect detection
- The difference between auditing, notifying, and blocking
- How DLP alerts support investigation and response
- How policies apply across Microsoft 365, endpoints, cloud applications, and on-premises repositories
- Why simulation should normally precede enforcement
- How legitimate business exceptions and false positives are handled
DLP is primarily an information protection and compliance capability, but its alerts and activity reports can become part of a broader SOC investigation.
Key Concepts
Microsoft Purview Data Loss Prevention
Microsoft Purview Data Loss Prevention helps organizations identify and control sensitive information as it moves through supported services and devices.
A DLP policy typically defines:
- The sensitive information to detect
- The locations where the policy applies
- The conditions that trigger the policy
- The user notifications or policy tips displayed
- The alerts and incident reports generated
- The activities that are audited, restricted, or blocked
- Whether users can override restrictions
- Whether the policy is simulated or enforced
The objective is to reduce accidental or unauthorized exposure without unnecessarily interrupting legitimate business activity.
Accessing DLP Policies in Microsoft Purview
DLP policies are managed through the Microsoft Purview portal.
Depending on the tenant and portal interface, Data Loss Prevention may appear:
- Directly in the left navigation menu
- Under Information Protection
- Through the Policies section after opening DLP
The exact navigation may differ between newer and older tenants.
Some tenants may already contain Microsoft-provided default policies, such as policies for:
- Microsoft 365 workloads
- Microsoft Teams
- Managed devices
Default policies can be reviewed and modified, but custom policies provide more control over protected data, scope, thresholds, and enforcement.
Templates Versus Custom Policies
When creating a DLP policy, Microsoft Purview provides predefined templates organized by category.
Common categories include:
- Financial
- Medical and health
- Privacy
- Enhanced templates
- Custom
Predefined templates
Templates provide a starting configuration for common regulatory or data-protection requirements.
For example, the U.S. Financial Data template can detect information such as:
- Credit card numbers
- U.S. bank account numbers
- ABA routing numbers
Templates reduce configuration effort and provide Microsoft-defined sensitive information types, confidence settings, and default rules.
Custom policies
A custom policy provides greater flexibility when an organization needs to:
- Use custom sensitive information types
- Combine multiple detection conditions
- Apply organization-specific thresholds
- Protect data not covered by a standard template
- Implement specialized actions or exceptions
Exam decision point
Use a predefined template when the scenario maps to a common data category. Use a custom policy when the organization has unique data patterns or requirements not covered by the available templates.
Administrative Scope
During policy creation, Microsoft Purview may allow the policy to be associated with administrative units.
Administrative units support delegated administration by limiting the administrative scope assigned to certain administrators.
A policy can also be applied across the full directory when no narrower administrative boundary is required.
Administrative scope should not be confused with DLP workload locations. Administrative units affect delegated management, while policy locations determine where the DLP policy evaluates content and activity.
Selecting DLP Locations
A DLP policy must be associated with one or more locations.
Supported locations may include:
- Exchange email
- SharePoint Online
- OneDrive for Business
- Microsoft Teams chats and channel messages
- Managed Windows devices
- Cloud application instances
- On-premises repositories
- Microsoft Fabric
- Power BI
The available locations may depend on licensing, configuration, and tenant capabilities.
Include and exclude options
Policies do not always need to apply tenant-wide. Administrators may be able to include or exclude:
- Specific users
- Groups
- SharePoint sites
- OneDrive accounts
- Other supported resources
This allows the organization to target the policy more precisely.
Example
A policy designed to protect financial records stored in a finance department SharePoint site could be scoped to:
- SharePoint Online
- The finance department site
- Finance-related users or groups
This is generally safer than applying an untested blocking policy to every workload and user.
Sensitive Information Types
Sensitive information types are Microsoft Purview classifiers that identify content matching recognizable data patterns.
Examples include:
- Credit card numbers
- Bank account numbers
- Government identifiers
- Health-related identifiers
- Routing numbers
Detection may use a combination of:
- Pattern matching
- Checksums
- Keywords
- Supporting evidence
- Proximity rules
- Confidence levels
A match does not automatically mean that a security incident has occurred. It means the content met the policy’s configured detection logic.
Confidence Levels
Confidence levels indicate how strongly Microsoft Purview believes that content represents a particular sensitive information type.
Common levels include:
- Low confidence
- Medium confidence
- High confidence
A high-confidence match normally requires more supporting evidence and is less likely to be a false positive.
Exam decision point
Choose a higher confidence level when the organization wants fewer false positives. Choose a lower confidence level when broader detection is more important and the organization is prepared to review additional noise.
Confidence level affects the quality of a match. It is not the same as the number of matches.
Instance Counts
The instance count specifies how many occurrences of a sensitive information type must appear before a rule matches.
For example:
- One credit card number
- Five bank account numbers
- Ten instances of the same sensitive information type
Instance counts can be used to distinguish between isolated activity and bulk exposure.
Example
An email containing one credit card number may represent a legitimate customer-support interaction. An email containing fifty credit card numbers may indicate a much greater risk.
The correct threshold depends on business requirements, regulatory obligations, and the expected use of sensitive data.
Exam trap
Do not confuse instance count with confidence level:
- Confidence level evaluates the quality of each detected match.
- Instance count evaluates how many matching items are present.
DLP Rules and Conditions
A policy can contain one or more rules. Each rule defines the conditions and actions associated with a particular type or volume of sensitive information.
Conditions may examine:
- Sensitive information type
- Confidence level
- Number of detected instances
- Whether content is shared internally or externally
- The workload or location involved
- The activity being attempted
Templates provide default rule settings, but administrators can review and customize them.
A policy should be designed so that the rule conditions are specific enough to detect meaningful risk without generating excessive false positives.
Policy Tips and User Notifications
Policy tips notify users when their actions may violate a DLP policy.
Depending on the workload, policy tips may appear in applications such as:
- Outlook
- SharePoint
- OneDrive
- Other supported Microsoft 365 applications
Policy tips can help users correct risky behavior before data leaves the organization.
Customizable elements
Administrators may be able to customize:
- Notification title
- Notification text
- Email subject
- Sender display name
- Email body
- Hyperlinks
- Compliance or training URL
- Recommended user actions
A compliance URL can direct users to internal guidance, a SharePoint knowledge base, or an organizational data-handling policy.
Exchange-specific behavior
Microsoft Purview can display a dialog before sending an email in Exchange-supported scenarios.
This type of pre-send interaction should not be assumed to apply to every workload.
Important distinction
A policy tip is a user-awareness control. It does not necessarily mean that the action is blocked.
A policy can:
- Notify only
- Allow but audit
- Allow an override
- Restrict the activity
- Block the activity
Notification Recipients
Notifications may be sent to:
- The user who sent, shared, or last modified the content
- The SharePoint site owner
- The OneDrive account owner
- The content owner
- Additional administrators or designated recipients
Additional recipients can help operational teams receive visibility into DLP activity.
However, organizations should avoid sending sensitive matched content to unnecessarily broad distribution lists.
User Actions in Notifications
Depending on the workload and configuration, a DLP notification may allow actions such as:
- Stop sharing a file
- Delete a file
- Override the restriction
- Apply a sensitivity or retention label
- Report a false positive
These actions support user remediation but should be configured carefully.
A user should not be given the ability to bypass an important regulatory control without a documented business reason.
Incident Reports
DLP incident reports provide detailed information about policy matches.
Information may include:
- The user involved
- The sensitive information type
- The matching rule
- The rule severity
- The content or evidence that matched
- The item containing the matching content
- The workload where the activity occurred
Incident reports may be sent to designated administrators or other recipients.
In the configuration covered by this lesson, incident reports are supported for activity in:
- Exchange
- SharePoint
- OneDrive
- Microsoft Teams
Operational use
A DLP incident report gives an analyst context for initial triage. The analyst must still determine:
- Whether the activity was legitimate
- Whether the match was accurate
- Whether sensitive information was actually exposed
- Who received or accessed the information
- Whether containment is required
DLP Alerts
DLP alerts notify security or compliance personnel when a DLP rule matches.
Alert behavior can be configured to:
- Generate an alert for every matching activity
- Generate alerts only after a threshold is reached
- Send alerts based on the volume of activity
- Notify additional administrators or response teams
Incident reports versus alerts
| Feature | Primary Purpose |
|---|---|
| Policy tip | Warn or guide the end user |
| Email notification | Inform a user or administrator |
| Incident report | Provide detailed information about the policy match |
| Alert | Notify operational personnel that a rule requires review |
| Activity report | Support monitoring, reporting, and trend analysis |
An alert is the operational signal. An incident report provides supporting detail.
Restricting Access and Encrypting Content
A DLP policy can restrict access to protected content in supported Microsoft 365 locations.
Possible actions include:
- Block sending an email
- Block a Teams chat or channel message
- Restrict access to a SharePoint file
- Restrict access to a OneDrive file
- Block external recipients
- Encrypt supported content
A common configuration is to block only people outside the organization while allowing internal business activity.
Least disruptive enforcement
When possible, enforcement should be proportional to the risk.
For example:
- Low-risk internal activity may be audited.
- External sharing may require justification.
- High-volume exposure may be blocked.
- Confirmed regulated data may require encryption or access restriction.
Overrides and Business Justification
A policy can allow users to override a restriction after seeing a policy tip.
Overrides may require the user to provide a justification.
Appropriate use cases include:
- A legitimate business process
- An incorrectly classified item
- A false positive
- An approved exception
Overrides provide flexibility, but they also create risk.
The organization should retain and review:
- The identity of the user
- The content involved
- The reason provided
- The action performed
- Whether repeated overrides indicate a policy problem
Exam decision point
When the business must occasionally permit an otherwise restricted action, use an override with required justification rather than disabling the policy entirely.
Endpoint DLP
Endpoint DLP extends data protection controls to supported devices.
When protected files are used on an endpoint, a policy can audit or restrict activities such as:
- Uploading a file to a cloud service
- Copying protected content
- Pasting content into supported browsers
- Performing file-related actions
- Using restricted applications
- Transferring information through unauthorized channels
Audit versus restrict
Endpoint activity can be configured as:
- Audit only
- Audit with user notification
- Restrict
- Block
Audit mode records the activity without stopping the user. Restriction mode actively prevents the configured activity.
Exam trap
An endpoint DLP rule configured only for auditing does not block the activity.
Restricted Applications and Application Groups
Endpoint DLP can apply different controls based on the application being used.
Administrators may configure:
- Restricted applications
- Application groups
- Browser-related controls
- Different restrictions for different application categories
This can help prevent users from moving protected data from approved business applications into unapproved applications.
Application-specific controls should be tested carefully because broad restrictions can interfere with normal business processes.
Defender for Cloud Apps Integration
Microsoft Defender for Cloud Apps can provide additional control over supported third-party cloud and web applications.
When the integration and required licensing are available, DLP-related controls may be used to restrict how sensitive content is handled in third-party applications.
This supports cloud access security broker capabilities for environments where sensitive data moves outside Microsoft 365.
Exam decision point
Use Microsoft Purview DLP to define sensitive-data protection requirements. Use Defender for Cloud Apps when the scenario requires session or access controls for supported third-party cloud applications.
On-Premises Repositories
Microsoft Purview may also support discovering or protecting data stored in connected on-premises repositories.
Possible actions can include:
- Auditing access
- Restricting access
- Removing or remediating files
- Applying policy conditions to connected repositories
These capabilities require additional configuration and should not be assumed to function automatically just because an on-premises location appears in the policy wizard.
Policy Modes
A DLP policy can generally be placed into one of several operational states.
Simulation mode
Simulation mode evaluates activity without immediately applying full enforcement.
It can be used to:
- Identify expected matches
- Measure false-positive rates
- Review affected users and workloads
- Validate rule thresholds
- Determine operational impact
- Tune the policy before blocking activity
Policy tips may optionally be displayed while the policy is in simulation.
The wizard may also provide an option to enable the policy automatically after a specified simulation period if no changes are made.
Turn the policy on immediately
This begins active enforcement after the policy is processed and distributed.
Immediate enforcement may be appropriate when:
- The rule has already been tested
- The risk is urgent
- The scope is narrow
- The control is required by policy or regulation
- The organization understands the operational impact
Leave the policy off
This saves the configuration without evaluating or enforcing it.
This may be useful when the policy is still being reviewed or must go through formal change approval.
Why Simulation Is Recommended
DLP conditions can match legitimate business data.
Activating a blocking policy without testing can cause:
- Email delivery failures
- Blocked collaboration
- SharePoint or OneDrive access issues
- Disruption to financial or customer-support processes
- Excessive alerts
- Help desk incidents
- User attempts to bypass controls
Simulation provides evidence that can be used to tune the policy before enforcement.
From a security operations perspective, simulation is similar to running a detection rule in audit mode before enabling automated containment.
Policy Propagation
A newly created or changed DLP policy may not become effective immediately.
Administrators should plan for a propagation period before validating the policy. The lesson described a typical delay of approximately 30 to 60 minutes, with potentially longer delays in some trial environments.
During testing, do not assume the policy failed simply because it does not trigger immediately.
Record:
- The time the policy was submitted
- The selected policy mode
- The workloads included
- The test data used
- The time the expected behavior was observed
Microsoft Security Operations Context
How DLP Fits into a SOC Workflow
DLP supports a SOC by generating evidence and alerts related to potentially unsafe handling of sensitive information.
A practical workflow may look like this:
1. Receive the alert
The analyst reviews:
- The DLP policy
- The matching rule
- The user
- The workload
- The sensitive information type
- The instance count
- The severity
- The attempted action
2. Validate the match
Determine whether the detected data is genuinely sensitive.
Review:
- The confidence level
- Supporting evidence
- The number of matches
- The file or message context
- Whether the user reported a false positive
3. Determine exposure
Identify whether the information:
- Remained internal
- Was shared externally
- Was blocked before transmission
- Was downloaded or copied
- Was made accessible through a link
- Was sent to an unauthorized recipient
4. Review entities
Relevant entities may include:
- User account
- Mailbox
- External recipient
- SharePoint site
- OneDrive account
- Device
- File
- IP address
- Cloud application
5. Establish business context
Determine:
- The user’s role
- Whether the recipient was approved
- Whether the action was part of a known process
- Whether an exception was documented
- Whether the user has generated similar alerts before
6. Contain the activity
Depending on the risk and available actions:
- Stop file sharing
- Restrict access
- Remove an external link
- Block the activity
- Encrypt the content
- Contact the user
- Escalate to compliance, privacy, legal, or management
7. Preserve evidence
Document:
- The alert and rule
- Matched sensitive information type
- User and recipient
- File or message identifier
- Timeline
- Override justification
- Actions taken
- Analyst conclusion
Avoid unnecessarily copying sensitive content into tickets or chat systems.
8. Improve future detection
After the investigation, the organization may:
- Adjust confidence levels
- Change instance thresholds
- Add exclusions
- Narrow the policy scope
- Expand the policy to additional locations
- Improve user training
- Modify notification text
- Change alert thresholds
- Remove unnecessary override permissions
Escalation Paths
A DLP alert may require coordination with:
- Compliance
- Privacy
- Legal
- Human resources
- Data owners
- Microsoft 365 administrators
- Endpoint security
- Identity security
- Cloud security
- Incident response
- Business leadership
The SOC should not make regulatory or legal determinations without involving the appropriate stakeholders.
Exam-Relevant Takeaways
- Microsoft Purview is the primary portal for creating and managing Microsoft 365 DLP policies.
- Templates provide predefined sensitive information types and rule settings.
- Custom policies are appropriate for organization-specific data or conditions.
- Locations determine where the policy evaluates activity.
- Administrative units relate to delegated administrative scope.
- Confidence level measures the strength of a sensitive-data match.
- Instance count measures the number of detected occurrences.
- Policy tips warn users but do not automatically mean the action is blocked.
- Incident reports provide detailed match information.
- Alerts notify administrators or operational teams that review may be required.
- A policy can audit, notify, allow an override, restrict, encrypt, or block.
- Overrides should normally require business justification.
- Endpoint DLP can audit or restrict device-based file and data activity.
- Defender for Cloud Apps is relevant when applying controls to supported third-party cloud applications.
- Simulation mode should normally be used before full enforcement.
- Policy changes may require time to propagate.
- Pre-send dialog behavior described in the policy wizard is specific to Exchange-supported scenarios.
- Incident-report support and available actions vary by workload.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| Detect credit card and bank account information | Purview DLP financial template | Includes predefined financial sensitive information types |
| Protect an organization-specific customer identifier | Custom DLP policy and custom sensitive information type | Standard templates may not recognize proprietary data |
| Test the impact of a policy before blocking users | DLP simulation mode | Evaluates matches without immediately enforcing all restrictions |
| Warn a user before sending sensitive data | Policy tip | Provides user-facing guidance at the point of activity |
| Allow an approved exception | Override with required justification | Preserves flexibility while recording the reason |
| Notify the SOC when a rule matches | DLP alert | Creates an operational signal for investigation |
| Provide detailed evidence about a match | DLP incident report | Includes rule, user, content, and item details |
| Stop external access to a sensitive SharePoint file | Restrict access in the DLP rule | Prevents unauthorized external access |
| Monitor copying or uploading protected files from a device | Endpoint DLP | Evaluates protected-file activity on supported endpoints |
| Apply controls to supported third-party web applications | Defender for Cloud Apps integration | Extends control to supported non-Microsoft cloud applications |
| Apply different controls to departments or resources | Include and exclude policy scope | Limits impact and aligns controls with business requirements |
| Reduce false positives | Raise confidence or instance thresholds | Requires stronger evidence before triggering |
| Detect smaller amounts of exposed data | Lower instance threshold | Causes the rule to match with fewer occurrences |
| Preserve a policy without running it | Leave the policy off | Saves configuration without evaluation or enforcement |
| Apply controls immediately for an urgent requirement | Turn the policy on | Begins enforcement after processing and propagation |
KQL Notes
No KQL query was demonstrated in this lesson.
The focus was policy configuration in Microsoft Purview rather than querying Microsoft Sentinel or Defender data.
For the SC-200 exam, remember that KQL may be used in Microsoft Sentinel or advanced hunting to investigate related activity after an alert is generated. However, the DLP policy itself is configured through Purview conditions, sensitive information types, thresholds, locations, and actions rather than through a KQL query.
Do not choose a hunting query when the scenario specifically asks how to create a preventive data-handling control. The correct answer is more likely to involve a Purview DLP policy.
Common Exam Traps
Confusing a policy tip with enforcement
A policy tip warns the user. Blocking must be configured separately.
Confusing confidence with instance count
Confidence evaluates match quality. Instance count evaluates match quantity.
Enabling the policy immediately without testing
Simulation is generally the safer first step when operational impact is unknown.
Assuming all workloads support identical actions
Exchange, SharePoint, OneDrive, Teams, endpoints, and third-party applications have different capabilities.
Assuming an audit action blocks the user
Audit records the activity. It does not prevent it.
Disabling a policy to support one legitimate exception
Use an override with justification or a targeted exclusion when appropriate.
Applying a policy to the wrong location
A policy cannot protect a workload that is not selected and properly configured.
Treating DLP alerts as proof of malicious activity
A DLP match may result from user error, legitimate business activity, or a false positive.
Assuming immediate policy activation
Policy creation and changes require propagation time.
Selecting Defender for Endpoint alone for third-party cloud application control
Endpoint DLP protects device activities. Defender for Cloud Apps is relevant when the requirement involves supported third-party cloud sessions or applications.
Exposing sensitive evidence in the incident process
Analysts should not paste full credit card numbers, banking details, or other sensitive values into tickets.
Real-World SOC Analyst Notes
Alert fatigue
Generating an alert for every low-confidence match can overwhelm the SOC.
Consider:
- Threshold-based alerts
- Higher-confidence conditions
- Workload-specific policies
- Narrower scope
- Separate rules for low- and high-risk activity
False positives
False positives are inevitable when pattern-based detection is used.
Analysts should distinguish between:
- A valid sensitive-data match
- A false pattern match
- A legitimate approved transfer
- A true policy violation
- Suspicious or malicious exfiltration
Evidence preservation
Record enough information to support the investigation without unnecessarily duplicating sensitive data.
Use identifiers and masked values when possible.
Automation safety
Automated actions such as deleting files, removing access, or blocking business communication can have significant impact.
Use:
- Simulation
- Audit-only deployment
- Narrow pilot groups
- Change control
- Defined rollback procedures
- Human approval for destructive actions
Tenant-wide impact
A broadly scoped DLP policy can affect every user in Exchange, SharePoint, OneDrive, and Teams.
Start with limited scope unless immediate tenant-wide enforcement is justified.
Access permissions
Only authorized administrators should be able to:
- Create policies
- Modify conditions
- Change enforcement
- Review matched content
- Receive incident reports
- Approve policy exceptions
DLP reports may contain highly sensitive information.
Data retention
The organization should understand how long it retains:
- DLP alerts
- Audit activity
- Incident reports
- Override justifications
- Investigation records
Retention should align with regulatory, legal, and internal requirements.
Cost considerations
Microsoft Sentinel costs are normally driven by data ingestion and retention. Purview DLP policy evaluation is not configured by writing Sentinel queries.
When forwarding or ingesting related alerts into a SIEM, evaluate whether the additional data provides enough operational value to justify ingestion and retention costs.
Change control
A DLP policy should be treated as a production security control.
Document:
- Business requirement
- Data owner
- Policy scope
- Sensitive information types
- Thresholds
- Enforcement actions
- Exceptions
- Test results
- Approval
- Rollback plan
Quick Reference Summary
- Create DLP policies in Microsoft Purview.
- Use templates for standard financial, health, and privacy data.
- Use custom policies for organization-specific requirements.
- Select the workloads where the policy must apply.
- Confidence measures match quality.
- Instance count measures match volume.
- Policy tips notify users.
- Alerts notify operational personnel.
- Incident reports provide detailed evidence.
- Audit observes activity without blocking it.
- Restrict or block only after evaluating business impact.
- Use justification-based overrides for approved exceptions.
- Endpoint DLP protects data used on managed devices.
- Defender for Cloud Apps extends control to supported third-party applications.
- Run new policies in simulation mode before enforcement.
- Allow time for policy propagation.
- Review false positives and tune the policy after deployment.
Flashcards
Q: Which Microsoft portal is used to create a Microsoft 365 DLP policy?
A: Microsoft Purview.
Q: What is the primary advantage of a predefined DLP template?
A: It provides preconfigured sensitive information types, conditions, and default rule settings for a common data category.
Q: When should a custom DLP policy be used?
A: When the organization needs to protect proprietary data or use conditions not covered by a standard template.
Q: What does a confidence level represent?
A: How strongly Microsoft Purview believes that detected content matches a sensitive information type.
Q: What does an instance count represent?
A: The number of occurrences of a sensitive information type required for a rule to match.
Q: Does displaying a policy tip automatically block the user?
A: No. Notification and enforcement are configured separately.
Q: What is the purpose of a DLP incident report?
A: To provide detailed information about the user, rule, sensitive content, and item involved in a match.
Q: What is the purpose of a DLP alert?
A: To notify administrators or operational teams that a policy rule matched and may require investigation.
Q: What is the difference between audit and block?
A: Audit records the activity, while block prevents the activity.
Q: What should normally be used before enabling a new blocking DLP policy?
A: Simulation mode.
Q: Why require justification for a policy override?
A: It allows legitimate exceptions while recording the user’s reason for bypassing the restriction.
Q: Which capability protects sensitive files during actions performed on managed devices?
A: Endpoint DLP.
Q: Which Microsoft product is relevant for controlling sensitive data in supported third-party cloud applications?
A: Microsoft Defender for Cloud Apps.
Q: What can be used to reduce excessive false positives?
A: Higher confidence levels, higher instance thresholds, exclusions, or narrower policy scope.
Q: Why might a newly created DLP policy not trigger immediately?
A: The policy may still be propagating across the selected services.
Practice Questions
Question 1:
A company wants to prevent employees from sending U.S. bank account and routing information outside the organization. The security team must first determine how many legitimate business messages would be affected.
What should the administrator do first?
A. Enable the policy immediately and block all users
B. Run the policy in simulation mode
C. Create a Microsoft Sentinel workbook
D. Isolate all devices that contain financial records
Correct Answer:
B. Run the policy in simulation mode
Explanation:
Simulation mode evaluates matches and helps identify false positives and business impact before enforcement is enabled.
Question 2:
A DLP rule detects a single high-confidence credit card number in an email. The organization wants the user to be warned but does not want to block the email.
Which action should be configured?
A. Display a policy tip
B. Restrict access to the mailbox
C. Delete the email automatically
D. Isolate the user’s endpoint
Correct Answer:
A. Display a policy tip
Explanation:
A policy tip warns the user about the sensitive information. Blocking is a separate enforcement decision.
Question 3:
Employees occasionally need to send protected financial information to an approved external auditor. The company wants the transfer to remain possible, but the employee must explain the business reason.
Which configuration should be used?
A. Disable the DLP policy for all external recipients
B. Allow an override with required justification
C. Lower the sensitive information confidence level
D. Configure the rule for audit only
Correct Answer:
B. Allow an override with required justification
Explanation:
A justification-based override permits legitimate exceptions while recording why the user bypassed the restriction.
Question 4:
An organization wants to monitor attempts to upload protected files from managed Windows devices without initially preventing the uploads.
Which configuration is most appropriate?
A. Endpoint DLP in audit mode
B. Exchange pre-send notification
C. Microsoft Sentinel automation rule
D. Defender for Identity sensor
Correct Answer:
A. Endpoint DLP in audit mode
Explanation:
Endpoint DLP evaluates protected-file activities on supported endpoints. Audit mode records the activity without blocking it.
Question 5:
A company needs to restrict the handling of sensitive files in supported third-party cloud applications.
Which Microsoft security capability should be included in the solution?
A. Microsoft Defender for Identity
B. Microsoft Defender for Cloud Apps
C. Microsoft Defender for Office 365 Safe Links
D. Microsoft Sentinel watchlists
Correct Answer:
B. Microsoft Defender for Cloud Apps
Explanation:
Defender for Cloud Apps provides cloud access security broker capabilities that can extend control to supported third-party cloud applications.