4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Implement security for databases
Contoso Pharmaceuticals runs an Azure SQL Managed Instance named sqlmi-contoso-eu with 15 databases. For one database named db-trials, the compliance team needs an audit of only the SCHEMA_OBJECT_CHANGE_GROUP and DATABASE_PERMISSION_CHANGE_GROUP actions, delivered to the Log Analytics workspace law-contoso-sec. The other 14 databases must not be audited.
What should you do?
- AIn the Azure portal, enable auditing on sqlmi-contoso-eu with Log Analytics as the destination and select law-contoso-sec.The portal auditing experience for a managed instance configures a server-level audit to Azure Storage; it records all databases and does not let you choose database-specific action groups or a Log Analytics destination.
- BCreate a server audit with CREATE SERVER AUDIT ... TO EXTERNAL MONITOR, create a database audit specification in db-trials for the two action groups, and add a diagnostic setting on sqlmi-contoso-eu that sends SQLSecurityAuditEvents to law-contoso-sec.On a managed instance, Log Analytics and Event Hubs destinations require the audit to target EXTERNAL MONITOR, the database audit specification scopes the actions to one database, and the diagnostic setting selecting the SQLSecurityAuditEvents log category routes the events to the workspace.
- CCreate a server audit with CREATE SERVER AUDIT ... TO URL pointing at a storage account, and create a database audit specification in db-trials for the two action groups.TO URL writes audit files to blob storage. The requirement is delivery to Log Analytics, which needs the EXTERNAL MONITOR target plus a diagnostic setting.
- DEnable database-level auditing on db-trials from the Azure portal and select the two action groups.The portal does not expose per-database auditing or action-group selection for a managed instance; that granularity is available only through T-SQL audit specifications.
Why: Auditing for Azure SQL Managed Instance is configured with T-SQL rather than the portal experience used for Azure SQL Database. A server audit defines the destination: TO URL for a storage account, or TO EXTERNAL MONITOR when events should flow to Log Analytics or Event Hubs through an Azure Monitor diagnostic setting on the managed instance that selects the SQLSecurityAuditEvents category. A database audit specification then selects the action groups to capture and scopes them to a single database, which is what keeps the other 14 databases out of the audit. The deciding constraints are per-database scope with specific action groups and a Log Analytics destination. The trap is the TO URL option, which is the right syntax for storage but cannot reach a workspace.
Implement security for databases
VanArsdel Ltd has 15 Azure Cosmos DB accounts in the subscription sub-vanarsdel-data. Only two accounts, cosmos-payments and cosmos-identity, hold regulated data; the other 13 hold public catalog data. The security team wants threat detection, such as alerts for suspicious key extraction and SQL injection attempts, on the two regulated accounts, and the CFO requires that spending be limited to those two accounts.
What should you do?
- AEnable the Defender for Azure Cosmos DB plan at the subscription level in Defender for Cloud environment settings.Subscription-level enablement protects all 15 accounts and bills for all of them, which conflicts with the requirement to limit spending to two accounts.
- BEnable Microsoft Defender for Azure Cosmos DB at the resource level on cosmos-payments and cosmos-identity only.Defender for Azure Cosmos DB supports per-resource enablement from the account's Microsoft Defender for Cloud blade or through ARM, so only the two regulated accounts are protected and billed.
- CEnable the Defender for open-source relational databases plan at the subscription level.That plan protects PostgreSQL, MySQL, and MariaDB servers. It does not cover Azure Cosmos DB.
- DEnable Defender CSPM on the subscription and review the attack paths for the two accounts.Defender CSPM provides posture recommendations and attack path analysis. It does not generate runtime threat alerts for Cosmos DB operations.
Why: Defender for Azure Cosmos DB analyzes the control-plane and data-plane activity of an account to detect threats such as key extraction, unusual access patterns, and SQL injection attempts, and it is one of the Defender for Databases plans that can be enabled at either subscription or individual resource scope. Subscription scope is the recommended default because it automatically protects new accounts, but when the deciding constraint is cost containment to specific resources, resource-level enablement is the correct implementation. The trap is choosing a plan for a different engine or substituting posture management for threat detection. Note that if the subscription plan is later enabled, it overrides and protects all accounts.
Implement security for databases
Trey Research operates three database estates in one subscription: 20 Azure SQL databases, eight SQL Server 2022 instances on Azure virtual machines, and four Azure Database for PostgreSQL flexible servers. Microsoft Defender for Azure SQL database servers is already enabled. The security team now wants vulnerability assessment findings and threat alerts, such as brute-force and SQL injection detections, for the SQL Server instances running on the virtual machines.
What should you do?
- AEnable the Defender for SQL servers on machines plan on the subscription and ensure each virtual machine is registered with the SQL IaaS Agent extension.Defender for SQL servers on machines is the plan that protects SQL Server on Azure VMs and Azure Arc-enabled SQL Server instances. The current agent architecture uses the SQL IaaS Agent extension (or the Arc SQL Server extension) to discover instances and deploy the Defender for SQL extension; the Azure Monitor Agent is no longer required.
- BEnable the Defender for open-source relational databases plan on the subscription.That plan covers Azure Database for PostgreSQL, MySQL, and MariaDB. It does not protect SQL Server on virtual machines.
- CEnable Defender for Servers Plan 2 on the subscription.Defender for Servers protects the operating system layer with EDR and vulnerability scanning of installed software. It does not perform SQL vulnerability assessment or detect SQL-specific attack patterns.
- DExtend the existing Defender for Azure SQL database servers plan to include the virtual machines.Defender for Azure SQL database servers covers only the PaaS offerings: Azure SQL Database, SQL Managed Instance, and Azure Synapse dedicated SQL pools. It has no scope setting for VMs.
Why: Microsoft Defender for Databases is an umbrella of four separately priced plans: Defender for Azure SQL database servers (PaaS), Defender for SQL servers on machines (SQL Server on Azure VMs, on-premises, and multicloud through Azure Arc), Defender for open-source relational databases (PostgreSQL, MySQL, MariaDB), and Defender for Azure Cosmos DB. Each plan protects a distinct engine and deployment model, so the deciding factor is simply which estate needs coverage, here SQL Server on virtual machines. The trap is assuming the PaaS plan or the OS-level Defender for Servers plan reaches inside a SQL Server instance; neither does. Since the 2025 plan update the solution no longer depends on the Azure Monitor Agent: on Azure VMs the SQL IaaS Agent extension is the integration point, and non-Azure machines must first be connected with Azure Arc and registered as Arc-enabled SQL Server instances.
Implement security for databases
Lucerne Publishing hosts 30 Azure SQL databases on the logical server sql-lucerne-prod, and new databases are added every month by a deployment pipeline. The security operations team requires that audit events from every database, including databases created in the future, land in the Log Analytics workspace law-lucerne-sec so that they can be queried with KQL. You must minimize administrative effort.
What should you do?
- AEnable auditing on each of the 30 databases with Log Analytics as the destination and add a step to the pipeline that enables auditing on new databases.Database-level policies work, but 30 individual configurations plus pipeline changes are more effort than one server-level policy that already covers new databases.
- BEnable server-level auditing on sql-lucerne-prod with Log Analytics as the destination and select law-lucerne-sec.A server auditing policy applies to every existing and future database on the server. Choosing Log Analytics writes events to the workspace, where they appear in the AzureDiagnostics table under the SQLSecurityAuditEvents category.
- CEnable Microsoft Defender for Azure SQL on the subscription and connect it to law-lucerne-sec.Defender for SQL provides vulnerability assessment and threat alerts. It does not capture the detailed database audit event stream.
- DEnable server-level auditing on sql-lucerne-prod with a storage account as the destination, then configure a Log Analytics data export rule from the storage account.Auditing can target Log Analytics directly, so routing through a storage account adds components and effort. Log Analytics data export also goes in the other direction, from a workspace to storage.
Why: Azure SQL auditing can be defined at the server level or the database level, and a server policy is inherited by every database on the logical server, including databases created later. That inheritance is what satisfies the future-databases requirement with a single configuration. Auditing supports three destinations, a storage account, Log Analytics, and Event Hubs, and selecting Log Analytics writes events directly into the workspace, where they are queried from the AzureDiagnostics table with Category == "SQLSecurityAuditEvents". The trap is confusing Defender for SQL threat detection with auditing or building a storage-to-workspace pipeline when a direct destination exists. If both a server and a database policy exist, both are honored and events are written twice, so avoid redundant database-level policies.