A lock-status App Service must call a VM and a Private Endpoint SQL NIC inside the VNet, while inbound Internet to the app must stay closed. How should networking be split?
Select an answer to reveal the explanation.
Short Explanation
VNet integration is the app’s outbound tunnel into the VNet; Private Endpoint (or access restrictions) covers inbound. Don’t pretend integration locks the front door.
Full Explanation
App Service regional VNet integration sends outbound calls from the app into a VNet (to reach a VM or Private Endpoint SQL NIC), while a Private Endpoint on the app (plus access restrictions) addresses private inbound. Do not treat VNet integration as inbound isolation. For a lock-status App Service that must call private resources while inbound Internet stays closed, split networking that way.
Using regional VNet integration for both inbound isolation and outbound VNet access so app Private Endpoints are unnecessary fails—integration is outbound-oriented. Using Hybrid Connections as the primary AZ-500 control for private inbound to App Service misses the Private Endpoint inbound pattern. Enabling only inbound access restrictions and skipping VNet integration fails outbound to private SQL.
Exam caveat: inbound private vs outbound VNet integration are different knobs—AZ-500 loves this distinction. Operational check: enable VNet integration for outbound, add Private Endpoint/access restrictions for inbound, test SQL/VM calls, and confirm public inbound is blocked. 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.