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.

• ✗

  Row-level security (RLS)

  Why it's wrong here

  Row-level security (RLS) in Azure Synapse uses a security predicate to filter which rows a query returns based on the caller's identity, such as USER_NAME() or SESSION_CONTEXT. This means unauthorized users may be limited to a subset of business-specific rows, such as only their own region, but every column in those rows remains fully visible and queryable. RLS therefore operates along the horizontal axis of the table and cannot prevent a user from selecting or viewing the contents of a PII column if they have access to any row. Because the requirement is specifically to block access to columns, RLS is insufficient and incorrect.

• ✓

  Column-level security

  Why this is correct

  Column-level security (CLS) in Azure Synapse implements table-level or view-level permissions that grant or revoke SELECT access to individual columns using the GRANT and DENY Transact-SQL statements. For example, a user can be granted access to all non-PII columns while being explicitly denied access to an SSN column, and any attempt to query that column returns an error. CLS enforces access control at the authorization layer, ensuring the protected column is not readable even when the user has access to other columns in the same table. This directly satisfies the requirement to prevent unauthorized querying of PII columns.

• ✗

  Azure Purview data classification

  Why it's wrong here

  Azure Purview data classification is a governance service that scans data sources, applies automated classification labels such as 'Social Security Number' or 'Email' to columns, and builds a searchable data map for compliance and lineage tracking. While it makes administrators aware of where PII resides and helps trigger downstream processes, Purview does not enforce any security boundaries, issue grants, or intercept queries at runtime. Even after classification, any user with existing SELECT permission can still query the classified columns, because Purview only provides metadata and visibility, not access control. Therefore, using Purview alone would not stop unauthorized access to PII columns.

• ✗

  Dynamic data masking

  Why it's wrong here

  Dynamic data masking (DDM) in Azure Synapse applies a masking rule to a column so that non-privileged users receive masked values in query results, such as displaying 'xxx-xx-1234' for a Social Security Number or hiding all email characters except the first letter. However, DDM does not alter the underlying data or remove the column from query results; it only transforms the output of SELECT statements for users lacking the UNMASK permission. This means unauthorized users can still see the column name, metadata, and can include it in queries, and they may potentially infer masked content through patterns or side channels. Since the requirement is to prevent querying PII columns entirely, DDM is a weaker control and does not satisfy the need for denial of access.

Go deeper

Related to this question