MS-102 Manage compliance by using Microsoft Purview Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Create a custom sensitive info type using a regular expression.

  Why this is correct

  Creating a custom sensitive info type (SIT) with a regular expression is the correct approach when your organization's employee ID follows a specific, predictable pattern (e.g., a prefix like “EMP-” followed by digits). In Microsoft Purview, a custom SIT lets you define a regex-based pattern that directly matches that format, and you can further refine detection with corroborative keywords, character proximity, and confidence levels. This allows DLP policies to precisely identify the data without relying on an exhaustive list of known values.

• ✗

  Use a keyword dictionary for the pattern.

  Why it's wrong here

  A keyword dictionary is fundamentally a list of exact terms or phrases (e.g., product codes, names) that Purview matches literally against content. It does not support pattern logic, variable-length alphanumeric sequences, or wildcards, so attempting to enumerate every possible employee ID value (e.g., 'EMP-001', 'EMP-002', ...) is infeasible and inherently brittle. For detecting a defined format, a keyword dictionary is the wrong tool; it is designed for term-based matching, not structural pattern matching.

• ✗

  Use exact data match (EDM) based classification.

  Why it's wrong here

  EDM-based classification requires an uploaded database of exact values (e.g., a table of all employee IDs) that is hashed and indexed in Microsoft Purview. It is intended for matching exact, known strings from a controlled dataset, not for deriving a pattern algorithmically; EDM will miss any value not in the uploaded database and requires ongoing schema definition and data refresh. Since the question states the employee ID follows a format (not a finite list), EDM is an over-engineered and unsuitable mechanism compared to a regular expression.

• ✗

  Use the built-in 'Employee ID' sensitive info type.

  Why it's wrong here

  The built-in 'Employee ID' sensitive info type may cover a generic format (e.g., a 9-digit number or a specific pattern used by many organizations) but does not necessarily match the exact format your organization uses, such as a custom prefix. Built-in SITs are Microsoft-defined and cannot be modified; they often rely on specific regex patterns, keywords, and context that may or may not align with your internal ID structure. If the built-in type does not recognize your format, it will generate false negatives, making a custom regex SIT the only reliable way to match your exact pattern.

Go deeper

Related to this question