Design security solutions for applications and data
Data Security Architecture
CoreDiscover and classify data, prioritize threats, choose layered encryption and key ownership, secure AI data flows, and protect Azure databases and storage with preventive and detective controls.
Aligned to SC-100 skills measured as of October 21, 2026; candidates testing earlier should review the transition note in the lane overview.
Why this matters
Data controls depend on knowing where sensitive information lives, who and what can reach it, how it moves, and which business outcomes require protection. Encryption is necessary but cannot correct excessive authorization, public exposure, or unsafe AI grounding.
Must Know
- Data discovery and classification establish inventory, sensitivity, lineage, ownership, and handling requirements that drive access, DLP, encryption, monitoring, and retention decisions.
- Threat prioritization combines sensitivity, exposure, identities, exploitable paths, business criticality, residency, lifecycle stage, and recovery requirements rather than sorting findings only by severity.
- Azure services commonly provide platform-managed encryption at rest; customer-managed keys add control and duties; infrastructure encryption can add a second service-side layer; client-side protection changes who can decrypt.
- Key Vault and managed HSM designs require separation of duties, network controls, soft delete and purge protection, rotation, backup or recovery, monitoring, and resilient application access.
- AI data architecture governs training, grounding, prompts, outputs, vector stores, evaluations, logs, retention, residency, access, provenance, and protection against indirect prompt-driven exfiltration.
- Azure SQL, Synapse, Cosmos DB, and Storage require service-specific identity, network, encryption, authorization, backup, audit, vulnerability, and data-protection choices.
- Defender for Storage and Defender for Databases detect suspicious activity and threats; they complement preventive configuration and data-governance controls.
Compare and Distinguish
- Data classification determines handling and control policy; threat detection observes suspicious behavior; encryption protects confidentiality under specific key and access assumptions.
- Service-side customer-managed keys give the organization key-control duties, while client-side encryption can keep plaintext unavailable to the service but increases application complexity.
Scenario examples
- Scenario: A research assistant grounds responses on regulated documents. Think: classify and minimize sources, scope identity, isolate the index, filter retrieval, evaluate leakage, log access, and govern prompts and outputs.
- Scenario: A storage account must resist account-key leakage and detect exfiltration. Think: use Entra authorization, disable unnecessary shared-key access, restrict networks, protect data and recovery, and enable Defender for Storage.
Exam traps
- Customer-managed keys do not prevent an overprivileged application from reading decrypted data through the service.
- Defender alerts do not replace private access, least privilege, classification, backup, or secure configuration.
Key takeaways
- Unknown data has no reliable owner, handling rule, or risk priority.
- A second encryption layer and a customer-managed key answer different threat questions.
- Authorization-aware retrieval is the core data boundary for a grounded agent.
How it works
- Discovery scans metadata and content signals to classify assets; policy and identity controls then enforce handling according to sensitivity and context.
- Encryption keys protect data keys or content, while authorization and network controls decide who can ask the service to decrypt and return data.
Objects and administrative surfaces
- Purview Data Map, scans, collections, classifications, lineage, sensitivity labels, data owners, risk registers, DLP policies, and retention controls.
- Key Vaults and managed HSMs, private endpoints, SQL and Cosmos identities, Storage authorization, encryption settings, audit logs, Defender plans, and alerts.
When to use it
- Use a unified data-security architecture whenever information crosses analytics, operational stores, collaboration, and AI workloads.
Security and governance implications
- Assign data owners, key custodians, platform operators, model owners, and threat responders with incompatible duties separated where risk requires.
Troubleshooting signals
- If classification coverage is incomplete, verify source registration, scan credentials, network access, supported formats, rules, and ownership.
- If a private data service remains exposed, trace DNS, private endpoint approval, public-network settings, firewall paths, and application identity.
More detail
- Evaluate discovery and classification solutions and use their output to prioritize protection.
- Select encryption layers and key-management responsibilities deliberately.
- Design Azure data and AI safeguards with Defender threat detection as one layer.
Ready for the quiz?
- When does infrastructure encryption add value beyond default service encryption?
- Which controls limit a grounded model from exposing excessive source data?
- How do Defender plans complement database preventive controls?
Related objectives
- D4.3.S1 — Evaluate solutions for data discovery and classification
- D4.3.S2 — Specify priorities for mitigating threats to data
- D4.3.S3 — Evaluate solutions for encryption of data at rest and in transit, including Azure Key Vault and infrastructure encryption
- D4.3.S4 — Design security for data used in AI workloads
- D4.3.S5 — Design a security solution for data in Azure workloads, including Azure SQL, Azure Synapse Analytics, and Azure Cosmos DB
- D4.3.S6 — Design a security solution for data in Azure Storage
- D4.3.S7 — Design a security solution that includes Microsoft Defender for Storage and Microsoft Defender for Databases