A new Azure SQL Managed Instance will store lock telemetry and must stay off the public Internet. Which network placement and endpoint setting should the security engineer use?
Select an answer to reveal the explanation.
Short Explanation
SQL MI wants its own subnet and the public endpoint left off. Clients should hitch a ride through the VNet—VPN, peering, Private Link—not a public TDS door.
Full Explanation
Azure SQL Managed Instance that stores lock telemetry and must stay off the public Internet belongs in a dedicated MI subnet with the public endpoint left disabled. Clients then use the VNet-local endpoint through VPN, peering, or Private Link patterns, keeping the TDS listener off the public Internet while preserving the platform’s required network placement.
Enabling the public TDS listener and protecting it only with dynamic data masking fails by concept: masking is a Domain 3 disclosure control and does not privatize the network endpoint. Deploying the MI into a shared App Service subnet and relying on Always Encrypted fails by concept: MI requires its own dedicated subnet, and Always Encrypted does not provide network isolation. Turning on Transparent Data Encryption and treating it as a substitute for disabling the public endpoint fails by concept: TDE protects data at rest, not inbound network exposure.
Exam caveat: AZ-500 separates Domain 2 MI networking (subnet, NSG/UDR, public endpoint) from Domain 3 encryption and Entra database controls. Operational check: create the dedicated MI subnet with required delegation/NSG patterns, deploy MI with public endpoint disabled, verify only private connectivity reaches the instance, and confirm VPN/peering/Private Link clients can authenticate successfully.