An ASE v3 deployment fails management connectivity after an engineer strips the ASE subnet NSG and points 0.0.0.0/0 at an NVA without the documented ASE exceptions. What should the security engineer restore?
Select an answer to reveal the explanation.
Short Explanation
ASE isn’t a free-for-all subnet. Leave the required NSG rules and UDR exceptions in place so Azure can still manage the environment—then inspect tenant traffic without cutting the platform’s lifeline.
Full Explanation
ASE v3 is VNet-injected and depends on documented subnet NSG rules and UDR patterns so Azure can manage the environment and so outbound platform dependencies succeed. After an engineer strips the ASE subnet NSG and points 0.0.0.0/0 at an NVA without the documented ASE exceptions, management connectivity fails. The security engineer must restore the required NSG rules and UDR patterns so platform management and outbound dependencies work while tenant traffic can still be inspected where the docs allow.
Deleting all NSGs on the ASE subnet permanently fails by concept: ASE expects specific platform allowances, not an empty security group. Forcing every ASE management packet through Azure Firewall Premium IDPS with no documented exceptions fails by concept: unsupported forced tunneling or missing exceptions breaks platform control planes even when IDPS is desirable for tenant flows. Moving the ASE to a multi-tenant App Service stamp and relying on Service Endpoints fails by concept: that abandons ASE rather than repairing ASE subnet hardening.
Exam caveat: AZ-500 treats “required ASE NSG/UDR exceptions” as non-negotiable—inspection goals never justify undocumented blackholing of platform traffic. Operational check: reapply the documented ASE subnet NSG rules, restore permitted UDR next hops/exceptions, confirm ASE management health returns, and only then route inspectable tenant egress through the NVA or firewall.