AZ-305
Deep Dive
Designing data protection on AZ-305 comes down to three questions: who controls the keys (Microsoft or the customer)? who are we protecting the data from (attackers, administrators, the cloud provider itself)? and how do we guarantee it can't be altered or deleted?
Contents
Platform-Managed Keys (PMK)
Customer-Managed Keys (CMK)
VM disk encryption
| Technology | Protects against | Key feature |
|---|---|---|
| TDE (Transparent Data Encryption) | Theft of the DB's physical files / backups | Encrypts the entire DB at rest. ON by default. Transparent: SQL admins SEE the data in cleartext when querying. CMK possible (BYOK) |
| Always Encrypted | DB and Azure administrators — data travels encrypted all the way to the client | Encrypts SPECIFIC columns; the client holds the keys. Neither the DBA nor Microsoft see the data. Limits queries (equality with deterministic). With secure enclaves: ranges and LIKE |
| Dynamic Data Masking | App users who shouldn't SEE the full value | Does NOT encrypt — masks the presentation (XXX-XX-1234). Data remains cleartext in the DB. Controls exposure, not cryptographic security |
| Row-Level Security | Cross-row access between different tenants/users | Filters rows based on the user context — multi-tenant in a single table |
The distinction that comes up most
"Neither database administrators nor Microsoft should be able to see the card numbers" → Always Encrypted (TDE won't do — the DBA sees the data). "Encrypt the database and its backups at rest" → TDE. "The call center only sees the last 4 digits" → Dynamic Data Masking.
In transit
In use — Confidential Computing
| Mechanism | What it guarantees |
|---|---|
| Immutable blob storage — time-based retention | WORM: no one (not even the Owner) can modify/delete blobs for N days. For SEC/FINRA and ransomware. Locked policy = irreversible |
| Immutable storage — legal hold | WORM with no fixed date — until the hold is lifted (litigation) |
| Soft delete (blobs, containers, file shares) | Recover accidental deletions during the retention period |
| Blob versioning | Every overwrite creates a recoverable version |
| Point-in-time restore (block blobs) | Restore containers to an earlier point in time |
| Resource lock CanNotDelete | Protect the ACCOUNT itself against deletion (control plane) |
Anti-ransomware signal
"Backups must not be encryptable or deletable by an attacker with administrator credentials" → immutable storage with a locked policy (or Azure Backup vaults with immutability + always-on soft delete + multi-user authorization).
Microsoft Purview
In SQL
| Requirement | Design |
|---|---|
| The organization must be able to revoke the storage encryption keys | CMK in Key Vault (+ purge protection) |
| Neither DBAs nor Microsoft see the card numbers | Always Encrypted on those columns |
| Encrypt the DB and backups at rest (general compliance) | TDE (default; CMK if key control is required) |
| Support only sees the last 4 digits of the document | Dynamic Data Masking |
| Each tenant only sees their own rows | Row-Level Security |
| Financial records immutable for 7 years (WORM) | Immutable blob storage, time-based locked policy |
| Data protected even while being processed | Confidential VMs / confidential computing |
| Discover PII across SQL, ADLS and S3 | Microsoft Purview |
| Encryption inside the VM's OS (BitLocker) | Azure Disk Encryption |
Did you get this topic?
Test what you just learned
A fintech stores card numbers in Azure SQL Database. The compliance requirement states: 'card data must not be visible to database administrators or the cloud provider, not even during a query'. TDE is already enabled. What's missing?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.