Un détaillant exécute son application de commerce électronique sur des instances EC2 derrière un Application Load Balancer (ALB) avec un backend Amazon RDS. CloudFront est configuré avec l'ALB comme origine pour mettre en cache le contenu statique. Route 53 héberge le DNS public. Après une mise à jour de l'application, l'ALB renvoie parfois des erreurs HTTP 502 (Bad Gateway) en raison d'en-têtes HTTP mal formés renvoyés à l'ALB. Le rechargement immédiat de la page réussit généralement. Pendant que l'entreprise corrige la cause première, l'architecte de solutions doit afficher une page d'erreur personnalisée au lieu de la page par défaut de l'ALB avec un minimum de frais opérationnels. Quelle combinaison d'étapes permet d'y parvenir ? (Choisissez-en deux.)

Les erreurs 502 de l'ALB sont interceptées par CloudFront car l'ALB est son origine. CloudFront peut être configuré pour renvoyer des pages d'erreur personnalisées pour des codes d'état HTTP spécifiques. Pour héberger ces pages d'erreur, un compartiment Amazon S3 configuré pour l'hébergement de sites web statiques est une solution simple et rentable, car il ne nécessite pas de serveurs supplémentaires. Les autres options sont incorrectes car : Les alarmes CloudWatch avec des fonctions Lambda pour modifier les règles de transfert de l'ALB sont trop complexes et réactives. Elles n'empêchent pas l'ALB de renvoyer l'erreur 502 initiale. Les vérifications de l'état de Route 53 et les cibles de secours sont conçues pour la disponibilité DNS, pas pour la gestion des erreurs HTTP spécifiques renvoyées par l'ALB à CloudFront. La métrique Elb.InternalError n'est pas la plus pertinente pour les erreurs 502 dues à des en-têtes mal formés.