Uma empresa usa uma conta AWS compartilhada para conectividade com data centers on-premises. Serviços web internos privados são executados em várias contas AWS e são acessados por funcionários do escritório usando nomes DNS em uma zona on-premises chamada example.internal. O registro de um novo serviço hospedado na AWS atualmente exige uma alteração manual de várias equipes no DNS interno. A empresa deseja que os proprietários dos serviços possam registrar seus registros DNS diretamente, com o mínimo de alterações de configuração e baixo custo. Qual combinação de etapas o engenheiro de rede deve implementar? (Escolha três.)

A criação de um endpoint inbound do Route 53 Resolver na VPC da conta compartilhada permite que os servidores DNS on-premises encaminhem consultas para domínios AWS. A configuração de encaminhadores condicionais nos servidores DNS on-premises direciona o tráfego para esse endpoint. A criação de uma zona hospedada privada aws.example.internal na conta compartilhada estabelece um domínio raiz para os serviços AWS. Por fim, a criação de zonas hospedadas privadas para cada conta (ex: account1.aws.example.internal) e a associação delas às VPCs relevantes e à VPC compartilhada permite que os proprietários dos serviços gerenciem seus próprios registros DNS, atendendo aos requisitos de baixo custo e mínimo de alterações manuais. As opções incorretas são: Criar um registro DNS para cada serviço em sua zona hospedada privada local não atende ao requisito de permitir que os proprietários dos serviços gerenciem seus próprios registros DNS, pois ainda exigiria intervenção manual. Criar uma regra do Amazon Route 53 Resolver para encaminhar consultas para onprem.example.internal para os servidores DNS on-premises é uma configuração para resolver nomes on-premises a partir da AWS, o oposto do que é necessário. Iniciar instâncias EC2 com BIND é uma solução mais complexa e cara do que o Route 53 Resolver, que é um serviço gerenciado.