Firma wdraża bezstanową aplikację internetową na instancjach EC2 w prywatnych podsieciach za Application Load Balancer (ALB). Instancje aplikacji internetowej działają w grupie Auto Scaling. Oddzielna stanowa aplikacja do zarządzania działa na EC2 w innej grupie Auto Scaling. Firma chce używać tego samego adresu URL, nazwy hosta, portu i protokołu dla obu aplikacji, przy czym aplikacja do zarządzania ma być dostępna pod prefiksem ścieżki /management. Dostęp do interfejsu zarządzania musi być ograniczony do zakresów adresów IP firmy w siedzibie. Certyfikat ACM SSL/TLS będzie chronić aplikację internetową. Jakie dwie czynności powinien podjąć inżynier sieci, aby spełnić te wymagania? (Wybierz dwie.)

Pierwsza poprawna opcja tworzy nową regułę dla słuchacza HTTPS, która kieruje ruch z prefiksem ścieżki /management i pochodzący z firmowych adresów IP do grupy docelowej aplikacji zarządzającej. Włączenie stickiness dla tej grupy docelowej jest kluczowe, ponieważ aplikacja zarządzająca jest stanowa. Druga poprawna opcja opisuje domyślne zachowanie, gdy żadna inna reguła nie zostanie dopasowana: ruch jest kierowany do grupy docelowej aplikacji internetowej. Wyłączenie stickiness dla aplikacji internetowej jest właściwe, ponieważ jest ona bezstanowa. Pozostałe opcje są nieprawidłowe, ponieważ: Modyfikacja domyślnej reguły w celu kierowania ruchu /management jest błędna; domyślna reguła powinna obsługiwać ruch do aplikacji internetowej. Użycie nagłówka X-Forwarded-For zamiast source-ip do filtrowania dostępu jest mniej bezpieczne, ponieważ nagłówek ten może być sfałszowany. Kierowanie ruchu do aplikacji internetowej, gdy warunki dla /management nie zostaną spełnione w domyślnej regule, jest sprzeczne z logiką działania reguł ALB.