Una aplicación crítica se ejecuta en una única instancia EC2 y utiliza un clúster de nodo único de ElastiCache for Redis, además de una instancia de base de datos RDS for MariaDB. Todos los componentes deben estar en buen estado y activos para que la aplicación funcione. Debe rediseñar la infraestructura para que pueda recuperarse automáticamente de fallos con un tiempo de inactividad mínimo. ¿Qué combinación de cambios debería implementar? (Elija tres).

Para la instancia EC2, colocarla detrás de un Elastic Load Balancer y en un grupo de Auto Scaling con una capacidad mínima de dos instancias asegura alta disponibilidad y recuperación automática. Si una instancia falla, el ELB redirige el tráfico y Auto Scaling lanza una nueva. Para la base de datos RDS, una implementación Multi-AZ en dos zonas de disponibilidad proporciona conmutación por error automática a una réplica en espera en caso de fallo de la zona de disponibilidad o de la instancia principal, minimizando el tiempo de inactividad. Para ElastiCache for Redis, un grupo de replicación con Multi-AZ habilitado crea réplicas en diferentes zonas de disponibilidad, permitiendo la promoción automática de una réplica a principal si el nodo primario falla. Las opciones incorrectas son: Configurar Auto Scaling en modo ilimitado no es una práctica común ni segura; siempre se establecen límites. Una réplica de lectura de RDS en la misma AZ no ofrece protección contra fallos de AZ y requiere promoción manual, lo que aumenta el tiempo de inactividad. ElastiCache for Redis no se gestiona con Auto Scaling; se utilizan grupos de replicación para la alta disponibilidad.