Si implementa Azure Front Door (Standard/Premium) davanti a due carichi di lavoro web multi-regione: /api e /web. Requisiti: instradare /api/* a Origin Group A e /web/* a Origin Group B; ogni origine espone un endpoint di integrità a /healthz che restituisce HTTP 200; applicare una policy WAF con una regola personalizzata che blocca specifici user-agent solo per le richieste a /api. Quali due configurazioni si dovrebbero implementare? Scegliere due.

La prima opzione corretta è creare due route separate: una per /api/ che punta a Origin Group A e un'altra per /web/ che punta a Origin Group B. Questo soddisfa il requisito di instradamento basato sul percorso. Associare la policy WAF con la regola personalizzata alla route /api garantisce che la regola di blocco dello user-agent si applichi solo alle richieste API, come richiesto. La seconda opzione corretta è impostare il percorso della sonda di integrità su /healthz per ogni gruppo di origine e configurarla per richiedere una risposta HTTP 200. Questo garantisce che Azure Front Door monitori correttamente lo stato di salute degli endpoint specifici /healthz di ciascun servizio, come specificato nei requisiti. Le opzioni errate sono: Configurare un singolo gruppo di origine con bilanciamento del carico ponderato non soddisfa il requisito di instradamento basato sul percorso a gruppi di origine distinti. Utilizzare le impostazioni predefinite della sonda di integrità con il percorso “/” non rispetta il requisito di utilizzare il percorso specifico “/healthz”. Collegare la policy WAF all'endpoint di Front Door e fare affidamento sulle esclusioni globali per /web è meno efficiente e più complesso della semplice associazione della policy alla route specifica /api, e potrebbe portare a configurazioni WAF indesiderate per /web.