Una empresa está desplegando una aplicación web sin estado en instancias EC2 en subredes privadas detrás de un Application Load Balancer (ALB). Las instancias de la aplicación web se ejecutan en un grupo de Auto Scaling. Una aplicación de gestión con estado separada se ejecuta en EC2 en otro grupo de Auto Scaling. La empresa quiere usar la misma URL, nombre de host, puerto y protocolo para ambas aplicaciones, con la aplicación de gestión accesible bajo el prefijo de ruta /management. El acceso a la interfaz de gestión debe limitarse a los rangos de IP locales de la empresa. Un certificado SSL/TLS de ACM protegerá la aplicación web. ¿Qué dos acciones debe realizar un ingeniero de redes para satisfacer estos requisitos? (Elija dos).

La primera acción correcta es insertar una regla en el oyente HTTPS del ALB. Esta regla debe usar una condición de patrón de ruta (path-pattern) para /management y una condición de IP de origen (source-ip) para los rangos de IP locales de la empresa. Si ambas condiciones coinciden, las solicitudes se reenvían al grupo objetivo de la aplicación de gestión. Habilitar la persistencia (stickiness) en este grupo objetivo es crucial porque la aplicación de gestión es con estado. La segunda acción correcta es configurar la regla predeterminada del oyente HTTPS para reenviar todas las demás solicitudes (las que no coinciden con la regla de /management) al grupo objetivo de la aplicación web. Dado que la aplicación web es sin estado, la persistencia debe deshabilitarse en su grupo objetivo para permitir que el ALB distribuya las solicitudes de manera uniforme. La opción incorrecta que modifica la regla predeterminada para el prefijo /management es errónea porque la regla predeterminada se aplica si ninguna otra regla coincide, no para una condición específica. La opción que usa X-Forwarded-For es incorrecta porque la condición source-ip del ALB es la forma correcta de filtrar por IP de origen.