Un minorista ejecuta su aplicación de e-commerce en instancias EC2 detrás de un Application Load Balancer (ALB) con un backend de Amazon RDS. CloudFront está configurado con el ALB como origen para almacenar en caché contenido estático. Route 53 aloja el DNS público. Después de una actualización de la aplicación, el ALB a veces devuelve HTTP 502 (Bad Gateway) debido a encabezados HTTP mal formados devueltos al ALB. Recargar la página inmediatamente suele tener éxito. Mientras la empresa soluciona la causa raíz, el arquitecto de soluciones necesita mostrar una página de error personalizada en lugar de la predeterminada del ALB con una sobrecarga operativa mínima. ¿Qué combinación de pasos logra esto? (Elija dos.)

La opción correcta es crear un bucket de S3 para alojamiento de sitios web estáticos y subir las páginas de error personalizadas. Luego, configurar las respuestas de error personalizadas de CloudFront para que, cuando el ALB devuelva un error 502, CloudFront sirva la página de error desde S3. Esto es de baja sobrecarga operativa porque S3 y CloudFront manejan la escalabilidad automáticamente, y CloudFront ya está en el flujo de tráfico. Las opciones incorrectas son: Usar una alarma de CloudWatch con una función Lambda para modificar las reglas del ALB es demasiado complejo y reactivo para una solución temporal de baja sobrecarga. Las verificaciones de estado de Route 53 y un destino de respaldo son para fallas completas del origen, no para errores específicos de la aplicación que ya están siendo manejados por CloudFront. Una alarma de CloudWatch para Elb.InternalError no es el error correcto (es 502 Bad Gateway), y la solución propuesta es de alta sobrecarga.