Laboratório Técnico: Design private DNS zones
Questões
Questão 1 — Múltipla Escolha
Uma equipe de arquitetura precisa garantir que máquinas virtuais em duas redes virtuais distintas, localizadas em regiões diferentes, consigam resolver nomes de uma mesma zona DNS privada sem depender de servidores DNS customizados.
Qual é o requisito mínimo para que a resolução de nomes funcione corretamente nas duas redes?
A) As duas redes virtuais devem estar conectadas via VNet Peering antes de serem vinculadas à zona DNS privada.
B) Cada rede virtual deve ser adicionada como um virtual network link na zona DNS privada, com registro automático habilitado em ambas.
C) Cada rede virtual deve ser adicionada como um virtual network link na zona DNS privada; o registro automático é opcional e independente da resolução.
D) A zona DNS privada deve ser implantada na mesma região das redes virtuais para que os links funcionem.
Questão 2 — Cenário Técnico
Um engenheiro configura uma zona DNS privada chamada internal.contoso.com e vincula a rede virtual vnet-prod com registro automático habilitado. Após a implantação de 120 máquinas virtuais nessa rede, o engenheiro percebe que os registros de algumas VMs não aparecem na zona.
Qual é a causa mais provável desse comportamento?
A) O registro automático só funciona para VMs criadas antes da criação do virtual network link.
B) O limite de registros gerados por registro automático em uma única zona DNS privada foi atingido.
C) VMs com mais de uma NIC não geram registros automáticos em zonas DNS privadas.
D) O registro automático requer que a VM esteja em execução no momento em que o link é criado.
Questão 3 — Verdadeiro ou Falso
Uma zona DNS privada pode ser vinculada a uma rede virtual que já possui um servidor DNS customizado configurado nas definições da VNet, e ambos coexistirão sem conflito: a zona privada resolverá os nomes para os quais possui registros, enquanto o servidor customizado tratará os demais.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa utiliza a seguinte arquitetura:
vnet-hub (10.0.0.0/16)
└── zona DNS privada: services.internal
└── virtual network link: vnet-hub (autoregistro: desabilitado)
vnet-spoke (10.1.0.0/16)
└── sem link com a zona services.internal
└── peering com vnet-hub configurado
Uma VM em vnet-spoke tenta resolver api.services.internal e falha. O engenheiro argumenta que o peering já deveria propagar a resolução DNS automaticamente.
Qual é o erro na abordagem do engenheiro?
A) O peering de VNet propaga rotas, mas não estende a resolução de zonas DNS privadas; vnet-spoke precisa de seu próprio virtual network link para a zona.
B) O peering só propaga resolução DNS quando o registro automático está habilitado no link da rede de origem.
C) A zona services.internal usa um sufixo inválido; zonas privadas exigem pelo menos dois rótulos antes do TLD.
D) VMs em redes spoke nunca conseguem resolver zonas DNS privadas vinculadas a redes hub, independentemente da configuração.
Questão 5 — Múltipla Escolha
Ao projetar zonas DNS privadas para endpoints privados de serviços PaaS do Azure, qual é a principal razão para usar os nomes de zona recomendados pela Microsoft (por exemplo, privatelink.blob.core.windows.net) em vez de zonas com nomes arbitrários?
A) Zonas com nomes arbitrários são bloqueadas pelo Azure Policy por padrão em ambientes de produção.
B) O nome da zona determina qual registro CNAME interno o serviço PaaS usa para redirecionar a resolução ao endpoint privado; um nome incorreto quebra essa cadeia de resolução.
C) Somente zonas com o prefixo privatelink são aceitas como virtual network links pelo Azure DNS.
D) O uso de nomes arbitrários impede a criação de registros do tipo A na zona, limitando a funcionalidade a registros CNAME.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: C
O mecanismo de resolução de nomes em zonas DNS privadas depende exclusivamente dos virtual network links. Cada rede virtual que precisa resolver nomes da zona deve estar vinculada a ela, independentemente de região ou topologia de rede. O peering entre VNets não é exigido nem suficiente para isso.
O registro automático é uma funcionalidade separada: quando habilitado, a zona passa a criar e remover registros A automaticamente para VMs da rede vinculada. Ele não é condição para que a rede use a zona como resolvedor.
A alternativa B é o distrator mais perigoso: confunde o conceito de registro automático com o de resolução, induzindo o candidato a achar que ambos os recursos devem estar sempre ativos juntos. A alternativa D é falsa; zonas DNS privadas são recursos globais e não têm dependência de região.
Gabarito — Questão 2
Resposta: B
Zonas DNS privadas do Azure impõem um limite de 10.000 registros gerados por registro automático por zona. Com 120 VMs, cada uma podendo gerar múltiplos registros (um por NIC), é plausível que esse limite seja atingido, especialmente em ambientes com NICs múltiplas ou registros acumulados de VMs anteriores já deletadas mas cujos registros ainda existem.
As demais alternativas descrevem comportamentos que não existem: o registro automático funciona independentemente da ordem de criação de VMs e links (A é falsa), VMs com múltiplas NICs geram registros para cada NIC (C é falsa), e o estado de execução da VM no momento do link não é um critério (D é falsa).
A consequência prática de não identificar esse limite é assumir que a zona está com defeito quando, na verdade, o teto de capacidade foi atingido e novos registros são silenciosamente descartados.
Gabarito — Questão 3
Resposta: Falso
A afirmação descreve uma coexistência harmoniosa que não ocorre automaticamente. Quando uma VNet tem um servidor DNS customizado configurado, as consultas DNS das VMs são direcionadas a esse servidor, e não ao resolvedor recursivo do Azure (168.63.129.16). Como a resolução de zonas DNS privadas passa obrigatoriamente pelo resolvedor do Azure, um servidor customizado que não encaminhe as consultas corretas para 168.63.129.16 simplesmente não conseguirá resolver os nomes da zona privada.
Para que os dois coexistam de forma funcional, o servidor DNS customizado deve ser configurado como forwarder condicional para os sufixos da zona privada, apontando para 168.63.129.16. Sem esse encaminhamento explícito, o virtual network link existe, mas a resolução falha na prática.
Gabarito — Questão 4
Resposta: A
O VNet Peering estabelece conectividade de camada 3 entre redes, permitindo que o tráfego flua entre elas. Ele não estende nem compartilha a resolução de zonas DNS privadas. Cada rede virtual que precisa resolver nomes de uma zona privada deve ter seu próprio virtual network link registrado nessa zona.
A arquitetura correta exige a criação de um link entre vnet-spoke e a zona services.internal. Sem isso, as VMs em vnet-spoke usarão o DNS padrão do Azure, que desconhece a zona privada.
A alternativa B é falsa: o registro automático não tem relação com a propagação de resolução entre redes. A alternativa C é falsa: services.internal é um nome válido para zona privada (dois rótulos). A alternativa D é falsa e representa um equívoco absoluto; a topologia hub-spoke com múltiplos links é um padrão documentado e suportado.
Gabarito — Questão 5
Resposta: B
Quando um endpoint privado é criado para um serviço PaaS, o Azure configura um registro CNAME no DNS público que redireciona o nome original do serviço (ex: contoso.blob.core.windows.net) para um nome no subdomínio privatelink (ex: contoso.privatelink.blob.core.windows.net). A zona DNS privada com o nome exato privatelink.blob.core.windows.net é que deve conter o registro A apontando para o IP privado do endpoint.
Se a zona tiver um nome diferente, a cadeia de resolução quebra: o CNAME público aponta para privatelink.blob.core.windows.net, mas não existe zona privada com esse nome para resolver a etapa final.
As alternativas A, C e D descrevem restrições que não existem no Azure DNS. Não há bloqueio por Policy padrão, não há exigência de prefixo privatelink para links, e registros do tipo A funcionam normalmente em zonas com qualquer nome válido.