Secure compute, storage, and databases →hardMultiple ChoiceObjective-mapped

AZ-500 Secure compute, storage, and databases Practice Question

A company uses Azure SQL Database with Transparent Data Encryption (TDE) encrypted using a customer-managed key (CMK) stored in Azure Key Vault. The Key Vault is protected by a firewall that denies all public access. The SQL server must be able to access the key for TDE operations. Which additional configuration is necessary in the Key Vault to allow this?

⚠ Common exam trap

It's easy for candidates to confuse network-level controls (private endpoints, firewall rules) with the Azure platform's built-in trust mechanism, mistakenly thinking that a private endpoint or a static IP rule is required when the simpler 'trusted Microsoft services' bypass is the correct and intended solution for PaaS services like Azure SQL Database.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable the 'Allow trusted Microsoft services to bypass this firewall' setting.

When Azure Key Vault is protected by a firewall that denies all public access, the Azure SQL Database service (a trusted Microsoft service) must be explicitly allowed to bypass the firewall to retrieve the customer-managed key for TDE operations. Enabling the 'Allow trusted Microsoft services to bypass this firewall' setting permits the SQL server's managed identity to authenticate and access the key vault without requiring a public IP address or network rule.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Configure a private endpoint for the Key Vault and assign it to the SQL server's virtual network.
Why it's wrong here
A private endpoint grants network-level access from a virtual network to the Key Vault, but the SQL server itself does not reside in a virtual network by default—it is a platform-as-a-service resource. The requirement is for the SQL server’s managed identity to authenticate to the Key Vault, not for network connectivity from a specific subnet. This option is tempting because private endpoints are commonly used to isolate Key Vault access from the public internet, and they would be correct if the SQL server were deployed inside a virtual network (e.g., Azure SQL Managed Instance).
✗
Enable soft-delete on the Key Vault.
Why it's wrong here
Enabling soft-delete on Key Vault is a data protection feature that retains deleted keys, secrets, and certificates for a configurable retention period (typically 7-90 days), and it is indeed required for Azure SQL TDE with customer-managed keys. However, soft-delete does not affect Key Vault's network firewalling or trust settings; it only guards against accidental or malicious deletion of cryptographic objects. It cannot grant the Azure SQL server's managed identity any network access to the Key Vault when the firewall is blocking public traffic, so it fails to address the connectivity issue.
✓
Enable the 'Allow trusted Microsoft services to bypass this firewall' setting.
Why this is correct
This setting allows Azure services like Azure SQL Database, which are trusted by Azure, to access the Key Vault even when the firewall is enabled to deny public traffic. It is the required configuration to allow TDE operations.
✗
Add a firewall rule to allow traffic from the Azure SQL Database's public IP address.
Why it's wrong here
Azure SQL Database uses a range of public IPs that are not static and can change. It is not practical to maintain IP-based rules, and this would also compromise security by allowing broader IP ranges.

Visual reference

Go deeper

AZ-500 Secure compute, storage, and databases Practice Question

Why each option matters

Option-by-option breakdown

Related to this question