Secure compute, storage, and databases practice questions

No additional configuration is needed; Azure Files uses SMB encryption by default and cannot be disabled.

Why wrong: Azure Files does support SMB 3.0 encryption, but the protocol version and encryption are not mandatory by default; the storage account will accept unencrypted SMB traffic unless the 'Secure transfer required' setting is explicitly enabled. Furthermore, the claim that encryption cannot be disabled is incorrect because this setting is fully configurable, and its default value is disabled. Therefore, additional configuration is required to enforce encrypted connections.

Configure a network security group (NSG) rule to block SMB traffic on port 445 that does not use encryption.

Why wrong: An NSG filters traffic based on network-layer attributes such as source/destination IP address, port, and protocol; it has no visibility into the SMB session's encryption state because both encrypted and unencrypted SMB traffic use TCP port 445. A rule blocking port 445 would therefore block all SMB access, including legitimate encrypted connections, rather than selectively blocking only those that lack encryption. Encryption enforcement for Azure Files must be handled at the storage/application layer, not by network security groups.

Set the Azure Files share to use the 'Premium' performance tier; encryption is only available on premium shares.

Why wrong: The premium performance tier is related to storage throughput and latency, and it does enable customer-managed keys (CMK) for Azure Files encryption at rest, but it does not control encryption in transit. SMB encryption enforcement via the 'Secure transfer required' setting is available on both standard and premium file shares, so selecting premium is neither necessary nor sufficient to force SMB 3.0 encryption. The misconception arises from conflating at-rest encryption with in-transit SMB encryption.

Enable the Azure SQL Database server's firewall to allow Azure services to access the server.

Why wrong: Enabling the Azure SQL Database server's firewall with 'Allow Azure Services and resources to access this server' only governs inbound connections to the SQL database endpoint. It does nothing for outbound requests the SQL server makes to Azure Key Vault on behalf of Transparent Data Encryption (TDE). The failure occurs in the Key Vault's network layer, not at the SQL firewall, so this configuration change cannot resolve the access denied error.

Assign a user-assigned managed identity to the SQL server instead of a system-assigned identity.

Why wrong: Assigning a user-assigned managed identity instead of the system-assigned identity does not alter how the Key Vault firewall evaluates incoming requests. Both identity types originate from the same Azure platform and are subject to the vault's default deny-all network rule unless an explicit exemption exists. Switching identity types would only change the security principal used for authentication, not the network path, so the TDE key retrieval would still fail due to the firewall.

Change the Key Vault firewall to allow all networks.

Why wrong: Changing the Key Vault firewall to allow all networks would technically let the SQL server's managed identity reach the vault, but it would expose the entire vault to the public internet. Any entity with a valid Entra ID token and the correct access permissions could then retrieve or wrap keys, drastically increasing the risk of key exfiltration. This violates the security requirement for least-privilege access and ignores the more restrictive 'Allow trusted Microsoft services' exemption that solves the same problem safely.

Configure Azure SQL Database auditing to log key usage.

Why wrong: Enabling Azure SQL Database auditing does not encrypt the data or manage any cryptographic material; it only records login attempts, query activity, and related database events. Auditing can show that a key was used, but it cannot protect the database files at rest or enforce a 12-month rotation schedule. Key usage logs may be useful for reporting, but they do not fulfill the encryption requirement.

Enable Azure Information Protection for the database.

Why wrong: Azure Information Protection is a classification and labeling service for documents and emails, and it does not integrate with Azure SQL Database's storage engine or provide at-rest encryption. Even when labels are applied, the underlying database pages remain unencrypted by TDE, and there is no customer-managed key rotation. This makes it unrelated to both the encryption and rotation requirements.

Enable the key vault for deployment by setting the 'Enabled for deployment' access policy.

Why wrong: The 'Enabled for deployment' access policy is a Key Vault firewall/access policy toggle that allows Azure Resource Manager (ARM) templates to deploy resources by retrieving secrets during template operations. It does not grant any cryptographic key permissions like wrapping or unwrapping, so Azure Disk Encryption cannot use it to access a KEK. This setting is part of the legacy access policy model and is irrelevant to ADE's key operation requirements.

Enable the key vault for disk encryption by setting the 'Enabled for Azure Disk Encryption' access policy.

Why wrong: This setting is a legacy option used in older versions of ADE. While it might work, it is not the recommended approach and is not sufficient by itself without also granting the correct permissions. The modern approach uses RBAC roles.

Add the 'Storage Account Contributor' role for the VMs to access the key vault.

Why wrong: The 'Storage Account Contributor' role is a control-plane role that manages storage accounts, not a data-plane permission on keys or secrets in Key Vault. Azure Disk Encryption does not interact with storage accounts for key access; it needs the ability to perform crypto operations such as 'wrapKey' and 'unwrapKey' on the KEK. Assigning this role would neither grant those Key Vault permissions nor allow VMs to encrypt disks, making it an incorrect fix.

User-assigned managed identity

Why wrong: A user-assigned managed identity is created as a standalone Azure resource, not as a property of the storage account. Even after you assign it to the storage account, it remains an independent object with its own lifecycle, so deleting the storage account does not delete the identity; you must explicitly delete it later to prevent an orphaned identity and stale Azure AD permissions. This manual cleanup requirement violates the prerequisite that the identity be automatically removed when the storage account is removed.

Service principal

Why wrong: A service principal is not an identity you assign directly to a resource; it is created through an Azure AD app registration and requires managing credentials such as a client secret or certificate. Those credentials expire and must be rotated and securely stored, which contradicts a no-credential-management design. Additionally, the service principal is not linked to the storage account's lifecycle, so deleting the storage account leaves the service principal and its Key Vault permissions in place, requiring separate cleanup.

Azure AD user account

Why wrong: An Azure AD user account is a human principal intended for interactive sign-in, not for non-interactive resource authentication. Using one for the storage account would require storing and rotating a user password, and security features like multi-factor authentication or conditional access would disrupt automated key-fetching operations. A user account has no lifecycle relationship with the storage account, making it both insecure and operationally invalid as an Azure resource identity.

Always Encrypted with randomized encryption.

Why wrong: Always Encrypted with randomized encryption uses a new initialization vector for every encryption operation, so identical plaintext values produce different ciphertext each time. This hides data patterns from the database engine but completely precludes equality, range, join, and grouping operations, and even makes indexing on the column impossible. It is appropriate only for columns that are never filtered or sorted, such as free-text notes or individual identifiers that must remain opaque to the database server.

Always Encrypted with secure enclaves.

Why wrong: Always Encrypted with secure enclaves creates a protected memory region within the database engine where encrypted data is decrypted for computation, and the plaintext never leaves the enclave. It leverages Intel SGX or virtualization-based security (VBS) to attest the enclave to the client, allowing the database engine to perform equality, range, pattern matching, sorting, and even in-place operations on encrypted columns without exposing data to DBAs or OS administrators. This solution provides stronger security than deterministic encryption, which leaks frequency patterns, and more functionality than randomized encryption, which blocks all predicates.

Transparent Data Encryption (TDE).

Why wrong: Transparent Data Encryption (TDE) encrypts the entire database at rest, including data files, log files, and backups, using a database encryption key protected by a certificate or asymmetric key. It defends against offline theft of physical media, but it does nothing to restrict what database administrators or anyone with access to the database engine can read because data is transparently decrypted when loaded into memory and processed normally. TDE offers no column-level granularity, no client-side key control, and no ability to perform computations on ciphertext, making it fundamentally different from Always Encrypted features that protect data from privileged database users.

Add the managed identity as an Azure AD admin for the SQL server.

Why wrong: Setting the managed identity as an Azure AD admin for the SQL server is incorrect because it assigns the identity to the server-level `sysadmin` role, granting full administrative control over all databases on that server. This violates least privilege and is far broader than the intended read-only data access. Additionally, an Azure AD admin is a server principal, not a contained database user, so it does not follow the scoped access model recommended for application identities.

Enable Azure AD-only authentication on the SQL server.

Why wrong: Enabling Azure AD-only authentication on the server disables SQL authentication, but it does not by itself grant any specific Azure AD principal access to a database. Authentication and authorization are distinct: an identity must still have a contained database user and appropriate roles like `db_datareader` to read data. This server-level setting is optional and often used for compliance, not as a mechanism to allow managed identity access.

AKS managed identity

Why wrong: Using the AKS cluster's managed identity to pull from ACR grants registry access at the cluster level, meaning any workload running on any node in the cluster can potentially use that identity to obtain images. This violates the policy requiring the use of a dedicated service principal secret, because a managed identity is not a static service principal secret and lacks the per-pod scoping needed to limit access to specific workloads. Worse, a cluster-scoped identity amplifies the blast radius if the cluster or a node is compromised, as the credential is not easily revocable per workload.

ACR admin account

Why wrong: The ACR admin account is a static, shared username and password that carries full registry permissions, including push and delete, far beyond the read-only access needed to pull images. Because it is a single credential with no per-registry or per-repository scoping, any secret leak exposes the entire registry, and the lack of built-in rotation and auditing mechanisms makes it unsuitable for production. A service principal with the AcrPull role would provide a narrowly scoped, independently rotatable credential, which is why the admin account fails the least-privilege and secret-management requirements.

Azure AD pod identity

Why wrong: Azure AD Pod Identity assigns an Azure AD managed identity to individual pods, enabling them to request a token and authenticate to ACR via `az acr login` or token-based pulls; however, this is fundamentally an identity-based mechanism, not a static service principal secret stored in a Kubernetes pull secret. Introducing it for image pulls would require deployed components like NMI (Node Managed Identity) and MIC (Managed Identity Controller), adding complexity and operational overhead while still violating the stated requirement to use a service principal secret. Additionally, the policy specifically forbids using any cluster or pod identity for this purpose, so this approach is not merely suboptimal—it is non-compliant by design.

The Key Vault does not allow access from the Azure platform.

Why wrong: Key Vault does not have a monolithic 'Azure platform' access toggle; access is granted through Azure AD identities and per-service-specific access policies. The Azure Disk Encryption feature specifically requires the 'Azure Disk Encryption for Azure VMs' access policy, not a generic network-level trust or a global bypass. Saying the vault 'does not allow access from the Azure platform' is imprecise because the platform's service principal is allowed only through that specific policy, so the missing policy is the precise underlying issue.

The Key Vault firewall is enabled and blocking access from Azure services.

Why wrong: While enabling the Key Vault firewall can block network calls, firewall rules are evaluated as an additional layer alongside access policies. When the 'Allow trusted Microsoft services' bypass is enabled (which is the default for back-end Azure services like Azure Disk Encryption), the ADE platform can traverse the firewall even if the firewall itself is turned on. Therefore, a firewall being enabled is not the direct cause here; the missing 'Azure Disk Encryption for Azure VMs' access policy is the actual blocker.

The Key Vault does not have the system-assigned managed identity of the VM enabled.

Why wrong: Azure Disk Encryption does not use the VM's system-assigned managed identity for Key Vault authentication; it relies on the Azure Disk Encryption service's own principal to access the vault. The VM's system-assigned identity is irrelevant to ADE's key retrieval process and does not participate in the encryption flow. Enabling that managed identity would not alter the Key Vault's access policy requirements, so it cannot be the source of the failure.

Enable the Key Vault firewall and add the VM's public IP address to the allowed list.

Why wrong: Adding the VM's public IP address to the Key Vault firewall only filters which source IPs are permitted to hit the vault's public endpoint; it does not change the network path the traffic takes. The VM's requests still resolve to Key Vault's public IP address and are routed over the internet/public infrastructure, directly violating the requirement to avoid the public internet. Moreover, a VM without a stable public IP (e.g., behind Azure NAT or in a subnet without a public IP) may not even have a source IP to add, making this approach both insecure and operationally brittle.

Use a service endpoint for Key Vault on the VM's subnet, and assign a managed identity to the VM.

Why wrong: A service endpoint routes traffic from the VM's subnet to the Key Vault service over the Azure backbone, but it still terminates at the service's public endpoint—the vault's public IP address—so it does not provide the isolation of a private IP. Only a private endpoint places a private IP from your VNet in front of the vault, which is what meets the 'no public internet' requirement. Assigning a managed identity to the VM only addresses authentication, not the network path, so this combination fails to deliver the required private connectivity.

Assign a system-assigned managed identity to the VM and grant it access to the Key Vault.

Why wrong: A system-assigned managed identity gives the VM an Microsoft Entra-backed identity that can be granted access to Key Vault secrets, but it solely handles authentication and authorization. It does not affect how the VM reaches the vault; without a private endpoint or service endpoint, the request still goes to the vault's public endpoint over the internet. Network privacy is a separate control-plane concern, so this option cannot satisfy the requirement to keep traffic off the public internet.

Disable public network access on the Key Vault.

Why wrong: Disabling public network access on the Key Vault would make the vault completely unreachable from any public endpoint, including the Azure SQL Database service, because Azure SQL runs in a shared Microsoft network and is not a private endpoint connection unless explicitly configured. This action would not only fail to fix the issue, it would guarantee that the SQL database cannot access the customer-managed key for TDE, causing the firewall to reject every attempt. The correct approach is to configure a selective bypass, not remove all public access.

Add the SQL Database server's system-assigned managed identity to the Key Vault access policy.

Why wrong: A system-assigned managed identity on the SQL Database server would handle authentication and authorization, typically granted via Key Vault access policies with get, wrapKey, and unwrapKey permissions, which are necessary for TDE with customer-managed keys. However, this does not address the network layer: the Key Vault's firewall evaluates the source IP or service tag before any authorization check, so even a properly permissioned identity cannot access the vault if the request is blocked by firewall rules. You need a network exception or private endpoint, not just an access policy.

Enable soft-delete on the Key Vault.

Why wrong: Enabling soft-delete on a Key Vault protects against accidental or malicious deletion by retaining deleted vaults and keys for a configurable retention period, which is a critical safeguard for TDE because losing the key would make the database inaccessible. However, soft-delete has absolutely no effect on the Key Vault's firewall configuration or the network path between Azure SQL Database and the vault. The firewall rejection is a connectivity issue, not a data retention issue, so this setting cannot resolve it.

BlockBlobStorage account with infrastructure encryption

Why wrong: BlockBlobStorage accounts are specifically designed for high-transaction, low-latency block blob workloads and do not offer access tiers such as Cool or Archive. Infrastructure encryption adds a second layer of encryption at the storage infrastructure level, which increases cost but does not reduce storage costs or address archival access patterns. For archival data that is accessed infrequently with minutes-level retrieval, this combination is both functionally incomplete and unnecessarily expensive.

BlobStorage account with Hot access tier and default encryption

Why wrong: A BlobStorage account with the Hot access tier is intended for data that is accessed or modified frequently, and it carries higher per-GB storage costs than Cool or Archive tiers. Archival data stored in the Hot tier will accrue significant storage fees over time, and the BlobStorage account type does not provide the same feature parity and account-level flexibility as general-purpose v2. Default encryption with Microsoft-managed keys is already included in all storage accounts, so the encryption choice does not compensate for the cost-inefficient tier.

General-purpose v1 account with Archive access tier and default encryption

Why wrong: General-purpose v1 accounts are legacy and do not support blob access tiers, so placing blobs in the Archive tier is not actually possible; the tier would need to be on a GPv2 or BlobStorage account. Furthermore, even if the Archive tier were available, rehydrating data from Archive can take up to 15 hours, which conflicts with a requirement for retrieval within minutes. Default encryption does apply to GPv1, but the unsupported tier and excessive retrieval latency make this option technically invalid.

The key vault is in a different Azure region than the VM.

Why wrong: The Azure Disk Encryption workflow uses the Key Vault's URI, which is a network endpoint that is accessible from any Azure region. A Key Vault residing in a different Azure region than the VM does not inherently block key recovery, as the VM contacts the vault over HTTPS rather than relying on regional affinity. As long as the vault's endpoint is reachable and the VM has the correct secrets, the encryption keys can be retrieved regardless of regional placement. Region mismatch alone is never a blocker for Azure Disk Encryption key retrieval.

The key was not created with soft-delete enabled.

Why wrong: Soft-delete is enabled at the vault level, and purge protection is also enabled. The key inherits these settings. If the key had soft-delete disabled, it would not be recoverable at all, but the question states they enabled both features on the vault.

The VM's managed identity does not have 'Key Vault Crypto Service Encryption User' permission.

Why wrong: While permissions are required for encryption operations, the recovery process (using the Azure portal or PowerShell) does not rely on the VM's managed identity; it uses the user's permissions. The issue is network connectivity, not permissions.

Use a virtual network service endpoint and disable public network access.

Why wrong: A virtual network service endpoint routes traffic from your VNet to Azure SQL over the Microsoft backbone, but it does not remove the underlying public endpoint of the managed instance—it merely adds a network-level restriction on the source VNet. Even if you disable public network access as a separate setting, the managed instance is still addressed via a public DNS name, and the configuration does not provide a dedicated private IP address in your VNet. This fails to give the true isolation and service-specific access that a private endpoint delivers, because service endpoints are not a replacement for Private Link and still leave the public endpoint architecture in place.

Configure firewall rules to allow only the IP ranges of Azure Data Factory and deny all other traffic.

Why wrong: Configuring firewall rules to allow only Azure Data Factory IP ranges on the public endpoint still leaves the managed instance publicly resolvable and listening on the internet. Such rules are IP-based, not service-based, so any client whose source IP falls within an allowed range—whether it is genuinely Data Factory or a different resource with a coincidentally matching IP—can connect. Azure Data Factory also does not have a fixed set of public IP ranges; it uses service tags that change over time, making this approach brittle and potentially over-permissive. This neither eliminates public exposure nor restricts access to specific Azure services, so it fails both requirements.

Apply a service tag for Azure SQL Managed Instance in the virtual network NSG.

Why wrong: Service tags in NSGs control outbound traffic to Azure services or inbound traffic from other Azure services, but they do not configure the managed instance itself to be non-public or restrict access to specific services.

Prevention mode

Why wrong: Prevention mode is the enforcement state of an Azure WAF policy: requests matching managed rules are logged and actively blocked with a 403 before reaching the backend. Running a public-facing application in this mode during discovery/assessment would allow WAF false positives to disrupt legitimate traffic, which violates the requirement to first identify attacks without impacting users. The correct phase for observation is Detection mode, which never changes the request outcome.

Logging mode

Why wrong: There is no such thing as a 'Logging mode' in Azure WAF; diagnostics logging is controlled separately through Azure Monitor diagnostic settings and will produce WAF logs whether the policy is in Detection or Prevention mode. Selecting a so-called logging mode would not alter the policy's blocking behavior, so it fails to provide a meaningful WAF configuration choice. The operational decision that matters is whether the policy operates in Detection or Prevention.

Off

Why wrong: Turning the WAF off removes all rule evaluation and, as a result, no WAF-specific log entries are generated for attempted attacks against the application. This leaves the public-facing endpoint without any web application firewall visibility, contradicting the requirement to identify malicious requests. The only way to satisfy the assessment goal is to keep the WAF enabled, preferably in Detection mode.

Use a custom Azure Automation runbook to rotate the key.

Why wrong: A custom Azure Automation runbook can technically rotate the key by calling PowerShell or REST APIs, but it requires writing and maintaining the script, assigning a managed identity, handling failures, and managing runbook schedules. This adds operational complexity and a separate automation dependency when Key Vault already exposes a built-in rotation policy. The requirement specifically calls for a native, no-manual-intervention solution, making a custom runbook an unnecessary and less supportable alternative.

Set a key expiration date of 90 days and manually renew.

Why wrong: Setting a key expiration date of 90 days and manually renewing before each expiry leaves the rotation process dependent on an administrator's schedule and memory. If the renewal is missed or delayed, the key can expire and cause encryption operations for blob storage to fail, making this approach unreliable. A 90-day expiration with manual renewal does not satisfy the 'without manual intervention' condition.

Enable versioning on the storage account and manually create a new key version.

Why wrong: Enabling versioning on the storage account applies to blob object versions for data protection and does not affect the lifecycle of the customer-managed encryption key in Key Vault. Manually creating a new key version in Key Vault is an administrative action, not an automated process, and if the storage account references a versioned key URI, it will keep using the old version until the account is updated. Therefore this option neither automates rotation nor aligns with the native Key Vault rotation behavior.

Store the key in a key vault in each region and use a managed identity to access the key vault.

Why wrong: Replicating keys into a Key Vault in every region adds unnecessary administrative overhead and does not satisfy the region-binding rule. Azure Storage customer-managed keys require a single key vault and key to reside in the exact same Azure region as the storage account; a managed identity only provides authenticated key retrieval, not regional alignment. If the key vault holding the active key is in a different region, encryption setup will fail regardless of how many vaults exist or which managed identity you use.

Use a key stored in an Azure Key Vault with the 'Soft Delete' enabled.

Why wrong: Soft Delete is a Key Vault recovery feature that retains a deleted vault or key for a configurable period (default 90 days), enabling restore after accidental deletion. It has no effect on the physical region of the vault; a key vault with Soft Delete enabled in a different region cannot be used as the encryption-key source for the storage account. Regional affinity is an architectural constraint, not a data-protection toggle.

Use an Azure Key Vault with 'Purge Protection' enabled.

Why wrong: Purge Protection is an optional retention safeguard that prevents a soft-deleted vault or key from being purged until the retention period has expired. It strengthens deletion control but does not influence the storage account's requirement that the key vault be in the same region. A vault with Purge Protection enabled but located outside the storage account's region would still violate the mandatory same-region placement rule for customer-managed keys.

Configure firewall rules to allow only trusted IP addresses

Why wrong: Configure firewall rules to allow only trusted IP addresses controls which source IPs can reach the Azure SQL Database logical server, using the server-level and database-level firewall settings. However, firewall rules operate at the network layer and do not inspect or enforce any TLS protocol version; a client from an allowed IP can still connect using TLS 1.0 or 1.1 unless a separate server-level TLS policy is set. Thus, while useful for limiting access to known hosts, it does not satisfy a requirement that all connections use at least TLS 1.2.

Enable Transparent Data Encryption (TDE)

Why wrong: Transparent Data Encryption (TDE) performs real-time encryption and decryption of database data files, log files, and backups at rest, protecting against physical theft of storage media or offline file access. TDE does not affect the client-to-server network connection: the encrypted data is transparently decrypted by the storage engine before being sent to the application, so it has no influence on whether the wire protocol uses TLS 1.2 or an older, less secure version. Enabling TDE is therefore an at-rest protection control, not a transport encryption policy.

Enable Advanced Threat Protection (ATP)

Why wrong: Advanced Threat Protection (ATP) for Azure SQL Database, now part of Microsoft Defender for SQL, uses behavioral analytics and machine learning to generate security alerts for suspicious activities such as SQL injection, brute-force login attempts, anomalous access patterns, and potentially harmful queries. ATP is a detective and alerting control that surfaces threats after or during an attack, but it does not alter the TLS negotiation process or block clients based on protocol version. Therefore, ATP can help identify attacks over a TLS 1.2 connection but cannot enforce that only TLS 1.2+ connections are established, so it does not meet the stated requirement.

Server-side encryption with Microsoft-managed keys

Why wrong: Server-side encryption with Microsoft-managed keys encrypts Azure Blob Storage at rest using AES-256, and the platform handles all key management, including automatic rotation. However, because Microsoft controls the keys, customers cannot perform on-demand key rotation, cannot revoke a key independently, and cannot meet compliance or audit requirements that mandate customer control over key lifecycle. While this option does protect data against unauthorized external access, it fails the requirement for customer-managed key control.

Client-side encryption

Why wrong: Client-side encryption encrypts data in the application before it is uploaded to Azure Blob Storage, meaning the service only ever receives already-encrypted bytes. While this offers data confidentiality throughout the entire pipeline, it requires significant application code changes to implement and maintain encryption and decryption logic, and it shifts key management and versioning responsibilities to the client. This approach increases overhead, complexity, and the risk of developer errors, and it is not the Azure-native server-side solution implied by the requirement.

Azure Disk Encryption

Why wrong: Azure Disk Encryption is designed for encrypting OS and data disks on Azure virtual machines using BitLocker (Windows) or DM-Crypt (Linux) — it does not apply to Azure Blob Storage. Because blobs are not attached virtual hard disks, configuring Azure Disk Encryption would have no effect on the stored data in blob containers. Thus, although Azure Disk Encryption is a valid encryption control for IaaS workloads, it is the wrong tool for encrypting Azure Blob Storage files.

Azure Defender for SQL

Why wrong: Azure Defender for SQL includes the Vulnerability Assessment feature, but the question asks for the specific feature that scans for vulnerabilities and generates reports, which is the Vulnerability Assessment itself. Azure Defender also includes threat detection and other capabilities not required here.

SQL Auditing

Why wrong: SQL Auditing is fundamentally a logging and tracking mechanism that records database events, such as SELECT, INSERT, UPDATE, and DELETE operations, along with schema changes and successful or failed login attempts, writing them to an Azure Storage account or Log Analytics workspace. Its purpose is compliance auditing, forensic investigation, and anomaly detection at the activity level—it never inspects configurations or permissions for weaknesses, so it is not a vulnerability scanner.

Azure SQL Insights

Why wrong: Azure SQL Insights is a monitoring and diagnostic solution that uses performance telemetry to visualize metrics like CPU, memory, I/O, query wait statistics, and index usage for Azure SQL databases. It is designed to help database administrators detect performance bottlenecks and tune workloads, not to assess security posture or identify vulnerabilities; a database can have excellent performance metrics while still containing critical security misconfigurations that Insights would never report.