A lock-app subnet has a default system route to Internet, but the security engineer needs PaaS-bound traffic to take the firewall path instead. What routing behavior should they rely on?
Select an answer to reveal the explanation.
Short Explanation
Azure’s default “go Internet” path loses to your UDR. Plant 0.0.0.0/0—or a tighter prefix—and the more specific route wins the race to the firewall.
Full Explanation
User-defined routes override system routes for matching prefixes, which is why a UDR 0.0.0.0/0 or a more specific prefix can force PaaS-bound or Internet-bound traffic from a lock-app subnet through the firewall instead of the default system Internet route. More specific prefixes win over less specific ones when multiple routes match.
Claiming system Internet routes always beat any UDR regardless of prefix length fails by concept. Claiming Private Endpoints automatically rewrite UDRs so firewall inspection is never required oversimplifies private connectivity behavior. Claiming service endpoints disable all route tables until removed is false.
Exam caveat: always validate with Effective routes on the NIC after changing UDRs or enabling private connectivity features. Operational check: add the UDR that steers the intended prefixes to the firewall, check effective routes on a lock-app NIC, test the PaaS flow, and confirm it no longer uses the direct system Internet next hop. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.