6.2 Database Auditing

Microsoft Certified: Cloud and AI Security Engineer Associate SC-500

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Skills Measured & Weightings 1.3 Study Path, Prerequisites & Exam Strategy

2 Microsoft Entra ID Secure Access

2.1 Privileged Identity Management (PIM) 2.2 Conditional Access Policies 2.3 MFA and Passwordless Authentication 2.4 Application Identities, OAuth Consent & Managed Identities

3 Azure Key Vault Secrets and Keys

3.1 Deploy and Configure Key Vault 3.2 Access Control and Firewall for Key Vault 3.3 Keys, Secrets, Certificates & Defender for Key Vault

4 Governance, Policy & RBAC

4.1 Azure Policy for Security Controls 4.2 Defender for Cloud Compliance & Security Standards 4.3 Resource Locks and Azure RBAC 4.4 Custom Roles, Overprivileged Access, Backup & IaC Security

5 Secure Storage Accounts

5.1 Storage Account Security Fundamentals 5.2 Storage Firewalls and Access Policies 5.3 Defender for Storage

6 Secure Databases

6.1 Azure SQL Platform Security 6.2 Database Auditing 6.3 Defender for Databases

7 Network Security Groups & Virtual Network Manager

7.1 Network Security Groups and Application Security Groups 7.2 Azure Virtual Network Manager Security Admin Rules 7.3 Virtual WAN and VPN Security

8 Private Access, Private Link & Azure Firewall

8.1 Microsoft Entra Private Access 8.2 Private Endpoints and Private Link 8.3 Azure Firewall 8.4 Network Watcher Diagnostics and Effective Rules

9 Security for AI Workloads

9.1 Purview DSPM for AI and Data Overexposure 9.2 Copilot Studio Protection and Agent Management 9.3 Microsoft Entra Agent ID Security 9.4 Defender for AI, Foundry Guardrails & AI Gateway

10 Secure Servers and Virtual Machines

10.1 Disk Encryption 10.2 Azure Bastion and JIT VM Access 10.3 Azure Arc and Defender for Servers 10.4 Trusted Launch, VM Security Features & Machine Configuration

11 Application Platform Security

11.1 Containers: AKS, ACR, ACI, Container Apps & Defender for Containers 11.2 Azure Functions and Logic Apps Security 11.3 Azure App Service Security 11.4 Web Application Firewall and API Management Protection

12 Defender for Cloud Security Posture

12.1 Defender CSPM and Secure Score 12.2 Workload Protection Plans and Multicloud Connectors 12.3 Vulnerability Management and Defender EASM

13 Microsoft Sentinel Activity and Event Collection

13.1 Workspaces, Roles & Content Hub 13.2 Data Connectors, Syslog/CEF & Windows Event Collection 13.3 Custom Tables, Retention & Purview Audit 13.4 Automation Rules and Playbooks

14 Microsoft Security Copilot & Final Review

14.1 Microsoft Security Copilot Workspaces and Roles 14.2 Plugins and Security Agents 14.3 Final Review and Exam-Day Strategy

6.2 Database Auditing

Key Takeaways Explain This Topic AI

Azure SQL Database auditing tracks selected database events to Azure Storage, Log Analytics, and/or Event Hubs for compliance, forensics, and anomaly investigation.

Server-level auditing covers all databases on a logical server; database-level auditing scopes a single database—avoid redundant dual enablement that multiplies log volume unless you have a deliberate reason.

Azure SQL Managed Instance uses SQL Server Audit patterns (CREATE SERVER AUDIT / specifications) to storage URL or EXTERNAL_MONITOR, plus diagnostic settings for Log Analytics and Event Hubs.

Default action groups typically include batch completion and successful/failed database authentication events; tune retention and destinations to investigation and compliance needs.

Auditing is the evidence trail; Defender threat alerts are detections—use both: alerts to start investigations, audit logs to prove who ran which statements when.

Last updated: July 2026

Role of Auditing on SC-500

The blueprint calls out Configure database auditing for Azure SQL Database and Azure SQL Managed Instance . Auditing answers: Who did what, on which database, from where, and when? It supports regulatory evidence, insider-threat review, and incident response. It is not the same as Advanced Threat Protection, which raises alerts on suspicious patterns—though both may appear together in secure SQL designs.

Azure SQL Database and Synapse Auditing Overview

Auditing for Azure SQL Database (and Azure Synapse Analytics SQL pools where supported) tracks database events and writes audit records to:

Destination Best for Notes

Azure Storage Long-term archive, immutable store options, offline review Append blobs; .xel -style audit files; open with SSMS or sys.fn_get_audit_file

• Log Analytics Interactive KQL, workbooks, Microsoft Sentinel correlation Strong choice for SOC investigation
• Event Hubs Streaming to third-party SIEM or custom pipelines Near-real-time export

You can enable multiple destinations. Auditing helps retain trails, report activity, and analyze discrepancies—Microsoft notes it facilitates compliance programs but does not by itself “guarantee” compliance certification.

Performance caveat: Auditing is optimized for database availability. Under extreme load, not every marked event may be recorded. Design critical audits with that resilience trade-off in mind and validate with Defender alerts and platform metrics.

Server-Level vs Database-Level Auditing

Scope What it covers When to use

Server (logical server) auditing Events for databases on that server (modern server audit architecture uses a server-level session capturing all DBs) Default for estate-wide policy: one configuration, consistent coverage

Database auditing Single database Different retention/destination per database, heavy OLTP isolation, or exceptions

• Practical guidance
• Enabling server-level auditing is usually enough for “audit everything on this server.”

Enabling both server and database auditing for the same events can duplicate records and inflate cost—LinkedIn/field reports and Microsoft large-OLTP guidance warn about volume.

For many busy databases , Microsoft recommends considering database-level auditing with reviewed action groups so each DB has its own log folder and queries stay manageable, instead of one enormous shared stream.

Server auditing architecture notes (exam-relevant)

Microsoft re-architected server auditing for Azure SQL Database for reliability alignment with SQL Server/MI patterns:

Server audit logs in storage may consolidate under a master folder rather than per-database folder names (older layouts differed).

Read-only replica logs may also land in the master folder; filter with replica-related columns when investigating.

Viewing certain audit data can require VIEW DATABASE SECURITY AUDIT (and related permissions) in the user database.

You do not need every internal detail memorized, but you should know: scope (server vs database), destinations, and that dual enablement multiplies volume.

What Events Are Captured?

Auditing uses action groups (categories of events). Default configurations commonly emphasize:

• Action group (conceptual) Captures
• BATCH_COMPLETED_GROUP (and similar batch events) Completed batches—queries and procedure executions
• SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP Successful logins to the database
• FAILED_DATABASE_AUTHENTICATION_GROUP Failed SQL authentication attempts that reach the database

Additional groups exist for permission changes, schema object access, and other security-relevant operations depending on product surface. For Azure Synapse SQL pools, support may be limited to default audit action groups only—another exam nuance.

Important capture nuances

Statement length: Audit fields such as statement and data sensitivity information may truncate around 4,000 characters —very long batches are only partially recorded.

Temp objects: tempdb /temporary table auditing is constrained; source table activity is the reliable trail for many insert-via-temp patterns.

Microsoft Entra failed logins: As noted in platform security, failed Entra authentications may not appear in SQL audit the same way SQL password failures do; check Microsoft Entra sign-in logs .

Successful Entra and SQL logins that establish a database session are auditable when the right groups are enabled.

Retention and Immutable Storage

Setting Guidance

SQL Auditing retention (storage) Configure retention days on the audit destination; 0 often means unlimited depending on UI/API

Changing from unlimited to N days Typically applies to new logs after the change; older unlimited-period blobs may remain

Storage immutability Use Azure Storage immutable policies with Allow protected append writes (append blobs / block and append)— None is not valid for SQL audit append patterns

Time-based immutability vs SQL retention Storage retention interval must be shorter than SQL Auditing retention when combining; unsupported combos include storage policy set while SQL retention is 0

Log Analytics retention Controlled by workspace table retention / commitment tiers—plan cost vs investigation window

Secure the log store independently: storage firewalls/private endpoints, RBAC ( Storage Blob Data Contributor for writers such as managed identity scenarios), and separate readers for auditors vs DBAs.

Storage behind VNet/firewall: Prefer general-purpose v2 accounts for audit write patterns Microsoft documents. Authentication mode to storage must match account settings (access keys vs Microsoft Entra / managed identity). If the SQL server has outbound restrictions, allowlist the storage FQDN and re-save auditing configuration after network changes.

Azure SQL Managed Instance Auditing

Managed Instance auditing follows SQL Server Audit more closely than the Database portal experience:

To Azure Storage (URL): Create a private container, establish a credential (historically SAS-based for the container URL), CREATE SERVER AUDIT ... TO URL (PATH=..., RETENTION_DAYS=...) , create server or database audit specifications , then ALTER SERVER AUDIT ... WITH (STATE = ON) .

To Log Analytics / Event Hubs: Enable diagnostic settings on the MI for SQLSecurityAuditEvents (and DevOps/support operation logs if used), create CREATE SERVER AUDIT ... TO EXTERNAL_MONITOR , specifications, then enable the audit.

Microsoft Support operations auditing: Optional separate server audit that records Microsoft support engineer operations during support cases—enable deliberately; enabling the checkbox on an existing audit can overwrite intent so only support ops are logged.

Differences vs SQL Server on-prem exist (URL targets, EXTERNAL_MONITOR, cloud identity patterns). For SC-500, remember: MI = SQL Audit objects + diagnostics , Database = auditing blade with Storage/LA/EH destinations , both produce investigation evidence.

• Using Audit Logs for Investigations
• Typical investigation flow

Trigger: Defender for SQL alert, user report, or compliance sampling request.

Scope time window and identity: UPN, client IP, application name, database name.

Query the right store:

Log Analytics: search SQLSecurityAuditEvents / AzureDiagnostics audit categories; filter by LogicalServerName, database_name, client_ip, principal.

Storage: browse container hierarchy or sys.fn_get_audit_file against blob paths.

Event Hubs: downstream SIEM correlation with Entra and NSG/Firewall logs.

Correlate: Pair SQL batches with Entra sign-ins, Key Vault access (if secrets used), and app logs.

Contain: Disable principal, rotate credentials, tighten firewall/private access, revoke roles.

Preserve evidence: Export relevant audit ranges; verify retention will not age them out mid-case.

Example investigation questions audit can answer

• Question Audit evidence
• Did this login succeed last night? Authentication success events + timestamp/IP
• Who dropped a table? DDL/batch events with principal and statement
• Was there mass SELECT before exfiltration alert? Batch completed events volume by principal
• Did a support engineer touch the MI? Support operations audit (if enabled)

Scenario: SOC receives a SQL injection alert from Defender for SQL on sqldb-orders . They open Log Analytics for the server’s audit diagnostic, filter the database and the 15-minute window, find repeated batches with tautology patterns from an app managed identity—and also interactive batches from a human Entra user who should only use the portal. Outcome: fix the app parameterization, revoke the human’s elevated role, confirm server audit retention ≥ 90 days for the regulator, and keep Defender enabled.

SC-500 Exam Traps (Auditing)

Auditing ≠ threat protection; one records, one detects.

Server vs database scope: know coverage and duplication risk.

Destinations are Storage, Log Analytics, Event Hubs—not “only Activity Log.”

MI configuration is not identical to Database portal toggles.

Failed Entra logins may require Entra logs, not only SQL audit.

Immutable storage for audit needs append write allowance.