PL-300 Prepare the data 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.

• ✓

  Configure dynamic data masking on the Azure SQL Database.

  Why this is correct

  Configuring dynamic data masking on Azure SQL Database obfuscates sensitive columns at the database engine level, applying mask functions to the result set based on the querying user's permissions. When Power BI runs a query (especially in DirectQuery or SQL passthrough), if the login lacks masking privileges, the returned data is already masked. This is a source-side defense that requires no alteration of the data model or report design.

• ✗

  Use row-level security (RLS) in Power BI to hide sensitive columns.

  Why it's wrong here

  Row-level security (RLS) in Power BI filters data rows based on DAX predicates associated with user roles, but it does not hide, remove, or obfuscate individual columns from a table. With RLS enabled, report consumers can still see every column in the underlying table, including sensitive ones, subject only to row filtering. To hide a column you would need to exclude it from the model or use a separate aggregated table, not RLS. RLS is scoped to rows only, making it an unsuitable mechanism for columnar masking.

• ✓

  Transform the data in Power Query by replacing sensitive values with a placeholder.

  Why this is correct

  Transforming data in Power Query by replacing sensitive values with placeholders (such as 'XXX', nulling, or hashing) is a valid static obfuscation method that occurs before data is loaded into the Power BI data model. This approach applies the same masking to every user because the transformation is baked into the loaded dataset, unlike source-level dynamic masking that varies by user context. It is useful when the protection requirement is uniform across all consumers and acceptable to lose the original values for downstream analysis.

• ✗

  Use Microsoft Purview sensitivity labels to mask data.

  Why it's wrong here

  Microsoft Purview sensitivity labels attach classification metadata to files and database columns, allowing automatic labeling, file-level encryption, and access governance policies, but they do not mutate or mask the actual data values. When Power BI connects to data bearing these labels, it receives the underlying plaintext values; the label simply signals sensitivity and enforces policies like encryption when files are exfiltered. Thus, labels cannot prevent exposure of column contents—they only guide behavior and trigger governance controls, not dynamic data masking.

• ✗

  Apply column-level security in Power BI Desktop.

  Why it's wrong here

  Power BI Desktop does not provide a built-in, click-to-configure column-level security feature. Its native security model is RLS, which restricts rows per role; column visibility is controlled only by excluding fields from the model or using a field parameter technique, which is not true column-level security. Claiming you can apply column-level security in Power BI Desktop is therefore inaccurate—at best you can split data into separate tables and manage relationships as an indirect workaround, but that is not a security feature.