6.3 Firewall Rules, Private Links, and Service Endpoints

Why Network Security Matters for DP-300

Azure SQL Database is reachable over the public internet by default, and the first layer of defense is the logical server firewall - the IP allow-list. For the DP-300 exam, network security questions focus on: which firewall scope applies (server vs database), the exact T-SQL procedure name, the behavior of the Allow Azure services toggle, when to use private endpoints vs service endpoints, and how SQL Managed Instance's VNet injection differs from Azure SQL Database's network model.

Server-Level Firewall Rules

The server-level firewall lives on the logical Azure SQL server and applies to every database on that server. You manage it through:

• The Azure portal (Networking pane).
• Azure CLI: az sql server firewall-rule create --server myserver --name AllowHome --start-ip-address 1.2.3.4 --end-ip-address 1.2.3.4.
• PowerShell: New-AzSqlServerFirewallRule.
• REST API.
• T-SQL from a connection that is already allowed in:

EXEC sp_set_firewall_rule @name = N'AllowAppSubnet', @start_ip_address = '10.10.0.0', @end_ip_address = '10.10.0.255';

An IP address 0.0.0.0 as both start and end is a special "allow-all Azure services" rule. Setting start_ip_address and end_ip_address to 0.0.0.0 opens the server to any Azure-internal service that can connect to your server. The Allow Azure services and resources to access this server toggle in the portal creates exactly that 0.0.0.0 rule. The exam trap: this toggle does not allow a specific VNet and does not restrict to your tenant - it allows any Azure tenant's services that know your server name. For production workloads you generally want to replace that toggle with explicit VNet service endpoints or private endpoints.

Database-Level Firewall Rules (Azure SQL Database Only)

Database-level firewall rules are stored inside the user database, not in master, and apply only to that database. They are created only with T-SQL, only from inside an already-allowed connection, and they are supported only on Azure SQL Database - not on SQL Managed Instance, not on SQL Server on VMs.

-- Run inside the user database
EXEC sp_set_database_firewall_rule @name = N'AnalyticsOnly', @start_ip_address = '203.0.113.10', @end_ip_address = '203.0.113.10';

Their purpose is to delegate per-database access (typically in ISV/SaaS scenarios where different tenants share a logical server). The evaluation order is: the engine checks database-level rules first, then server-level rules. If a database-level rule grants access, the connection is accepted even if the server-level rules would deny it. A frequent exam scenario: a tenant needs access to only their own database on a shared server - use a database-level firewall rule scoped to that database.

To remove rules: sp_set_firewall_rule with a NULL start/end or EXEC sp_delete_firewall_rule @name = N'...'; likewise sp_delete_database_firewall_rule for database scope.

Private Endpoints

A private endpoint is a network interface that assigns the logical Azure SQL server a private IP address from your VNet's address space. Traffic from the VNet to the server then traverses the Microsoft backbone rather than the public internet, and the server's public endpoint can be disabled entirely. Configuration:

1. Create a private endpoint in a subnet of your VNet, connecting to the target Azure SQL server (Microsoft.Sql/servers).
2. The private endpoint gets a private IP from that subnet.
3. The endpoint integrates with a private DNS zone (privatelink.database.windows.net) so the server's hostname resolves to the private IP from within the VNet.
4. On the server, set Public network access to Disabled (the publicNetworkAccess property = Disabled) so only private endpoint traffic is accepted.

With public access disabled, connections from outside the VNet (and from on-premises without hybrid DNS) cannot reach the server. The exam pattern: when a scenario says "the database must never be reachable over the public internet" or "must only be reachable from inside the corporate VNet", the answer is private endpoint + public network access disabled, not just a firewall rule (which leaves the public endpoint open, just with an allow-list).

Private Link vs Service Endpoints

A common exam contrast. Virtual network service endpoints (for Microsoft.Sql, regional scope) extend your VNet identity to the Azure SQL server and let the server allow traffic specifically from that VNet/subnet. The traffic still uses public IP addresses and the public endpoint - it is just restricted to your VNet's traffic. Private Link (private endpoints) gives the server a private IP in your VNet and lets you disable public access entirely.

Service endpoints are simpler and free; private endpoints cost an hourly fee plus per-GB data processing but provide the strongest isolation. Choose private endpoints when the requirement is "no public access", "on-premises reach without traversing the internet", or "private IP only". Choose service endpoints when you want to restrict to a VNet but the public endpoint can stay.

Network Security Groups and Managed Instance

SQL Managed Instance takes a different network model. It is deployed into a dedicated subnet inside your VNet - VNet injection - and the subnet must be delegated to Microsoft.Sql/managedInstances. The instance is reachable only from inside the VNet (or via a configured public endpoint if you explicitly enable one). Access control is through network security groups (NSGs) attached to that subnet, with rules for the management ports (9000-9003, 1438, 1440-1442) that Azure uses to maintain the instance, plus your own rules for client traffic on 1433.

Key NSG requirements for SQL MI:

• Inbound rules must allow management ports from the AzureResourceManager and AzureCloud service tags (or specific ranges), and port 1433 from your client subnets.
• Outbound rules must allow communication to Azure Storage, Azure Key Vault, Azure Active Directory (Microsoft Entra ID), and Azure SQL configuration endpoints - typically via AzureCloud service tag.
• The subnet cannot be shared with other workloads, must be large enough (Microsoft recommends /24 or larger) for future scaling, and NSG changes can take several minutes to apply.

A heavily tested trap: you cannot put a SQL MI subnet behind an NSG that blocks AzureCloud or the management ports, because Azure's management plane cannot reach the instance and the instance goes unhealthy. When a scenario describes a SQL MI becoming unreachable after a network team tightened the NSG, the answer is to allow the management ports and service tags, not to reconfigure the SQL MI.

Hybrid Connectivity and Minimum Public Network Access

For on-premises clients, two patterns work:

• ExpressRoute or site-to-site VPN + private endpoint with private DNS - the cleanest, traffic stays on private IP throughout.
• ExpressRoute + service endpoints - traffic egresses on-premises via the ExpressRoute peering, then hits the public endpoint with VNet identity.

The PublicNetworkAccess property on Azure SQL Database (Enabled, Disabled, or SecuredByPerimeter) governs whether the public endpoint is reachable at all. Disabled means only private endpoint traffic works. A scenario that asks "what is the minimum public network access configuration" is steering you to set PublicNetworkAccess = Disabled once private endpoints are in place, so that no traffic from the internet is possible even if the firewall rules are misconfigured.

Putting It Together: Decision Guide

• Need to allow one client IP on a single server? Server-level firewall rule.
• Need to allow one tenant access to only their database on a shared server? Database-level firewall rule (Azure SQL Database only).
• Need to restrict to a VNet but keep the public endpoint? Service endpoint.
• Need to block all public access and reach the server via private IP only? Private endpoint + PublicNetworkAccess = Disabled.
• Need a fully instance-scoped deployment with your own VNet and NSG control? SQL Managed Instance in a delegated subnet.

Common Exam Traps in Network Security

A handful of distractors recur in the network security objective:

• "Use the Allow Azure services toggle to restrict to your VNet." Wrong - the toggle opens the server to any Azure-internal service across all tenants. Use a service endpoint or private endpoint for VNet-scoped access.
• "Database-level firewall rules work on SQL Managed Instance." Wrong - they are Azure SQL Database only.
• "Service endpoints give the server a private IP." Wrong - they extend VNet identity to the public endpoint; only private endpoints provide a private IP.
• "You can enable TDE to secure network traffic." Wrong - TDE is data-at-rest only, never network encryption.
• "Tightening the SQL MI subnet NSG to deny all AzureCloud traffic is fine because the instance is self-contained." Wrong - the management ports must reach Azure's control plane or the instance goes unhealthy.

Recognizing these patterns speeds scenario triage. Network security for Azure SQL is layered: firewall first (allow-list), then service endpoints (VNet-scoped public), then private endpoints (private IP only), then managed instance (your VNet, your NSG). The correct answer is always the layer that matches the stated threat model - no more, no less.