Secure storage, databases, and networking
Azure Database Security
CoreHarden Azure database platforms, record auditable events, and enable the correct Defender plan across heterogeneous database services.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
Database security combines identity, network isolation, encryption, server and database configuration, auditing, vulnerability findings, and threat alerts. An audit destination is evidence, not prevention.
Must Know
- Use Microsoft Entra authentication where appropriate, minimize SQL logins, configure firewall or private connectivity, and keep encryption protections enabled.
- Transparent data encryption protects data files at rest; Always Encrypted protects selected values from the database engine for supported client patterns.
- Azure SQL auditing records selected database and server events to a configured destination for investigation and compliance.
- Server-level auditing can cover databases on a logical server; database-level policy can be used when a database needs different settings.
- Defender for Databases is enabled through Defender for Cloud plans and produces vulnerability or threat insights for supported database services.
- Auditing, vulnerability assessment, and threat protection answer different questions: what happened, what is weak, and what suspicious activity was detected.
Compare and Distinguish
- TDE encrypts stored database files; TLS protects transport; Always Encrypted limits plaintext exposure for selected columns.
- Auditing preserves activity records; Defender alerts on suspicious behavior; posture recommendations identify insecure configuration.
- A logical-server firewall rule has broader reach than a database user or contained-database permission.
Scenario examples
- Scenario: Auditors need immutable long-term evidence of failed logins. Think: configure auditing to an appropriate protected destination and retention.
- Scenario: DBAs must not see selected customer values in plaintext. Think: evaluate Always Encrypted rather than relying only on TDE.
- Scenario: Several database engines need threat detection. Think: enable the supported Defender for Databases plans at the proper subscriptions and verify coverage.
Exam traps
- Turning on auditing without a reachable destination or sufficient retention does not meet the evidence requirement.
- TDE does not prevent an authorized query from returning plaintext.
- A Defender alert does not automatically repair the vulnerable configuration that enabled an attack.
- A private endpoint restricts the path but does not define database users or permissions.
Key takeaways
- Harden the platform and the database permission model separately.
- Design auditing around event coverage, destination protection, query access, and retention.
- Enable Defender coverage per supported database resource and investigate its evidence.
How it works
- Clients authenticate, connect through an allowed network path, and receive database permissions independent of platform IAM.
- Audit and Defender pipelines consume activity or signals and send evidence to their configured security surfaces.
Objects and administrative surfaces
- Azure SQL logical server, database, managed instance, Microsoft Entra administrator, firewall, private endpoint, and encryption settings.
- Auditing policy, selected action groups, Log Analytics or storage destination, retention, and diagnostic evidence.
- Defender for Cloud database plans, recommendations, vulnerability results, and alerts.
When to use it
- Use server-level policy for consistent SQL database auditing and database-level policy for justified exceptions.
- Use Defender for Databases for supported threat protection while retaining ordinary audit evidence.
Security and governance implications
- Limit SQL administrators, audit policy editors, and access to audit destinations.
- Monitor public endpoints, firewall exceptions, unmanaged SQL credentials, and uncovered database resources.
Troubleshooting signals
- For missing audit events, verify scope, event categories, destination permissions, ingestion delay, and retention.
- For blocked connectivity, separate DNS and network path, server firewall, Microsoft Entra token, and database user mapping.
More detail
- Configure Azure SQL identity, network, encryption, and platform settings.
- Place auditing at server or database scope and select a durable destination.
- Enable the applicable Defender for Databases protection across the database estate.
- Distinguish posture remediation from incident response.
Ready for the quiz?
- Which encryption control can keep selected columns encrypted from the database engine?
- What must be configured in addition to enabling an audit policy?
- How do a vulnerability finding and a runtime alert differ?
Related objectives
- D2.2.S1 — Implement platform-level security configurations in Azure SQL
- D2.2.S2 — Configure database auditing for Azure SQL Database and Azure SQL Managed Instance
- D2.2.S3 — Configure Defender for Databases protection across Azure database services