Microsoft AZ-500: Data, Storage and Database Security — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Part of the Microsoft Azure Security Engineer Associate AZ-500 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure data, storage, and database security centers on minimizing trust, isolating data planes, encrypting everywhere, and operationalizing least privilege with auditable access paths. This section explains how to harden Azure Storage, Azure SQL, and Azure Cosmos DB, choose the correct identity and key strategy, and prevent data exfiltration. Every control described is accompanied by the operational reasoning behind it so you can justify and maintain the configuration in production.

Securing Azure Storage Accounts and Data Access

Storage account authorization and sharing

• Azure RBAC for Azure Storage: Prefer Azure AD–based authorization (Blob and Queue) via built-in roles such as Storage Blob Data Reader/Contributor. Reasoning: token-based, time-bound access via Conditional Access, logged in Entra ID; avoids perpetual account keys and supports just-in-time assignment.
• Shared keys: The account’s primary/secondary keys grant full data-plane rights. Disable key usage in code and rotate often. Reasoning: shared keys are bearer secrets without user binding or CA; compromise = total data exposure.
• SAS types:
  • Service SAS: Grants scoped access to specific resources (blob, file, queue, table) with permissions, IP, protocol, and time limits. Reasoning: precise least privilege for apps that cannot use AD tokens.
  • Account SAS: Broader surface (e.g., across services); use sparingly. Reasoning: expands blast radius if leaked.
  • User delegation SAS: Issued using Azure AD and a user delegation key for Blob. Reasoning: binds to Azure AD identity and CA; superior auditability and revocation.
• Stored access policies: Define reusable constraints (expiry, permissions) for SAS on containers/shares; revoking or updating the policy invalidates SAS issued under it. Reasoning: central revocation without regenerating tokens embedded in clients.

Example: generate a user delegation SAS for a blob with Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Service security by type

• Blob/Queue/Table: Use Azure AD RBAC where supported (Blob, Queue). Set AllowBlobPublicAccess to false, require HTTPS, enable versioning and soft delete. Reasoning: removes anonymous exposure paths and enables recoverability.
• Azure Files: Use Azure AD Kerberos for SMB with Entra ID (or AD DS integration) and enforce least-privilege share/file permissions. Require SMB encryption. Reasoning: identity-bound access with transport security over SMB; no shared keys in user space.
• Table service: Use SAS with strict IP/time constraints and avoid account SAS. Reasoning: service-level granularity isn’t as rich; scope aggressively.

Network isolation for all storage services

• Storage firewall rules: Restrict to selected public IP ranges only when Private Link is not feasible. Reasoning: reduces attack surface but still traverses public internet.
• Private endpoints: Prefer Private Link for Blob, Queue, Table, and Files. Map private DNS zones to resource-specific names. Set public network access to Disabled. Reasoning: traffic stays on Azure backbone; resource identity is validated via private DNS; mitigates exfiltration to lookalike services.
• Service endpoints and policies: If Private Link is not an option, enable service endpoints and apply service endpoint policies to restrict egress to specific storage accounts. Reasoning: constrains traffic even over virtual network egress; limits risk of sending data to attacker-owned accounts.

Operational settings to standardize

• Enforce HTTPS only, minimum TLS 1.2.
• Disable shared key access for Blob and Queue if using AD (feature support dependent).
• Immutability policies on critical containers/shares for regulatory retention and ransomware resilience.

Encryption and Key Management

Encryption at rest layers

• Service-managed keys (SMK): Default server-side encryption managed by Azure. Reasoning: zero operational overhead; suitable for many workloads.
• Customer-managed keys (CMK): Keys in Key Vault or Managed HSM for Storage, SQL, and Cosmos DB. Reasoning: externalized trust boundary, customer control of rotation/revocation, and compliance evidence.
• Infrastructure encryption (double encryption): Additional layer using separate keys. Reasoning: defense-in-depth if storage media encryption is bypassed or a crypto boundary is compromised.

Key rotation and operations

• SMK rotate automatically; no action required.
• CMK rotate by creating a new key version, granting wrap/unwrap permissions, and re-pointing the resource to latest version (or versionless key reference when supported). Reasoning: non-disruptive rotation with auditable change.
• Protect keys with Key Vault soft delete and purge protection; control admin via RBAC and data-plane via access policies or RBAC (for Managed HSM, use RBAC). Reasoning: prevents destructive key loss and enforces least privilege.

Example: set CMK for a storage account

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Encryption scopes

• Use per-container encryption scopes in Storage when different data sets require distinct keys. Reasoning: segment blast radius and enable differential key lifecycles.

Database Platform Security: Azure SQL and Azure Cosmos DB

Azure SQL authentication and access

• Microsoft Entra authentication: Create a server-level Azure AD admin; use contained database users (CREATE USER FROM EXTERNAL PROVIDER). Reasoning: avoids SQL logins/passwords and enables Conditional Access and PIM.
• Contained users: Identity lives in the database, not master. Reasoning: simplifies geo-restore and failover without re-provisioning logins.
• Firewall rules: Avoid broad client IP rules; prefer Private Link with public network access disabled. If IP rules are required, scope to exact addresses and automate review. Reasoning: narrows attack surface and reduces discovery through public endpoints.
• Private endpoints: Route all data-plane traffic over VNet with private DNS. Reasoning: eliminates exposure and simplifies exfiltration prevention.
• Authentication patterns: Use Active Directory Integrated (for domain-joined devices) or interactive/device code to obtain tokens; service workloads should use managed identities. Reasoning: removes passwords and enables token lifetimes/policies.

Data protection features

• Transparent Data Encryption (TDE): On by default; encrypts data/logs/backups. Reasoning: protects at-rest media without app changes. Use TDE with CMK for externalized control.
• Always Encrypted: Client-side encryption for sensitive columns with keys in Key Vault. Reasoning: prevents SQL operators or the engine from seeing plaintext; use for PII/PCI fields.
• Dynamic Data Masking (DDM): Obfuscates query results for non-privileged users. Reasoning: reduces casual data exposure but is not a security boundary; combine with RBAC.
• Auditing: Send to Log Analytics, Event Hubs, or Storage. Reasoning: creates an immutable trail for investigations and compliance.

Example: enable server-level auditing to Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Vulnerability Assessment (VA): Baselines and scans schema/config; export to storage; integrate with DevSecOps gates. Reasoning: continuous hygiene and drift detection with clear remediation guidance.
• Threat Detection: Detects SQL injection, anomalous logins, login from unfamiliar location, abusive privileges. Reasoning: managed detection with low operational overhead; complements network controls.
• Alert response: Route to Logic Apps, email, SIEM. Create playbooks for triage, user suspension, token revocation, and firewall tighten. Reasoning: codified response reduces mean time to contain.

Azure Cosmos DB security

• Keys and tokens: Primary/secondary keys are high-privilege; rotate regularly. Prefer Azure AD RBAC for data-plane operations with roles like Cosmos DB Built-in Data Contributor/Reader. Reasoning: identity-bound access with CA and audit.
• Network controls: IP firewall allow list for contingency; Private Endpoints as the default path; disable public access if feasible. Reasoning: guaranteed path control and endpoint validation.
• Encryption: At rest by default; enable CMK for additional control. Reasoning: meets external crypto requirements and separation of duties.
• Diagnostic logs and metrics: Enable DataPlaneRequests, ControlPlaneRequests, and API-specific categories (e.g., MongoRequests). Reasoning: end-to-end observability for access patterns, throttling, and anomalous requests.

Monitoring, Classification, and Exfiltration Controls

Key Vault–backed secrets and connection strings

• Use managed identities to retrieve secrets/keys at runtime; never store secrets in code or settings. Reasoning: eliminates credential sprawl and secret rotation in apps.
• App Service/Functions Key Vault reference

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Prefer Azure AD access tokens to SQL over secret-based connection strings when possible. Reasoning: stronger policy and revocation.

Information protection and data classification

• Microsoft Purview Information Protection sensitivity labels: Apply labels with encryption and usage rights for documents and emails; integrate with auto-labeling. Reasoning: persistent protection beyond storage boundaries.
• SQL Information Protection (Azure SQL): Use built-in data discovery and classification, recommend labels on columns, and export to Purview. Reasoning: central governance and consistent policy across data estate.

Data exfiltration controls and secure access patterns

• Private Link first: For Storage, SQL, and Cosmos DB. Disable public endpoints. Reasoning: prevents access from the public internet and enforces traffic origin in approved VNets.
• Egress filtering: Use Azure Firewall with FQDN tags and DNAT rules that only permit required Azure endpoints; add service endpoint policies where Private Link is impractical. Reasoning: outbound allow-listing blocks data leakage to attacker-controlled endpoints.
• Resource instance rules: For Storage firewall, allow only specific trusted resource instances (e.g., a Synapse workspace) to access. Reasoning: binds access to known producers/consumers, not just networks.
• SAS hardening: Use user delegation SAS where possible, limit to HTTPS, restrict IPs, minimal permissions, and shortest lifetimes; tie to stored access policies for revocation. Reasoning: reduces token misuse and simplifies emergency invalidation.
• AKS and service endpoints: If relying on service endpoints, use Azure CNI so pods get VNet IPs and inherit endpoint access. Reasoning: bridge container traffic to VNet-native controls; otherwise, endpoints do not apply to NATed pod traffic.
• Logging and analytics: Enable Storage, SQL, and Cosmos DB diagnostic logs to Log Analytics; create alerts for anomalous data volume, SAS issuance spikes, and frequent 403s. Reasoning: early detection of exfiltration attempts.

Practical Problem Scenario

Spotify needs to prevent data exfiltration from developer subnets and AKS workloads to unauthorized Storage and SQL endpoints while enabling CI/CD pipelines to run integration tests.

1. Disable public network access and create Private Endpoints for all production Storage accounts and Azure SQL servers. Reasoning: Forces all data-plane flows over Private Link, eliminating public ingress/egress and enabling strict origin enforcement via VNets and private DNS.

2. Configure private DNS zones with A records mapping the storage and database resource FQDNs to the private endpoint IPs; link all required VNets. Reasoning: Prevents DNS leakage to public endpoints and ensures clients resolve to the intended private resources.

3. In Storage firewalls, add resource instance rules only for the production AKS cluster and build agent scale set identities; set default action to deny. Reasoning: Even within the same VNet, only approved resource identities can access the account, thwarting lateral movement and exfiltration from untrusted workloads.

4. Enforce Azure CNI on AKS and enable service endpoints with service endpoint policies to allow dev namespaces to reach only a dedicated non-prod storage account. Reasoning: Dev pods obtain VNet IPs so network policies apply; endpoint policies constrain any non-private traffic strictly to sanctioned accounts.

5. Replace shared keys with Azure AD RBAC for Blob and Queue in app code; where sharing is unavoidable for tests, issue user delegation SAS with stored access policies and 1-hour expiry. Reasoning: Identity-bound tokens are auditable and revocable; short-lived SAS minimizes risk if a token is exposed in build logs.

6. Enable Defender for SQL with threat detection and Vulnerability Assessment; route alerts and SQL audit logs to a central Log Analytics workspace with automated Logic Apps for triage (disable user, revoke sessions, add temporary firewall deny). Reasoning: Managed detections accelerate containment of SQL injection and anomalous access, while playbooks standardize and speed the response.

7. Use Key Vault for CMK protecting TDE and Storage encryption scopes; enable soft delete and purge protection; rotate keys quarterly and update resource references to the latest key version. Reasoning: Externalized cryptographic control with safe rotation meets compliance and reduces operational error risk.

8. Classify sensitive columns in Azure SQL with SQL Information Protection and onboard to Microsoft Purview; apply MIP sensitivity labels for downstream exports. Reasoning: Persistent labeling travels with data extracts, limiting misuse and enabling DLP tooling to enforce controls across tools and devices.

9. Lock down egress with Azure Firewall to only Azure services required by build/test, using FQDN tags for Storage and SQL and denying wildcard outbound HTTP(S). Reasoning: Positive security model ensures traffic can reach only approved endpoints, preventing data from leaving to attacker domains.

This sequence prevents public access, restricts both who and what can reach data, binds access to identities rather than secrets, and operationalizes monitoring and rapid response—all while preserving developer velocity through scoped, time-bound exceptions.

← Compute · All domains · Key Management →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →