DP-900 Describe an analytics workload on Azure 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.

• ✗

  Use a regular expression pattern matching.

  Why it's wrong here

  In Azure Purview, classification of data relies on predefined sensitive types, not on manually invoked regex operations. A regular expression is merely a pattern-matching technique that you might use to define a custom rule, but it is not a classification action or a built-in rule itself. Because Purview already includes a 'Credit Card Number' system classification with Luhn validation, implementing regex matching would be duplicative, more error-prone, and would not integrate with Purview's native detection pipeline.

• ✗

  Create a custom classification rule.

  Why it's wrong here

  Azure Purview provides a built-in 'Credit Card Number' sensitive information type, so creating a custom classification rule is unnecessary overhead. A custom rule would require you to supply your own regex and optionally keywords and expected confidence, leaving room for false positives or missed numbers that the curated system classifier already handles via the Luhn checksum. Custom rules are intended for data patterns that have no existing system classification, not for well-covered standards like credit card numbers.

• ✗

  Enable the 'Personally Identifiable Information (PII)' classification.

  Why it's wrong here

  The 'Personally Identifiable Information (PII)' classification is an umbrella category in Purview that covers a wide range of attributes such as names, addresses, and government IDs. Enabling it would tag credit card data indirectly, but it would also flag many other data types, making the classification too broad for targeted PCI DSS compliance monitoring. Applying the specific 'Credit Card Number' classification gives a precise, auditable signal that this exact sensitive data type is present, which is what the scenario requires.

• ✓

  Enable the 'Credit Card Number' classification.

  Why this is correct

  This is the correct action because Azure Purview ships with a built-in system classification named 'Credit Card Number' that detects 13–19-digit card numbers and validates them against the Luhn algorithm to filter out random digit strings. Enabling this classification in a scan rule set lets Purview automatically label data assets containing credit card information, giving you a compliant and precise way to identify sensitive data. It is the most direct built-in approach, requiring no custom logic or overly broad categories.

Go deeper

Related to this question