Uma empresa está implantando um aplicativo web sem estado em instâncias EC2 em sub-redes privadas atrás de um Application Load Balancer (ALB). As instâncias do aplicativo web são executadas em um grupo do Auto Scaling. Um aplicativo de gerenciamento com estado separado é executado em EC2 em outro grupo do Auto Scaling. A empresa deseja usar a mesma URL, nome de host, porta e protocolo para ambos os aplicativos, com o aplicativo de gerenciamento acessível sob o prefixo de caminho /management. O acesso à interface de gerenciamento deve ser limitado aos intervalos de IP locais da empresa. Um certificado ACM SSL/TLS protegerá o aplicativo web. Quais duas ações um engenheiro de rede deve realizar para satisfazer esses requisitos? (Escolha duas.)

A primeira ação correta é inserir uma nova regra no listener HTTPS do ALB. Esta regra deve usar a condição path-pattern para /management e a condição source-ip para os intervalos de IP locais da empresa. Se ambas as condições forem atendidas, as solicitações são encaminhadas para o grupo de destino do aplicativo de gerenciamento. A aderência (stickiness) deve ser habilitada para este grupo de destino, pois o aplicativo de gerenciamento é com estado. A segunda ação correta é garantir que a regra padrão do listener HTTPS encaminhe todas as outras solicitações (que não correspondem à regra de gerenciamento) para o grupo de destino do aplicativo web. Como o aplicativo web é sem estado, a aderência deve ser desabilitada para o grupo de destino do aplicativo web, ou deixada desabilitada por padrão. As opções incorretas falham porque: Modificar a regra padrão para encaminhar para o aplicativo de gerenciamento se não houver uma correspondência é o oposto do que é necessário. Usar X-Forwarded-For para restrição de IP não é a forma padrão e segura de filtrar por IP de origem no ALB; a condição source-ip é a correta. Habilitar aderência no grupo de destino do aplicativo web é incorreto, pois o aplicativo web é sem estado.