Een solutions architect heeft een webapp geïmplementeerd die toegankelijk is vanuit twee AWS-regio's onder een aangepast domein met behulp van Amazon Route 53 latency-based routing. Voor elke regio heeft de architect gewogen recordsets gemaakt die verwijzen naar een paar webservers in verschillende Availability Zones. Tijdens een disaster-recoverytest werden alle webservers in één regio gestopt, maar Route 53 leidde het verkeer niet automatisch om naar de andere regio. Welke van de volgende opties kan dit gedrag verklaren? (Kies twee.)

De optie "Evaluate Target Health" op een alias recordset zorgt ervoor dat Route 53 de gezondheid van de onderliggende resources controleert. Als deze optie niet is ingeschakeld, zal Route 53 verkeer blijven sturen naar de regio, zelfs als de webservers niet beschikbaar zijn. Daarnaast, als de gewogen recordsets voor de individuele webservers geen geassocieerde HTTP health checks hebben, kan Route 53 de onbeschikbaarheid van die specifieke servers niet detecteren. Zonder health checks blijft Route 53 verkeer naar die servers sturen, wat resulteert in mislukte verbindingen in plaats van een failover naar de andere regio. De andere opties zijn onjuist: Het gewicht bepaalt de verdeling binnen een regio, niet de failover tussen regio's bij een storing. Een falende health check in de fallback-regio zou de failover bemoeilijken, niet verklaren waarom de failover niet plaatsvond. Latency-based en weighted resource record sets kunnen wel gecombineerd worden.