The hub Azure Firewall must allow a spoke VM to login.microsoftonline.com over HTTPS, allow TCP 1433 to a known SQL IP, and publish an internal RDP host to one operator IP. How should those be mapped to firewall rule kinds?
Select an answer to reveal the explanation.
Short Explanation
FQDN HTTPS → application rule, known IP:port → network rule, publish an internal host → DNAT. Don’t pretend three NSG lines on the firewall subnet are the same toolbox.
Full Explanation
Azure Firewall rule kinds map cleanly to the hub scenarios for canal operations. Use an application rule for HTTPS to login.microsoftonline.com (FQDN-based), a network rule for TCP 1433 to a known SQL IP (5-tuple), and a DNAT rule to publish an internal RDP host to one operator IP. That mapping keeps identity egress, data-plane SQL, and controlled admin publish on the correct rule engines.
Using three NSG lines on the Azure Firewall subnet instead fails by concept: NSGs on the firewall subnet are not a substitute for Firewall application, network, and DNAT rule collections. Using only DNAT rules for the FQDN, the SQL IP, and the RDP publish fails by concept: DNAT publishes inbound mappings and cannot express FQDN application filtering or ordinary 5-tuple allow the same way. Using only application FQDN rules for TCP 1433 and for publishing RDP fails by concept: application rules are not the DNAT publish mechanism, and raw SQL IP 5-tuples belong in network rules.
Exam caveat: memorize application = FQDN/HTTP(S)-style, network = 5-tuple, DNAT = publish/map—mixed misuse is a common trap. Operational check: create the three rule types accordingly, from a spoke VM verify HTTPS to login.microsoftonline.com and TCP 1433 to the SQL IP, and confirm only the designated operator IP reaches the published RDP mapping.