Un architetto di soluzioni ha implementato una web app accessibile da due Regioni AWS con un dominio personalizzato utilizzando il routing basato sulla latenza di Amazon Route 53. Per ogni Regione, l'architetto ha creato set di record pesati che puntano a una coppia di server web in diverse Zone di Disponibilità. Durante un test di disaster recovery, tutti i server web in una Regione sono stati arrestati, ma Route 53 non ha reindirizzato automaticamente il traffico all'altra Regione. Quale delle seguenti opzioni potrebbe spiegare questo comportamento? (Scegliere due.)

Il set di record alias di latenza per la Regione con i server arrestati deve avere l'opzione "Evaluate Target Health" abilitata. Senza questa opzione, Route 53 non valuta l'integrità dei record sottostanti e continuerà a inviare traffico a quella Regione anche se i server sono inattivi, impedendo il failover automatico. Inoltre, se i set di record pesati che puntano ai server web arrestati non hanno un controllo di integrità HTTP associato, Route 53 non rileverà che i server sono non disponibili. Anche se "Evaluate Target Health" fosse abilitato sul record alias, non ci sarebbero controlli di integrità da valutare per i record pesati, e il traffico non verrebbe reindirizzato. Le altre opzioni sono errate perché: Il peso maggiore non impedisce il failover se i controlli di integrità funzionano correttamente. Un server non integro nella Regione di fallback non impedirebbe il reindirizzamento dalla Regione fallita. I record di latenza e pesati possono essere combinati.