What's changed: Created SC-100 Chapter 5 (Domain 4 "Application and data security": M365 protection (Microsoft Secure Score/Defender for Office 365/Defender for Cloud Apps (CASB)/Intune/Purview labels/DLP); Copilot for Microsoft 365 (permission/label inheritance/oversharing/DSPM for AI/Purview Audit); app protection (threat modeling/secure development lifecycle/workload identity/API Management/Azure WAF); data protection (discovery/classification/encryption at rest-in transit/CMK/Key Vault/Defender for Storage/Defender for Databases/Azure SQL/Synapse/Cosmos DB/Storage)).
5.4Securing data
Understand data discovery/classification, prioritizing data-threat mitigation, encryption at rest/in transit (Azure Key Vault, infrastructure encryption), data protection for Azure workloads (Azure SQL, Azure Synapse Analytics, Azure Cosmos DB) and Azure Storage, and Microsoft Defender for Storage/Databases.
Ultimately, data is what we protect. Architects start from "where is what sensitive data (discovery/classification)," then layer encryption, access, and threat detection, protecting high-value data first.
5.4.1Discovery/classification and encryption
First, use data discovery and classification (Microsoft Purview information protection/sensitivity labels) to know "where the sensitive data is" and set mitigation priorities. Then design encryption: encryption at rest (on by default; use customer-managed keys (CMK) in Azure Key Vault/Managed HSM as needed) and encryption in transit (TLS), with double-layer infrastructure encryption. Key management—"who holds the keys (Microsoft-managed vs customer-managed)"—directly ties to compliance requirements. Architects organize "encryption by sensitivity and key custody" as design decisions.
5.4.2Threat detection for datastores
Design threat detection per datastore: Azure Storage with Microsoft Defender for Storage (malware upload, anomalous access), and Azure SQL, Azure Cosmos DB, PostgreSQL/MySQL with Microsoft Defender for Databases (SQL injection, anomalous access). Including analytics platforms like Azure Synapse Analytics, enable threat protection for data at rest as Defender for Cloud CWPP. The key is defense in depth: layering threat detection on access control (private endpoints, RBAC, firewalls) and encryption.
Cues: "discover/classify where sensitive data is" = Purview (information protection/labels). "manage your own encryption keys (compliance)" = CMK + Key Vault/Managed HSM. "anomalous access/malware on Storage" = Defender for Storage. "SQLi/anomaly on Azure SQL/Cosmos DB" = Defender for Databases.
Watch the mix-ups: (1) Encryption at rest is on by default—the requirement is often "who manages the keys (CMK)." (2) Defender for Storage/Databases (threat detection) and encryption/access control (prevention) are different layers—stack them. (3) Sensitivity labels (Purview, data-following) and store encryption (platform) are complementary.
5.4.3Section summary
- Use Purview discovery/classification to locate sensitive data and prioritize; encrypt at rest/in transit + key management (CMK = Key Vault/Managed HSM)
- Defender for Storage (Storage) and Defender for Databases (Azure SQL/Cosmos DB) detect threats to data at rest
- Defense in depth—layer access control, encryption, threat detection—protecting high-value data first
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Regulation requires that you—not Microsoft—manage the keys used to encrypt data. Which is best?
Q2. To detect anomalous access or malware uploads to Azure Storage, which is best?
Q3. To detect SQL injection or anomalous access on Azure SQL or Azure Cosmos DB, which is best?
Q4. What is the most appropriate starting point for data protection?
Q5. Which correctly describes defense in depth for data protection?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.