Pular para o conteúdo principal

Laboratório Técnico: Link a private DNS zone to a VNet

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de plataforma criou uma zona DNS privada chamada database.internal e a vinculou a uma VNet chamada Hub-VNet. Máquinas virtuais nessa VNet conseguem resolver nomes dentro da zona sem problemas. Posteriormente, uma nova VNet chamada Spoke-VNet foi criada e as VMs nela não conseguem resolver os mesmos nomes.

Qual é a causa raiz do problema?

A) A zona DNS privada só permite uma única VNet vinculada por vez, e a Hub-VNet ocupa esse slot.

B) A Spoke-VNet não possui um link de resolução configurado para a zona database.internal.

C) O peering entre Hub-VNet e Spoke-VNet propaga automaticamente os links DNS, mas há um atraso de sincronização esperado.

D) É necessário duplicar os registros DNS na zona para que cada VNet tenha seu próprio conjunto de entradas.

Questão 2 — Cenário Técnico​

Um engenheiro precisa que VMs em uma VNet registrem seus nomes automaticamente na zona DNS privada corp.internal à medida que são provisionadas. Ele configura o link entre a zona e a VNet, mas os registros das VMs não aparecem na zona após o provisionamento.

Trecho da configuração do link via CLI:

az network private-dns link vnet create \
  --resource-group rg-networking \
  --zone-name corp.internal \
  --name link-corp \
  --virtual-network Hub-VNet \
  --registration-enabled false

Qual é o problema e como corrigi-lo?

A) O parâmetro --zone-name deveria incluir um ponto final (corp.internal.) para indicar zona raiz.

B) O parâmetro --registration-enabled está definido como false; deve ser alterado para true para habilitar o registro automático.

C) O link deve ser criado no portal do Azure, pois a CLI não suporta o parâmetro --registration-enabled.

D) A VNet precisa ter pelo menos uma sub-rede com delegação para Microsoft.Network/dnsResolvers antes de aceitar registro automático.

Questão 3 — Verdadeiro ou Falso​

Uma zona DNS privada pode estar vinculada a uma VNet com o registro automático habilitado e, ao mesmo tempo, essa mesma VNet pode ter o registro automático habilitado em uma segunda zona DNS privada diferente.

Verdadeiro ou Falso?

Questão 4 — Cenário Técnico​

Uma empresa mantém a seguinte arquitetura:

  • Zona DNS privada: api.internal
  • Links configurados: VNet-A (resolução apenas) e VNet-B (resolução apenas)
  • As VNets não possuem peering entre si

Uma VM na VNet-A cria uma entrada manualmente na zona via portal. Uma VM na VNet-B tenta resolver esse mesmo nome e obtém sucesso. Em seguida, a equipe remove o link da VNet-B e tenta novamente a resolução, mas dessa vez a consulta falha.

Qual comportamento está sendo demonstrado por essa sequência de eventos?

A) A remoção do link interrompe a resolução porque a VNet-B perde o acesso ao plano de dados da zona DNS privada.

B) A falha ocorre porque, sem o link, o Azure redireciona as consultas para o DNS público, onde api.internal não existe.

C) A remoção do link exclui automaticamente todos os registros da zona que foram criados enquanto o link estava ativo.

D) A resolução falha porque a VNet-B perde o peering implícito com a VNet-A que o link DNS privado criava.

Questão 5 — Múltipla Escolha​

Ao planejar vínculos entre zonas DNS privadas e VNets em uma topologia hub-and-spoke, qual afirmação descreve corretamente um limite operacional do serviço que impacta diretamente o design?

A) Uma única zona DNS privada pode ser vinculada a no máximo 10 VNets, independentemente de assinaturas ou regiões.

B) Uma VNet pode ser vinculada a múltiplas zonas DNS privadas, mas apenas uma delas pode ter o registro automático habilitado.

C) Links de resolução não são permitidos entre VNets em assinaturas diferentes dentro do mesmo tenant do Microsoft Entra ID.

D) O registro automático só funciona em VNets localizadas na mesma região que a zona DNS privada.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O acesso à resolução de uma zona DNS privada depende exclusivamente da existência de um link de resolução entre a zona e a VNet. O peering entre VNets não propaga nem herda vínculos de DNS privado: cada VNet deve ter seu próprio link configurado na zona. A alternativa A está errada porque o limite real é muito superior a uma única VNet. A alternativa C representa um equívoco comum, pois peering e links DNS são planos de controle independentes. A alternativa D é incorreta porque os registros DNS são compartilhados por todas as VNets vinculadas à zona.

Gabarito — Questão 2​

Resposta: B

O registro automático de VMs em uma zona DNS privada depende de o parâmetro --registration-enabled estar definido como true no link entre a VNet e a zona. Com o valor false, o link existe apenas para resolução, não para registro. As VMs são provisionadas normalmente, mas nenhum registro A é criado automaticamente. A alternativa A é incorreta pois a CLI aceita o nome sem ponto final. A alternativa C é falsa, o parâmetro é suportado na CLI. A alternativa D confunde o recurso de DNS Resolver privado, que é uma funcionalidade distinta e não um pré-requisito para registro automático.

Gabarito — Questão 3​

Resposta: Falso

Uma VNet pode ter o registro automático habilitado em apenas uma zona DNS privada por vez. Essa é uma limitação de design do serviço: permitir registro automático em múltiplas zonas simultâneas criaria conflitos de autoridade sobre qual zona recebe o registro canônico da VM. É perfeitamente válido vincular a mesma VNet a várias zonas para fins de resolução, mas o registro automático fica restrito a uma única zona por VNet.

Gabarito — Questão 4​

Resposta: A

O link entre uma VNet e uma zona DNS privada é o que garante acesso ao plano de dados de resolução da zona. Ao remover o link, a VNet-B perde a capacidade de enviar consultas DNS que o resolvedor do Azure encaminhará para aquela zona privada. A alternativa B está errada porque o Azure não redireciona automaticamente para DNS público ao remover um link: a consulta simplesmente não encontra resolução. A alternativa C está incorreta: remover o link não afeta os registros existentes na zona. A alternativa D confunde o comportamento do link DNS com conectividade de rede, que são planos completamente distintos.

Gabarito — Questão 5​

Resposta: B

O limite de uma única zona com registro automático por VNet é uma restrição real e influencia diretamente o design em topologias hub-and-spoke, especialmente quando há necessidade de registrar VMs em zonas diferentes conforme o ambiente ou função. A alternativa A está incorreta: o limite de vínculos por zona é muito maior que 10 e varia conforme a configuração. A alternativa C é falsa: links entre VNets de assinaturas diferentes dentro do mesmo tenant são suportados. A alternativa D é incorreta: a zona DNS privada é um recurso global e o registro automático não tem restrição de região entre a zona e a VNet vinculada.