Canal-operations web apps must not receive a public inbound VIP. Which App Service Environment design meets that inbound-isolation requirement?
Select an answer to reveal the explanation.
Short Explanation
Need the site off the public Internet? Pick Internal (ILB) ASE v3—the inbound address lives as a private IP in your VNet. External ASE still hangs a public VIP on the door.
Full Explanation
Canal-operations web apps that must not receive a public inbound VIP need an Internal (ILB) App Service Environment v3. In that design the inbound address is a private IP inside the customer VNet, so browsers and partners reach the sites only through private connectivity such as VPN, ExpressRoute, or peered networks—not through a public front-end VIP.
Deploying an External ASE v3 and relying on the ASE name alone fails by concept: External ASE still presents a public inbound VIP; naming is not isolation. Using only multi-tenant App Service with a public IP and blocking browsers with Azure DDoS Protection Standard fails by concept: DDoS Protection mitigates volumetric attacks but does not privatize the inbound address. Placing apps on Azure Container Apps and disabling Microsoft Defender for Cloud fails by concept: Container Apps is a different platform, and Defender posture settings are Domain 4 controls that do not create ILB ASE inbound isolation.
Exam caveat: distinguish Internal (ILB) ASE from External ASE—VNet injection alone does not mean “no public VIP.” Operational check: deploy ASE v3 as Internal/ILB in the designated subnet, verify the inbound address is a private IP, confirm no public VIP is assigned to the ASE front end, and test that canal operators reach apps only over private paths.