SIMULATION You need to ensure that when non-administrative users query the SalesLT.Customer table in db1, email addresses are obscured. For example, an email address of [email protected] must appear a

Azure SQL Dynamic Data Masking - Exam Explanation Overall Goal The objective is to protect sensitive data (email addresses) from non-privileged users without changing the underlying data or application code. Dynamic Data Masking (DDM) is the correct tool because it applies maskin

Submitted by ngozi_ng· Mar 6, 2026Implement a secure environment

Question

SIMULATION You need to ensure that when non-administrative users query the SalesLT.Customer table in db1, email addresses are obscured. For example, an email address of [email protected] must appear as [email protected]. You may need to use SQL Server Management Studio and the Azure portal. Answer: SQL Database dynamic data masking with the Azure portal In the Dynamic Data Masking pane in the portal, you see the recommended columns for your database. Select Add Mask for one or more columns, then select the appropriate masking function and select Save, to apply mask for these fields. In details: Enable dynamic data masking Step 1: Launch the Azure portal at https://portal.azure.com. Step 2: Go to your database resource in the Azure portal. [Select db1] Step 3: Select the Dynamic Data Masking pane under the Security section. Step 4: In the Dynamic Data Masking configuration page, you may see some database columns that the recommendations engine has flagged for masking. In order to accept the recommendations, just click Add Mask for one or more columns and a mask is created based on the default type for this column. You can change the masking function by clicking on the masking rule and editing the masking field format to a different format of your choice. Be sure to click Save to save your settings. 4.1 If possible locate the column with email addresses in the SalesLT.Customer table [If not seen skip to step 5] 4.2 Click Add Mask Step 5: To add a mask for any column in your database, at the top of the Dynamic Data Masking configuration page, click Add Mask to open the Add Masking Rule configuration page. [Skip steps 5-6 step if step 4 was successful] Step 6: Select the Schema, Table and Column to define the designated field for masking. Select the following Table: SalesLT.Customer table Column: [Choose the column with the email addresses] Step 7: Select how to mask from the list of sensitive data masking categories. Select Email ([email protected]) Step 8: Click Add in the data masking rule page to update the set of masking rules in the dynamic data masking policy. Step 9: Type the SQL authenticated users or authenticated identities from Microsoft Entra ID (formerly Azure Active Directory) that should be excluded from masking, and have access to the unmasked sensitive data. [Skip] Step 10: Click Save in the data masking configuration page to save the new or updated masking policy. Reference: https://learn.microsoft.com/en-us/azure/azure-sql/database/dynamic-data-masking-configure- portal

Exhibit

Explanation

Azure SQL Dynamic Data Masking - Exam Explanation

Overall Goal

The objective is to protect sensitive data (email addresses) from non-privileged users without changing the underlying data or application code. Dynamic Data Masking (DDM) is the correct tool because it applies masking at the query result layer - the actual data in the database is unchanged, but non-administrative users see a masked version. Admins and excluded identities still see real data.

This is a declarative policy approach, not encryption - it's lightweight, reversible, and requires no schema changes.

Step-by-Step Reasoning

Step 1 - Launch the Azure portal DDM for Azure SQL Database is managed through the Azure portal (or T-SQL/PowerShell). SSMS alone cannot configure DDM policies - it's a platform-level security feature, not a database object.

Step 2 - Navigate to db1 You must scope to the correct database resource. DDM policies are per-database, not per-server. Choosing the wrong database means the mask is never applied to SalesLT.Customer.

Step 3 - Open the Dynamic Data Masking pane (under Security) This is where the DDM policy lives. Skipping this and trying to configure masking elsewhere (e.g., SSMS object properties) won't work - DDM is not exposed there.

Step 4 - Use recommendations (if available) Azure's recommendations engine scans column names and data patterns to suggest likely sensitive columns. If EmailAddress appears, accepting the recommendation creates the rule automatically with the correct default mask type. Skipping this when the recommendation is present wastes time but doesn't break anything - you'll just do it manually in the next step.

Step 5 - Manually click "Add Mask" at the top (if no recommendation) If the engine didn't surface the column (possible if naming is non-standard), you must create the rule manually. This opens the Add Masking Rule configuration pane.

Step 6 - Select Schema, Table, and Column You must be precise: Schema = SalesLT, Table = Customer, Column = EmailAddress (the actual column name). A wrong column means the mask applies to the wrong data - the email column remains unmasked.

Step 7 - Select the "Email" masking function Azure SQL offers several masking formats:

Format	Example
Default	`XXXX` (full mask)
Email	`[email protected]`
Custom string	Configurable prefix/suffix/padding
Random number	Numeric columns

You must choose Email - it's the only built-in format that produces the [email protected] pattern required by the spec. Choosing "Default" would obscure the entire value, not match the required format.

Step 8 - Save Without saving, no policy is written. The mask does not take effect. This is the most commonly missed step in simulations.

Step 9 (Skipped) - Exclusions You can whitelist specific users/identities (e.g., DBAs) who should see real data. The question says skip this - by default, only db_owner and server admins bypass masking automatically.

What Breaks If Steps Are Skipped or Misordered

Skipped Step	Consequence
Step 2 (wrong database)	Mask applied to wrong DB; `db1` remains unprotected
Step 6 (wrong column)	Wrong column masked; email column still visible
Step 7 (wrong mask type)	Output format won't match `[email protected]` requirement
Step 8 (no Save)	Configuration lost; masking never activates

Memory Tip

"Portal -> DB -> Security -> DDM -> Schema.Table.Column -> Email format -> Save"

Think of it as a funnel: you start broad (portal) -> narrow to the database -> narrow to the security feature -> narrow to the exact column -> choose how to hide it -> commit.

A secondary anchor: DDM is non-destructive and transparent - real data is untouched, only query results are masked. If you're ever unsure whether DDM or Transparent Data Encryption (TDE) is the right answer, remember: TDE protects data at rest (disk), DDM protects data at query time (what users see). This question requires the latter.

Topics

#Dynamic Data Masking#Data Security#Azure SQL Database#Data Privacy

Community Discussion

No community discussion yet for this question.

Full DP-300 Practice