Quick Note — Recommend a Solution for Data Protection (Relational)
AZ-305 › Unit 2 › Design data storage for relational data › Recommend a solution for data protection
Quick Note — Recommend a Solution for Data Protection (Relational)
Data protection for Azure's relational platforms — Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs — is where many AZ-305 candidates lose easy marks. The exam rarely asks "is encryption turned on?" — it asks which encryption primitive, combined with which masking or isolation control, satisfies a set of regulatory, operational, and performance constraints at the lowest total cost. Getting this right means knowing which layer of the stack each feature protects: physical media, in-flight traffic, in-memory data, or the human operator looking over the DBA's shoulder.
Retrieval target
- Recommend a Solution for Data Protection (Relational)
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Transparent Data Encryption (TDE) | Encrypts the database at rest — data files, transaction log, backups — without app changes. On by default for new Azure SQL DB / MI since 2017; older DBs must enable manually. The engine encrypts pages as they're written and decrypts when read. Uses a service-managed key by default; can be switched to a customer-managed key (CMK) in Key Vault for BYOK scenarios. |
Always Encrypted | A client-side encryption feature that protects sensitive columns (SSN, credit card, PII) at rest, in transit, and in use — even DBAs see ciphertext. The client driver encrypts before sending. Uses Column Encryption Keys (CEKs) stored encrypted in the DB and protected by Column Master Keys (CMKs) held outside the DB (Key Vault, Windows cert store, HSM). |
Dynamic Data Masking (DDM) | An access-time policy that masks columns for non-privileged users — the underlying data is unchanged, only the projection is masked (e.g., XXX-XX-1234). Built-in masking functions: default, email, random, custom string, credit card. Not encryption — a user with UNMASK permission or who exfiltrates the page sees real data. Use for casual exposure prevention, not strict confidentiality. |
Row-Level Security (RLS) | A predicate-based access control: you write an inline table-valued function that returns rows visible to the current session, and attach it to one or more tables as a security policy. Comes in two flavors — filter (hides rows from SELECT/UPDATE/DELETE) and block (rejects writes that would violate the predicate). Enforced by the engine, so works regardless of how the client connects. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.