Um site executa uma camada web (grupo do Auto Scaling do EC2 em duas AZs) e uma camada de banco de dados (RDS para MySQL Multi-AZ). As ACLs de rede da sub-rede do banco de dados são restritas apenas às sub-redes web que precisam de acesso ao banco de dados; as sub-redes web usam regras NACL padrão. Uma terceira sub-rede foi adicionada recentemente ao grupo do Auto Scaling. Após o escalonamento, alguns usuários veem intermitentemente erros de que o servidor web não consegue se conectar ao banco de dados. As tabelas de rotas e os grupos de segurança foram verificados. Que alterações um administrador SysOps deve fazer para que os servidores web na nova sub-rede possam alcançar a instância do banco de dados? (Escolha duas.)

As ACLs de rede (NACLs) são sem estado, o que significa que tanto o tráfego de entrada quanto o de saída devem ser explicitamente permitidos. Quando um novo servidor web é adicionado em uma nova sub-rede, ele precisa de permissão para iniciar uma conexão com o banco de dados e para receber a resposta. A primeira ação correta é adicionar uma regra de permissão de entrada para MySQL/Aurora (porta 3306) nas NACLs da sub-rede do banco de dados, com a origem definida para a nova sub-rede web. Isso permite que os servidores web na nova sub-rede iniciem a conexão com o banco de dados. A segunda ação correta é adicionar uma regra de permissão de saída para o intervalo de portas TCP efêmeras (1024-65535) nas NACLs da sub-rede do banco de dados, com o destino definido para a nova sub-rede web. Isso permite que o banco de dados envie a resposta de volta para os servidores web. As opções incorretas se concentram em alterar as NACLs padrão da sub-rede web, o que não é necessário, ou em regras de saída incorretas para a sub-rede do banco de dados. As NACLs da sub-rede web já são padrão, o que geralmente significa que permitem todo o tráfego de saída, e o problema está na comunicação com o banco de dados, que tem NACLs restritivas.