Manage compliance by using Microsoft Purview →hardMultiple Choice

MS-102 Manage compliance by using Microsoft Purview Practice Question

Exhibit

{
  "Assignment": {
    "Target": {
      "All": "AllUsers"
    },
    "Method": "Automatic",
    "Condition": {
      "SensitivityTypes": ["9f1cff3e-8e2d-4b9a-9a0d-1c2d3e4f5a6b"]
    },
    "LabelId": "e1f6a5b4-3c2d-4e5f-9a8b-7c6d5e4f3a2b"
  }
}

Refer to the exhibit. You are reviewing a Microsoft Purview auto-labeling policy configuration. The SensitivityTypes GUID corresponds to a sensitive info type that detects credit card numbers. The LabelId is for a 'Confidential' label. Users report that documents containing credit card numbers are not being automatically labeled. What is the most likely reason?

⚠ Common exam trap

The trap is focusing on label publication or licensing when the most common cause of silent auto-labeling failure is a misconfigured policy scope that omits the locations where the sensitive data actually resides.

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 auto-labeling policy is not scoped to the correct locations (e.g., SharePoint, Exchange).

Auto-labeling policies in Microsoft Purview must be scoped to the locations where the sensitive data resides (Exchange, SharePoint, OneDrive, etc.). If the policy is not scoped to the correct locations, documents containing credit card numbers in those locations will never be evaluated, so no automatic labeling occurs. This is the most common configuration oversight when auto-labeling appears to do nothing.

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 'Confidential' label is not published to users.
Why it's wrong here
The label is already published to users because it is referenced in the auto-labeling policy. In Microsoft Purview, auto-labeling policies can only select sensitivity labels that have been published via a label policy, so its presence in the configuration confirms publication. Therefore, this is not the reason the auto-labeling fails.
✗
The sensitive info type GUID is incorrect.
Why it's wrong here
The sensitive info type GUID is correct; it matches the built-in Microsoft-provided identifier for the Credit Card Number entity. If the GUID were invalid, the policy editor would typically reject it during configuration. Thus, the misidentification of the SIT is not the cause of the labeling failure.
✗
Users do not have the appropriate license for auto-labeling.
Why it's wrong here
Auto-labeling is an organizational capability that depends on tenant-level licenses, such as Microsoft 365 E5 or the Microsoft Purview add-on, rather than per-user licenses. All users within the tenant share this feature once the appropriate license is assigned to the organization, so insufficient licensing is not the issue here. Since the policy also lacks location scoping, licensing would not explain the failure.
✓
The auto-labeling policy is not scoped to the correct locations (e.g., SharePoint, Exchange).
Why this is correct
For an auto-labeling policy to apply labels, it must be explicitly scoped to the locations where content resides, such as SharePoint sites, Exchange mailboxes, and OneDrive. The exhibit shows that the policy does not include these locations, or includes only a subset, so the policy never scans the content. Without proper location scoping, no labeling occurs even if the label and SIT are configured correctly.

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