AZ-500 Secure networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Configure IP restrictions on the App Service to allow only the Azure Front Door service tag AzureFrontDoor.Backend.

  Why this is correct

  The AzureFrontDoor.Backend service tag covers the IP ranges that Azure Front Door's origin-facing servers use when they forward requests to your App Service. By adding an access restriction that allows only this service tag, any request that does not originate from those backend IPs—including direct traffic to the App Service's public URL—is rejected. This is the standard, low-overhead method for locking down an App Service origin to only receive traffic from Front Door.

• ✗

  Configure the App Service to require client certificates and configure Azure Front Door to present a certificate.

  Why it's wrong here

  Requiring client certificates makes the App Service demand a valid certificate from every connecting client, but it does not verify that the certificate belongs specifically to Azure Front Door; any client that possesses a valid certificate, including an attacker who has obtained a client cert, can still connect directly to the App Service. Additionally, you would need to implement custom certificate validation logic in your application code to confirm the presented certificate's issuer or subject matches Front Door's expected values, increasing complexity. Even if configured, Front Door's automatic certificate presentation does not prevent direct access that supplies its own certificate, so this approach fails to guarantee exclusive access through Front Door.

• ✗

  Set the App Service access restrictions to deny all and then add a rule to allow the Azure Front Door service tag AzureFrontDoor.Frontend.

  Why it's wrong here

  Access restrictions on an App Service evaluate the source IP address of the inbound request. When Azure Front Door forwards a request to the origin, the source IP comes from the AzureFrontDoor.Backend range, not the AzureFrontDoor.Frontend range, which is used by clients connecting to Front Door's edge endpoints. Denying all and allowing only the Frontend service tag will therefore block legitimate Front Door traffic, because the backend range is not included in that tag, and will also block direct traffic, so the app becomes unreachable rather than being protected.

• ✗

  Configure a WAF policy to block all requests that do not contain the X-Azure-FDID header.

  Why it's wrong here

  The X-Azure-FDID header is injected by Front Door and can be used to validate that a request came through a specific Front Door instance, but a WAF policy on Front Door only evaluates requests that actually traverse Front Door. Direct requests to the App Service's public endpoint never pass through that WAF policy, so the header check is never applied to them. Even if the WAF policy were somehow applied at the origin, attackers can spoof the X-Azure-FDID header in their direct requests, since it is not a cryptographically signed header. Therefore, this control does not prevent bypassing Front Door and may also block legitimate requests if Front Door's header format changes or is missing.

Go deeper

Related to this question