Microsoft Purview DLP Policy Priority and Rule Precedence – SC-200 Study Guide

Purpose of This Lesson

This lesson explains how Microsoft Purview Data Loss Prevention handles precedence when multiple DLP policies or rules could apply to the same activity.

There are two separate concepts to understand:

1. Policy priority determines precedence between different DLP policies.
2. Rule restrictiveness determines the effective result when rules within a policy conflict.

The most important distinction is that Microsoft Purview DLP treats a lower policy priority number as a higher priority. A policy assigned priority 0 takes precedence over a policy assigned priority 1, 2, or another higher number.

Although Microsoft Purview DLP is primarily associated with compliance and information protection, security operations analysts may encounter its alerts and incidents while investigating attempted data exfiltration, unauthorized sharing, insider risk, or mishandling of sensitive information.

---

Key Concepts

Microsoft Purview Data Loss Prevention

Microsoft Purview DLP helps organizations identify, monitor, and protect sensitive information across supported Microsoft services and endpoints.

A DLP policy can detect content such as:

• Financial information
• Personal identification data
• Health-related information
• Payment card data
• Organization-specific sensitive information

A policy can then perform actions such as:

• Displaying a policy tip to the user
• Sending an email notification
• Generating an administrative alert
• Creating an incident report
• Restricting or blocking the activity
• Allowing an override under configured conditions

DLP policies are managed from the Microsoft Purview portal.

A typical navigation path is:

Microsoft Purview portal → Data Loss Prevention → Policies

Portal navigation changes periodically, but the DLP policies page is where administrators create, edit, prioritize, test, enable, and monitor DLP policies.

---

The Two Layers of DLP Precedence

DLP precedence must be considered at two different levels.

Precedence Layer	What It Controls
Policy priority	Determines which policy has higher precedence when multiple policies are relevant
Rule restrictiveness	Determines the effective action when applicable rules conflict

These concepts should not be treated as interchangeable.

Policy priority compares separate policies. Rule restrictiveness determines what happens when rules within a policy produce overlapping or conflicting outcomes.

---

DLP Policy Priority

Each DLP policy is assigned a numerical priority.

For DLP policies:

The lower the number, the higher the priority.

For example:

Policy	Priority	Relative Precedence
UK Financial Data	0	Highest
US Financial Data	1	Lower than priority 0
General Sensitive Information	2	Lower than priorities 0 and 1

A policy with priority 0 has higher precedence than a policy with priority 1.

This numbering system can be confusing because some other Microsoft features use different priority conventions. Do not assume that a larger number means a higher priority.

Changing Policy Priority

From the DLP policies page, an administrator can use the policy menu to:

• Move a policy up
• Move a policy down
• Move it to the highest priority
• Move it to the lowest priority

Moving a policy to the highest position assigns it the lowest priority number, normally 0.

Example

Assume the following order:

• US Financial Data: priority 0
• UK Financial Data: priority 1

If the UK Financial Data policy is moved to the highest priority, the order becomes:

• UK Financial Data: priority 0
• US Financial Data: priority 1

The UK policy now has higher precedence.

---

Why Policy Priority Matters

Multiple DLP policies may cover overlapping:

• Users
• Groups
• Administrative units
• Locations
• Sensitive information types
• Applications
• Devices
• Sharing activities

For example, an organization could have:

• A broad company-wide financial data policy
• A stricter policy for the finance department
• A policy covering UK financial information
• A policy covering US financial information

Without deliberate prioritization, overlapping policies may produce results that are difficult to predict or administer.

Priority should reflect the organization’s intended governance model. More specific or more critical policies are often positioned above broad baseline policies, although the correct design depends on the organization’s requirements.

---

Creating a DLP Policy from a Template

Microsoft Purview provides templates for common regulatory and data-protection scenarios.

The lesson uses a financial data template to create a policy for UK financial information.

A typical policy creation workflow includes:

1. Select a template or create a custom policy.
2. Name and describe the policy.
3. Assign administrative units when required.
4. Select the locations where the policy applies.
5. Configure policy settings.
6. Review the generated rules.
7. Select a testing or activation mode.
8. Submit the policy.

Templates provide a starting configuration, but they should not automatically be treated as production-ready.

Administrators should review:

• Included sensitive information types
• Confidence levels
• Instance counts
• User and group scope
• Locations
• Notifications
• Policy tips
• Alert settings
• Incident report recipients
• Restriction actions
• Override behavior

---

Administrative Units

The policy creation wizard can include an option to assign administrative units.

Administrative units can be used to scope administration to a subset of the organization. This may be useful when different administrators are responsible for different:

• Departments
• Geographic regions
• Business units
• Subsidiaries

Administrative units relate to delegated administration. They are not the same as the users, groups, or locations protected by the policy.

An exam scenario may distinguish between:

• Who can administer the policy
• Which users or workloads the policy protects

These are separate design decisions.

---

Choosing DLP Locations

A DLP policy must be configured for supported locations.

Depending on licensing and configuration, locations may include Microsoft 365 services and managed endpoints.

The locations selected during policy creation determine where the policy can inspect and enforce activity.

A DLP policy cannot protect data in a workload that is outside its configured scope or not supported by the DLP feature.

This creates an important operational decision:

Before troubleshooting a DLP policy that did not trigger, verify that the affected workload or location is included in the policy.

---

DLP Simulation Mode

The example policy is initially configured to use simulation.

Simulation allows administrators to evaluate policy behavior before fully enforcing restrictions.

Simulation is useful for identifying:

• How frequently the policy would match
• Which users and workloads would be affected
• Potential false positives
• Unexpected overlap with existing policies
• Whether thresholds are too broad
• Whether business processes would be interrupted

Simulation is generally safer than immediately enabling a restrictive policy across the organization.

Why Simulation Matters Operationally

A DLP policy can affect legitimate business processes. A poorly designed rule could prevent users from:

• Sharing approved financial documents
• Sending information to a trusted partner
• Copying files to an approved location
• Completing a required business workflow

Simulation provides evidence that can be reviewed before enforcement begins.

It should be treated as part of change validation rather than as an optional administrative step.

---

Rules Within a DLP Policy

A single DLP policy can contain multiple rules.

Template-based policies commonly create rules for different data volumes or risk levels.

For example:

Rule	Sensitive Information Count	Example Response
Low-volume detection	1–4 instances	Notify the user
High-volume detection	5 or more instances	Notify the user and alert administrators

The low-volume rule represents a lower-risk match. It may provide:

• Email notification
• A policy tip
• User education

The high-volume rule represents a potentially more serious event. It may also:

• Send an incident report
• Generate an administrative alert
• Notify security or compliance personnel
• Apply stronger restrictions

The exact actions depend on the template and administrator configuration.

---

Instance Counts and Thresholds

DLP rules can use instance counts to distinguish between isolated and high-volume exposure.

An instance count refers to how many matching sensitive-information occurrences are found in the evaluated content.

For example:

• One document containing two matching financial identifiers may meet a 1–4 condition.
• A file containing six matching identifiers may meet a 5 or more condition.

Thresholds help organizations avoid treating every event as equally severe.

This supports risk-based handling:

• A low-volume event may require education.
• A high-volume event may indicate bulk data transfer or exfiltration.
• Repeated events may justify escalation even when each individual event appears small.

The analyst should evaluate the threshold together with the affected user, data type, destination, and business context.

---

Rule Conflict Behavior

When applicable rules conflict, the lesson’s key principle is:

The most restrictive applicable result takes effect.

For example, suppose two applicable rules produce the following actions:

• Rule A displays a warning.
• Rule B blocks the activity.

The blocking action is more restrictive and therefore governs the effective result.

Another example:

• Rule A allows the user to override.
• Rule B blocks without override.

The non-overridable block is more restrictive.

This behavior helps prevent a less restrictive rule from weakening a stronger protection requirement.

Restrictiveness Is Different from Policy Priority

Do not confuse these two principles:

• Policy priority: Lower number means higher policy priority.
• Rule conflict: The more restrictive applicable action takes effect.

A policy can have the highest numerical precedence while still containing multiple rules with different conditions and actions.

---

Understanding “Most Restrictive”

Actions can generally be viewed along a progression such as:

1. Audit or record the activity
2. Notify the user
3. Display a policy tip
4. Generate an administrative alert
5. Require business justification
6. Allow override with justification
7. Restrict the activity
8. Block the activity without override

This list is conceptual rather than a complete Microsoft enforcement matrix. Exact behavior depends on the workload, policy configuration, licensing, and supported action.

The important exam concept is that a stronger protective action is not normally weakened by a less restrictive overlapping rule.

---

Microsoft Security Operations Context

How DLP Fits into a SOC Workflow

DLP is not only a compliance control. It can also provide security telemetry related to:

• Data exfiltration
• Insider threats
• Compromised accounts
• Unauthorized cloud sharing
• Bulk transfer of sensitive files
• Sensitive data copied to removable media
• Sensitive information sent through email
• Repeated policy violations

A security operations analyst may not be the administrator who creates the policy, but the analyst may investigate the alert or incident it generates.

---

Example SOC Investigation Workflow

1. Triage the DLP Alert

Review:

• Alert severity
• Triggered policy
• Triggered rule
• Sensitive information type
• Number of detected instances
• Affected user
• Source workload
• Destination
• Timestamp
• Whether the action was allowed or blocked

Determine whether the alert represents:

• A normal business process
• Accidental handling
• Policy testing
• Repeated negligence
• Malicious behavior
• Activity from a compromised account

2. Review the User Entity

Investigate the user associated with the event.

Relevant questions include:

• Is the user authorized to handle the data?
• Is the destination approved?
• Has the user triggered similar alerts before?
• Did the user recently change roles?
• Is the user leaving the organization?
• Are there suspicious sign-ins?
• Is the account showing impossible travel or unfamiliar device activity?

DLP evidence should be correlated with identity and endpoint telemetry when possible.

3. Review the Device or Workload

Determine where the activity occurred:

• Exchange Online
• SharePoint Online
• OneDrive
• Teams
• A managed Windows endpoint
• Another supported location

The source workload determines which team and tools may be needed for further investigation.

4. Determine Scope and Impact

Assess:

• What data was involved
• How many items were affected
• Whether the data left the organization
• Whether the action was blocked
• Who received or accessed the data
• Whether the event was isolated or repeated
• Whether multiple policies or rules matched

A high-volume rule should generally receive more scrutiny than an isolated low-volume notification.

5. Contain or Remediate

Possible actions may include:

• Revoking an external sharing link
• Removing access to a file
• Disabling or resetting a compromised account
• Isolating an affected endpoint
• Blocking a destination
• Escalating to compliance, legal, HR, or insider-risk personnel
• Updating the DLP rule
• Increasing the policy’s priority
• Moving the policy into enforcement after successful simulation

The response must be proportional to the evidence.

6. Document the Investigation

Record:

• Policy and rule names
• Policy priority
• Triggered conditions
• Sensitive information involved
• User and device details
• Destination
• Effective enforcement action
• Analyst findings
• Containment actions
• Escalations
• False-positive determination
• Recommended tuning

Good documentation helps distinguish a one-time business exception from an ongoing control weakness.

7. Improve Future Detection

Post-incident improvements may include:

• Adjusting instance counts
• Changing sensitive information types
• Modifying confidence levels
• Narrowing or expanding user scope
• Changing locations
• Revising notification text
• Increasing alert severity
• Reordering policy priority
• Adding stronger actions to high-volume rules
• Extending simulation
• Creating a documented exception process

---

Policy Priority Design Considerations

Priority should be deliberately planned rather than adjusted only after a conflict occurs.

Specific Policies Versus General Policies

A common design pattern is:

• Higher priority for narrowly scoped, high-risk policies
• Lower priority for broader baseline policies

For example:

Policy	Suggested Relative Priority
Executive financial data restriction	Highest
Finance department DLP policy	High
Organization-wide financial data policy	Lower
General user notification policy	Lowest

This allows specialized controls to take precedence over broad defaults.

However, administrators must test the actual policy behavior rather than relying only on naming or assumed order.

---

Governance and Change Control

Changing DLP priority can affect enforcement throughout the tenant.

Before reordering policies:

1. Identify overlapping users, groups, and locations.
2. Compare rule conditions.
3. Compare enforcement actions.
4. Review existing exceptions.
5. Test the proposed order.
6. Document the reason for the change.
7. Obtain approval where required.
8. Monitor alerts after implementation.

Moving a policy to priority 0 should not be treated as a harmless cosmetic change.

It can alter how overlapping controls are applied and may affect a large number of users.

---

Exam-Relevant Takeaways

For an exam-style scenario, remember the following:

• DLP policies are administered through Microsoft Purview.
• The DLP policies page shows the priority order.
• A lower priority number represents a higher priority.
• Priority 0 is the highest policy priority.
• Administrators can move policies up, down, to the top, or to the bottom.
• A DLP policy can contain multiple rules.
• Templates may create separate low-volume and high-volume rules.
• Instance counts determine which threshold condition is met.
• High-volume rules usually generate stronger responses than low-volume rules.
• When rules conflict, the most restrictive applicable result takes effect.
• Simulation should be used to evaluate impact before broad enforcement.
• Policy priority and rule restrictiveness are separate concepts.
• DLP alerts may contribute to investigations involving data exfiltration, insider risk, compromised identities, or mishandling of sensitive information.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Create or edit a DLP policy	Microsoft Purview DLP	DLP policies are configured and administered in Purview
Change which DLP policy has higher precedence	DLP policy priority controls	Policies can be moved up or down in the priority list
Make a policy the highest priority	Move to highest priority	The policy is assigned the lowest priority number, normally 0
Test a new DLP policy without immediately enforcing restrictions	Simulation mode	Shows expected matches and impact before full enforcement
Respond differently to small and large amounts of sensitive data	Separate rules with instance-count conditions	Thresholds allow different actions based on detected volume
Resolve overlapping rule outcomes	Most restrictive applicable action	Stronger protection takes precedence over a weaker action
Investigate whether a DLP event is connected to a compromised user	Microsoft Defender XDR and identity telemetry	Provides broader context about sign-ins, devices, alerts, and related activity
Investigate endpoint-based sensitive data movement	Endpoint DLP and endpoint security telemetry	Shows activity associated with the user and managed device
Correlate DLP activity with other enterprise security events	Microsoft Sentinel, when the relevant data is connected	Provides cross-source analytics, hunting, and incident management
Identify repeated DLP policy violations	Purview alerts, reports, and audit information	Helps establish patterns and determine whether tuning or escalation is required
Delegate administration by department or region	Administrative units	Limits which administrators manage scoped resources or policies
Determine why a policy did not trigger in a workload	Review policy locations and scope	The affected workload must be included and supported

---

KQL Notes

The lesson does not demonstrate Kusto Query Language.

KQL is not used to define DLP policy priority or rule precedence. These settings are configured through Microsoft Purview.

KQL may still be relevant when DLP-related data is available in Microsoft Sentinel, Microsoft Defender XDR advanced hunting, or another connected log source. An analyst could then use KQL to correlate DLP activity with identity, endpoint, or email events.

The exam distinction is:

• Use Microsoft Purview configuration to change DLP policies and priority.
• Use KQL-based hunting or analytics to investigate and correlate security telemetry when the appropriate data is available.

Do not select a KQL query as the solution to a question that asks how to reorder DLP policies.

---

Common Exam Traps

Trap 1: Assuming a Higher Number Means Higher Priority

For DLP policies, priority 0 is higher than priority 1.

The correct rule is:

Lower number = higher DLP policy priority.

Trap 2: Confusing Policy Priority with Rule Restrictiveness

Policy priority compares separate DLP policies.

Rule restrictiveness determines the effective outcome of overlapping rules.

These are different precedence mechanisms.

Trap 3: Treating the First-Created Policy as Permanently Highest

Policies can be reordered after creation. Creation date does not permanently determine precedence.

Trap 4: Immediately Enabling a Restrictive Policy

A production-wide restrictive DLP policy can disrupt legitimate business activity.

Simulation is the safer first step when validating a new policy.

Trap 5: Assuming a Template Requires No Review

Templates are starting points. Their thresholds, data types, notifications, and actions still require validation.

Trap 6: Ignoring Instance Counts

Low-volume and high-volume rules may detect the same category of information but apply different actions based on the number of matches.

Trap 7: Expecting a Notification Rule to Override a Blocking Rule

When applicable rules conflict, the more restrictive result governs the effective outcome.

Trap 8: Using Microsoft Sentinel to Configure DLP Policy Priority

Sentinel can help investigate and correlate events, but DLP policy ordering is configured in Microsoft Purview.

Trap 9: Assuming Administrative Units Define the Data Location

Administrative units relate to delegated administration. DLP locations determine where policy inspection and enforcement apply.

Trap 10: Ignoring Tenant-Wide Impact

Changing policy order can change enforcement for many users and workloads. It should follow testing and change-control procedures.

---

Real-World SOC Analyst Notes

Alert Fatigue

Low-volume DLP rules can produce large numbers of alerts or notifications if thresholds are too broad.

Before escalating every event, consider:

• Data sensitivity
• Number of instances
• Destination
• User role
• Frequency
• Historical behavior
• Whether the action was blocked
• Whether a business justification exists

Rule tuning should reduce noise without hiding meaningful activity.

---

False Positives

A DLP match does not automatically prove malicious intent.

False positives may occur because:

• A sensitive information type matched a benign numeric pattern
• The user was completing an approved task
• The destination was a trusted business partner
• Test data resembled real financial information
• The policy scope was overly broad
• Confidence levels were too low
• Exceptions were not properly configured

Analysts should validate the content and context before assigning intent.

---

Investigation Quality

A strong DLP investigation goes beyond confirming that a rule fired.

The analyst should determine:

• What happened
• Who performed the action
• What information was involved
• Where the information was sent or copied
• Whether the data left organizational control
• Whether the behavior was intentional
• Whether the account or device was compromised
• Whether the action was blocked
• Whether similar events occurred previously

---

Evidence Preservation

Depending on the severity of the event, preserve:

• Alert details
• Policy and rule names
• Priority numbers
• Timestamps
• User identity
• Device identity
• File names and paths
• Sharing destinations
• Email recipients
• Sensitive information classifications
• Instance counts
• Enforcement results
• Relevant audit records

Avoid unnecessarily copying sensitive data into tickets or chat messages. Document identifiers and secure evidence locations instead.

---

Escalation Paths

A DLP event may require coordination with:

• Compliance
• Legal
• Human resources
• Insider risk personnel
• Identity administrators
• Endpoint security
• Messaging administrators
• SharePoint or OneDrive administrators
• Data owners
• Incident response teams
• Management

A malicious exfiltration case should not be handled only as a policy-tuning issue.

Likewise, an accidental low-volume violation may not justify disabling the user or isolating the device.

---

Automation Safety

Automated actions should be designed carefully.

A rule that blocks activity tenant-wide can interrupt critical operations. A rule that automatically escalates every low-confidence match can overwhelm the SOC.

Safer implementation practices include:

• Begin in simulation.
• Review match volume.
• Pilot with a limited group.
• Confirm exception handling.
• Use stronger actions for higher-confidence or higher-volume events.
• Monitor after enforcement.
• Maintain a rollback plan.

---

Access Permissions

Not every SOC analyst should be able to create, reorder, or enforce DLP policies.

Organizations should separate responsibilities where practical:

• Analysts investigate alerts.
• Compliance administrators manage policy.
• Security administrators correlate broader threats.
• Legal or HR personnel handle regulated investigations.
• Change authorities approve tenant-wide enforcement changes.

Use least privilege and document who is authorized to change policy precedence.

---

Data Retention

Investigation capability depends on how long relevant alert, audit, and activity data remains available.

Retention considerations include:

• Investigation timelines
• Regulatory requirements
• Licensing
• Audit retention
• Sentinel retention, when data is ingested
• Legal hold requirements
• Internal evidence-handling policies

An alert may be visible after supporting telemetry has expired, making scope determination more difficult.

---

Microsoft Sentinel Cost Considerations

DLP policy configuration itself is performed in Microsoft Purview, not Microsoft Sentinel.

If DLP or related audit information is ingested into Sentinel, ingestion and retention may create costs.

Before sending large volumes of compliance telemetry into Sentinel, determine:

• Whether the data supports a security use case
• Which fields are needed
• How long the data must be retained
• Whether filtering can reduce unnecessary ingestion
• Whether lower-cost retention options are appropriate

Do not ingest data merely because it is available. Connect it to a defined detection, hunting, or investigation requirement.

---

Quick Reference Summary

• Microsoft Purview manages DLP policies.
• DLP policy priority uses numerical ordering.
• Lower number means higher priority.
• Priority 0 is the highest.
• Policies can be moved up, down, to the top, or to the bottom.
• A policy can contain multiple rules.
• Templates may create low-volume and high-volume rules.
• Instance counts determine which rule condition matches.
• High-volume matches generally trigger stronger actions.
• When rule outcomes conflict, the most restrictive result takes effect.
• Policy priority and rule restrictiveness are separate concepts.
• Use simulation before broad enforcement.
• Verify scope, locations, thresholds, and exceptions.
• Treat DLP alerts as potential security events, not only compliance events.
• Correlate DLP activity with user, device, identity, email, and cloud evidence.

---

Flashcards

Q: Which Microsoft portal is used to configure DLP policies?
A: Microsoft Purview.

Q: In Microsoft Purview DLP, does a lower or higher number represent higher policy priority?
A: A lower number represents higher priority.

Q: What is normally the highest DLP policy priority number?
A: Priority 0.

Q: What happens when a policy is moved to the highest-priority position?
A: It is assigned the lowest numerical priority, normally 0.

Q: What are the two separate layers of DLP precedence?
A: Policy priority between policies and restrictiveness between applicable rule outcomes.

Q: What happens when applicable DLP rules conflict?
A: The most restrictive applicable result takes effect.

Q: Why might a DLP template contain separate low-volume and high-volume rules?
A: To apply different responses based on the number of sensitive-information instances detected.

Q: In the example policy, what instance count represents low volume?
A: One through four instances.

Q: In the example policy, what instance count represents high volume?
A: Five or more instances.

Q: What is a common response to a low-volume match?
A: Notify the user through email or a policy tip.

Q: What additional responses may be used for a high-volume match?
A: Administrative alerts, incident reports, and stronger enforcement actions.

Q: Why should a new DLP policy be placed in simulation?
A: To measure impact, identify false positives, and validate behavior before enforcement.

Q: Does Microsoft Sentinel configure DLP policy priority?
A: No. DLP policy priority is configured in Microsoft Purview.

Q: What should an analyst verify when a DLP policy does not trigger?
A: Policy scope, supported locations, rule conditions, thresholds, and exceptions.

Q: Why can changing DLP policy priority require change control?
A: It can change enforcement behavior across overlapping users, data, and workloads.

---

Practice Questions

Question 1:

An organization has two Microsoft Purview DLP policies. The Finance Department policy has priority 0, and the General Financial Data policy has priority 1. Which policy has the higher priority?

A. General Financial Data
B. Finance Department
C. Both have equal priority
D. The policy created most recently

Correct Answer:
B. Finance Department

Explanation:
Microsoft Purview DLP uses lower numerical values for higher policy priority. Priority 0 is higher than priority 1.

---

Question 2:

A DLP policy contains two applicable rules. One rule displays a policy tip, while another blocks the activity without allowing an override. What outcome should be expected?

A. Only the policy tip is displayed
B. The user selects which rule to apply
C. The activity is blocked
D. Both rules are ignored because they conflict

Correct Answer:
C. The activity is blocked

Explanation:
When applicable DLP rules conflict, the most restrictive result takes effect. Blocking without override is more restrictive than displaying a policy tip.

---

Question 3:

A security administrator creates a new DLP policy that may affect thousands of users. The administrator wants to understand how often it will match before preventing any activity. What should the administrator do first?

A. Move the policy to priority 0
B. Enable simulation mode
C. Create a Microsoft Sentinel workbook
D. Disable all existing DLP policies

Correct Answer:
B. Enable simulation mode

Explanation:
Simulation allows the organization to evaluate matches, false positives, and operational impact before enforcing restrictions.

---

Question 4:

A financial data policy uses one rule for one through four sensitive-information instances and another rule for five or more instances. Why are separate rules used?

A. To apply different actions based on the detected volume
B. To assign different Microsoft Sentinel workspaces
C. To change the policy’s numerical priority
D. To delegate administration through separate tenants

Correct Answer:
A. To apply different actions based on the detected volume

Explanation:
Instance-count thresholds allow lower-volume activity to generate user notifications while higher-volume activity can trigger alerts, incident reports, or stronger enforcement.

---

Question 5:

An analyst is asked to make a UK Financial Data policy take precedence over a US Financial Data policy. The UK policy currently has priority 1, and the US policy has priority 0. What should the analyst recommend?

A. Change the UK policy to priority 2
B. Move the UK policy to the highest-priority position
C. Add a KQL query to the UK policy
D. Change the UK policy from simulation to disabled

Correct Answer:
B. Move the UK policy to the highest-priority position

Explanation:
Moving the UK policy to the highest position assigns it the lowest numerical value, normally priority 0, giving it higher precedence.