Manage compliance by using Microsoft Purview →hardMultiple Choice

MS-102 Manage compliance by using Microsoft Purview Practice Question

Exhibit

Refer to the exhibit.

{
  "Name": "DLP Policy - Credit Card",
  "Mode": "Test",
  "Rules": [
    {
      "Name": "Block Credit Card Numbers",
      "Condition": {
        "SensitiveInformation": [
          {
            "id": "50842eb7-edc8-4019-85dd-5a5c1f2bb085",
            "minCount": 1
          }
        ]
      },
      "Actions": [
        "BlockAccess",
        "NotifyUser"
      ],
      "UserNotifications": {
        "Enabled": true,
        "NotifyUserInEmail": true
      }
    }
  ]
}

Refer to the exhibit. You have a DLP policy in test mode as shown. A user reports that they received a notification that sharing credit card numbers is blocked, but they were still able to share them. What is the most likely reason?

⚠ Common exam trap

MS-102 often tests the confusion between 'policy tip shown' and 'action enforced' — candidates assume a notification means the block happened, forgetting that test/simulation mode only surfaces tips and alerts without enforcing actions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The policy is in test mode, which does not enforce actions.

A DLP policy in test mode (also called simulation mode) evaluates rules and generates alerts, notifications, and activity reports, but it does not enforce the configured actions such as BlockAccess or Block. Therefore the user sees the policy tip/notification indicating the content is sensitive, yet the sharing is still allowed because the block action is not applied. This is the intended behavior for validating a policy before turning it on.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The rule action 'BlockAccess' is not included in the policy.
Why it's wrong here
The exhibit confirms that a rule with the BlockAccess action is present in the DLP policy. BlockAccess is a valid restrictive action that, when enforced, restricts access to SharePoint or OneDrive documents. Because the policy is in test mode, however, that action is only simulated — the rule is evaluated and matches are logged, but no actual block is placed on the content. Therefore the absence of blocking is not due to the action being missing from the policy.
✓
The policy is in test mode, which does not enforce actions.
Why this is correct
DLP policies have a policy-level mode setting: 'Enforce', 'Test with policy tips', or 'Test without policy tips'. In 'Test' mode, Microsoft 365 processes the policy's conditions to identify sensitive content and generate incident reports, but all rule actions — including BlockAccess — are effectively disabled. The exhibit explicitly shows the policy is in test mode, which fully explains why nothing is blocked and no access restriction occurs. This is the designed behavior for validating rules before enforcement.
✗
The condition 'SensitiveInformation' is not configured correctly.
Why it's wrong here
The condition in this policy is a valid sensitive information rule, such as a recognized sensitive info type with an instance count and confidence level. If this condition were malformed or referenced a non-existent entity, the policy would fail to evaluate or would produce no matches; but the scenario shows that the rule is actually matching content as expected. Because the condition is working correctly, it is the test mode, not the condition itself, that prevents the BlockAccess action from executing.
✗
The notification is not enabled in the policy.
Why it's wrong here
The notification settings in this policy are enabled, as shown by the notification entry, and user notifications and policy tips are separate from enforcement. Even if notifications were disabled, that would only stop end-user emails or policy tips from being delivered; it would have no effect on whether the BlockAccess action is applied. The behavior observed here is caused by the policy's test mode, not by the notification configuration.

Go deeper

MS-102 Manage compliance by using Microsoft Purview Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question