A public botanical-garden site runs on an External App Service Environment. What inbound-security conclusion should the security engineer draw?
Select an answer to reveal the explanation.
Short Explanation
External ASE still wears a public VIP. Living in a VNet doesn’t mean “already isolated”—park NSG, Firewall, or WAF in front like any other public edge.
Full Explanation
An External App Service Environment still places a public inbound VIP on the botanical-garden site. VNet injection improves isolation options for management and backends, but it does not make External ASE automatically Internet-private. The security engineer should conclude that NSG, Azure Firewall, and/or WAF controls remain required at the public edge rather than treating the ASE SKU as automatic Internet isolation.
Assuming External ASE is automatically private because ASE always injects into a VNet fails by concept: that description matches Internal (ILB) ASE inbound behavior, not External. Relying only on Azure Bastion in front of External ASE for HTTP(S) visitor traffic fails by concept: Bastion is an administrative RDP/SSH path, not a public web reverse proxy or WAF edge. Disabling TLS on the ASE apps so WAF can inspect cleartext fails by concept: weakening transport security on a public garden site is not the approved WAF pattern and increases exposure.
Exam caveat: map External versus Internal ASE before choosing edge controls—External still needs public-inbound hardening. Operational check: inventory the External ASE public VIP, place WAF/Firewall/NSG controls appropriate to visitor HTTP(S), verify TLS remains enabled, and confirm Bastion is used only for admin access if required—not as the visitor path.