Um site de notícias global usa o CloudFront com um domínio personalizado service.example.com e uma origem ALB em service-alb.example.com. As instâncias EC2 Windows de backend estão em um grupo do Auto Scaling atrás do ALB. A política de segurança exige criptografia em trânsito para todo o caminho, desde os usuários até o backend. Qual combinação de alterações é necessária para atender a essa política? (Escolha três.)

A primeira opção correta garante a criptografia entre o usuário e o CloudFront. Criar um certificado ACM para service.example.com e configurá-lo no CloudFront, juntamente com o redirecionamento HTTP para HTTPS, estabelece uma conexão segura na borda. A segunda opção correta aborda a criptografia entre o ALB e as instâncias EC2. Usar um certificado público de terceiros (ou ACM) para as instâncias EC2 e configurar um grupo de destino HTTPS garante que o tráfego do ALB para o backend seja criptografado. A terceira opção correta estabelece a criptografia entre o CloudFront e o ALB. Criar um certificado ACM para service-alb.example.com, configurar um listener HTTPS no ALB com este certificado e forçar o CloudFront a usar HTTPS para a origem garante que esta parte do caminho também seja criptografada. Excluir o listener HTTP no ALB remove qualquer caminho não criptografado. As opções incorretas falham em um ou mais requisitos: certificados autoassinados não são confiáveis publicamente e não atendem aos padrões de segurança; usar um certificado ACM com um nome de domínio genérico para instâncias EC2 não é a prática padrão para criptografia de ponta a ponta; e não configurar o CloudFront para usar HTTPS para a origem do ALB ou não remover o listener HTTP do ALB deixaria lacunas na criptografia.