The DP-300 compliance section tests one skill: knowing which security feature fits which scenario. Encryption locks data, but regulators expect more — who queried what and when, whether sensitive columns are structurally hidden, and whether any record has been tampered with. Azure SQL Database addresses each requirement at a different layer.
SQL Audit — Recording Everything Like CCTV
SQL Audit is the equivalent of installing CCTV on your database. Every login, query, and data modification is recorded in a durable log that you can present as evidence during a compliance audit.
A server-level audit policy applies automatically to every database on that server — useful when a team manages many databases and needs a consistent baseline. A database-level policy scopes to a single database and can run alongside, or independently of, the server policy.
Audit logs can flow to three destinations: Storage Account, Log Analytics Workspace, or Event Hub. Storage Account suits long-term retention requirements. Log Analytics lets you run Kusto queries immediately for ad hoc investigation. Event Hub connects audit events to real-time streaming pipelines. In exam scenarios, "submit long-term evidence to a regulator" points to Storage Account; "integrate with real-time anomaly detection" points to Event Hub.
Dynamic Data Masking — The Redacted Receipt
When you pay at a coffee shop, your receipt shows only the last four digits of your card number. Dynamic Data Masking (DDM) works the same way. The real value stays intact in the database; users without sufficient privilege receive a masked version at query time.
There are five masking rule types. replaces numbers with 0, strings with X, and dates with 1900-01-01. exposes the first letter and domain suffix. combines a prefix, a block of X characters, and a suffix. substitutes a random value within a defined range. reveals characters at both ends, masking the middle.
The most important exam point about DDM is the permission — any user granted this sees the raw value. Administrators with db_owner also bypass masking entirely. DDM controls the presentation layer only; it is not a substitute for engine-level access control. When a scenario requires "even the DBA must not see plaintext," the answer is Always Encrypted, not DDM.
Row-Level Security — Different Badges for Different Floors
In a corporate headquarters, a sales employee's badge opens the sales floor but not the R&D lab. Row-Level Security (RLS) applies this same idea to database rows. Two users querying the same table can receive completely different result sets based on their session context.
RLS is built from two pieces. A — an inline table-valued function — encodes the logic of "can this user see this row?" A binds that function to a target table. A silently removes rows from SELECT results that fail the condition. A also prevents INSERT, UPDATE, and DELETE operations that violate the policy.
RLS is most commonly seen in multi-tenant SaaS architectures: one table holds data from many customers, and RLS ensures each customer sees only their own rows — without separate tables or views per tenant.
Ledger — The Notarized Document
A document notarized by a public office cannot be altered after the stamp is applied; any change is detectable as forgery. Azure SQL Ledger applies the same concept to database records. A cryptographic hash chain protects the history of each ledger table, and any modification outside the normal write path is detected at verification time.
There are two Ledger table types. An allows modifications and deletes, but every change is appended to a history table protected by the hash chain. An allows only INSERT; UPDATE and DELETE are blocked at the engine level. When an exam question mentions "tamper detection" or "cryptographic proof of data integrity," Ledger is the answer.
Defender for SQL — The Security Guard at the Gate
A security guard at a factory entrance notices an unusual pattern of badge swipes and reports it immediately. Microsoft Defender for SQL analyzes query patterns and access behavior to surface anomalous activity automatically.
Defender for SQL has two capabilities. scans for misconfigurations, excessive privileges, and unpatched vulnerabilities, then provides remediation guidance. monitors runtime behavior and raises alerts for SQL injection attempts, logins from unusual locations, and brute-force attacks. If SQL Audit is "record what happened," Defender for SQL is "alert when something looks wrong."
Comparing the Controls Side by Side
Always Encrypted is frequently compared with DDM: DDM stores plaintext in the database and only masks the output, while Always Encrypted means the database server itself never decrypts the data — only the client holding the encryption key can read plaintext.
Here is a quick reference for each control. SQL Audit logs access history with no bypass concept (compliance evidence, audit trail). Dynamic Data Masking hides the displayed value but can be bypassed with UNMASK permission (hiding sensitive columns from app users). Row-Level Security restricts row access but db_owner bypasses it (multi-tenant isolation, department scoping). Always Encrypted cannot be bypassed without the client key (plaintext never visible to the server). Ledger detects tampering immediately (cryptographic immutability proof).
!4 data protection controls compared
Practical Pitfalls — Bypass Scenarios and Layered Design
DDM is effective for regular application users but provides no protection when a DBA connects directly through SQL Server Management Studio — masking does not apply. RLS similarly does not apply to db_owner. Whenever a scenario states "even administrators must not access plaintext," Always Encrypted is the required answer.
Ledger specializes in tamper detection but provides no access control. Pairing it with SQL Audit gives you both an immutable record and a log of who wrote that record. Defender for SQL is a threat-detection service, not a masking or access-blocking mechanism. Data Discovery & Classification automatically labels sensitive columns; those labels then feed DDM rule suggestions and Audit policy targeting.
Exam Key Takeaways
"Record who ran which query and when" -- SQL Audit "Long-term retention of audit logs for regulators" -- Storage Account destination "Stream audit events to a real-time pipeline" -- Event Hub destination "Show only partial card number to app users" -- Dynamic Data Masking "Even the DBA must not see plaintext" -- Always Encrypted "Same table but each department sees only its own rows" -- Row-Level Security (FILTER predicate) "Allow inserts but block updates and deletes" -- Append-only ledger table "Mathematically prove no historical record was tampered with" -- Azure SQL Ledger "Real-time detection of SQL injection attempts" -- Defender for SQL (Advanced Threat Protection) "Scan for misconfigurations and excessive permissions" -- SQL Vulnerability Assessment "Automatically discover and label sensitive columns" -- Data Discovery & Classification "Isolate customer data in a multi-tenant table" -- Row-Level Security
SQL Audit = record, DDM = display masking, RLS = row isolation, Ledger = tamper proof, Defender = threat detection