Laboratório Técnico: Configure networking settings for an App Service
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento precisa garantir que seu App Service consiga se comunicar com um banco de dados hospedado em uma Azure Virtual Network privada, sem expor esse banco à internet. O App Service está no plano Standard S2.
Qual funcionalidade deve ser habilitada no App Service para atender a esse requisito?
A) Private Endpoint no App Service, apontando para a subnet do banco de dados
B) VNet Integration, conectando o App Service à subnet onde o banco de dados reside
C) Service Endpoint na subnet do App Service, autorizado no firewall do banco de dados
D) Hybrid Connection, configurando um relay entre o App Service e a VNet privada
Questão 2 — Cenário Técnico
Um desenvolvedor relata que, após habilitar VNet Integration regional em seu App Service, as chamadas para recursos dentro da VNet integrada continuam falhando. Ao investigar, você identifica a seguinte configuração no App Service:
WEBSITE_VNET_ROUTE_ALL = 0
O banco de dados alvo está em 10.1.2.5, dentro de uma subnet da VNet integrada.
Qual é a causa mais provável da falha?
A) A VNet Integration regional não suporta comunicação com endereços RFC 1918 sem configuração adicional de DNS
B) A configuração WEBSITE_VNET_ROUTE_ALL = 0 impede que o tráfego destinado a endereços privados seja roteado pela VNet
C) O App Service precisa estar no plano Premium para acessar recursos em subnets que não sejam a própria subnet de integração
D) A subnet de integração não pode conter outros recursos além do App Service delegado a ela
Questão 3 — Múltipla Escolha
Você precisa bloquear o acesso ao seu App Service para que apenas requisições originadas de um endereço IP corporativo específico (203.0.113.45) sejam aceitas. Todas as demais devem ser rejeitadas com status 403.
Qual é a abordagem correta usando os recursos nativos do App Service?
A) Configurar uma regra de Access Restriction do tipo "Allow" para o IP 203.0.113.45 e, como a regra padrão nega todo o restante implicitamente, nenhuma outra ação é necessária
B) Configurar uma regra "Allow" para 203.0.113.45 e uma regra "Deny" explícita para 0.0.0.0/0 com prioridade menor
C) Associar um Network Security Group (NSG) à subnet do App Service e adicionar uma regra de entrada liberando apenas 203.0.113.45
D) Habilitar a VNet Integration e configurar o NSG da subnet integrada para bloquear todo o tráfego exceto o IP desejado
Questão 4 — Cenário Técnico
Uma empresa deseja que seu App Service seja acessível apenas por recursos internos da organização, sem qualquer exposição à internet pública. O endpoint do App Service deve ter um IP privado resolvível dentro da VNet.
O arquiteto propõe a seguinte solução:
- Criar um Private Endpoint para o App Service em uma subnet da VNet corporativa
- Criar uma Private DNS Zone
privatelink.azurewebsites.netvinculada à VNet - Habilitar a opção "Route All" na VNet Integration do App Service
Qual é o erro na proposta acima?
A) Private Endpoints em App Services não suportam zonas DNS privadas; é necessário usar entradas DNS manuais
B) A opção "Route All" na VNet Integration é irrelevante para o requisito de acesso privado de entrada; Private Endpoint e DNS privado já resolvem o cenário sem que VNet Integration seja necessária
C) A Private DNS Zone deve ser privatelink.azurewebsites.windows.net e não privatelink.azurewebsites.net
D) É necessário desabilitar o endpoint público do App Service explicitamente, pois Private Endpoint sozinho não impede acesso via internet
Questão 5 — Verdadeiro ou Falso
Afirmação: Ao configurar VNet Integration regional em um App Service, a subnet delegada a essa integração pode ser compartilhada com outros recursos Azure, como máquinas virtuais, desde que haja endereços IP disponíveis na subnet.
Verdadeiro ou Falso?
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A VNet Integration é a funcionalidade que permite ao App Service fazer chamadas de saída para recursos dentro de uma VNet privada. Ela conecta o App Service a uma subnet e roteia o tráfego de saída por essa rede, permitindo alcançar o banco de dados sem exposição à internet.
O principal equívoco dos distratores está em confundir direção do tráfego:
- Private Endpoint (A) serve para que outros recursos acessem o App Service de forma privada, ou seja, tráfego de entrada. Não resolve comunicação de saída do App Service para a VNet.
- Service Endpoint (C) restringe o acesso a serviços Azure gerenciados (como Azure SQL, Storage), mas não habilita o App Service a rotear tráfego por uma VNet privada.
- Hybrid Connections (D) é uma solução válida para cenários on-premises via Service Bus Relay, mas não é a abordagem nativa e adequada para comunicação com uma VNet Azure.
Gabarito — Questão 2
Resposta: B
Com WEBSITE_VNET_ROUTE_ALL = 0, apenas o tráfego destinado a endereços não roteáveis pela internet (como o espaço RFC 1918) não é obrigatoriamente forçado pela VNet. Na prática, com esse valor, o App Service roteia pela VNet somente rotas explicitamente definidas. Para endereços 10.x.x.x, o roteamento pode não ocorrer via VNet Integration sem que "Route All" esteja habilitado.
Definir WEBSITE_VNET_ROUTE_ALL = 1 (ou usar a configuração equivalente no portal) força todo o tráfego de saída pela VNet, incluindo o destinado a 10.1.2.5.
- O distrator A confunde o papel do DNS com o roteamento de rede; DNS privado é relevante para resolução de nomes, não para conectividade com IPs já conhecidos.
- O distrator C é impreciso: planos Standard suportam VNet Integration regional.
- O distrator D é parcialmente verdadeiro como boa prática de segurança, mas não é a causa da falha descrita.
Gabarito — Questão 3
Resposta: A
As Access Restrictions do App Service funcionam com uma regra padrão implícita de "Deny All" com a menor prioridade. Ao adicionar uma regra "Allow" para 203.0.113.45, todo o tráfego não contemplado por essa regra é automaticamente negado. Não é necessário criar uma regra "Deny" explícita para 0.0.0.0/0.
O distrator B descreve um comportamento correto em NSGs, mas não nas Access Restrictions do App Service, onde a lógica de "deny implícito" já existe nativamente.
Os distratores C e D representam um equívoco conceitual importante: App Services são serviços PaaS e não residem em subnets gerenciadas pelo usuário. NSGs não são aplicáveis diretamente ao tráfego de entrada do App Service da mesma forma que em VMs.
Gabarito — Questão 4
Resposta: B
O cenário descrito é de acesso privado de entrada ao App Service. Para isso, Private Endpoint expõe o App Service com um IP privado na VNet, e a Private DNS Zone garante a resolução correta do hostname para esse IP interno.
A VNet Integration é uma funcionalidade de saída (outbound), não de entrada. Incluí-la na proposta não é um erro que quebre a solução, mas representa um componente desnecessário e conceitualmente equivocado para o requisito apresentado, tornando a proposta incorreta como descrita.
- O distrator C está errado: o sufixo correto da zona privada para App Services é de fato
privatelink.azurewebsites.net. - O distrator D aponta uma preocupação legítima de segurança (desabilitar o endpoint público é recomendado), mas não representa um erro na proposta que torne a solução inoperante.
Gabarito — Questão 5
Resposta: Falso
A subnet usada para VNet Integration regional deve ser delegada exclusivamente ao serviço Microsoft.Web/serverFarms. Essa delegação impede que outros recursos, como máquinas virtuais ou outros serviços, sejam implantados ou conectados à mesma subnet.
Esse é um limite de plataforma, não apenas uma recomendação. Tentar associar outros recursos à subnet delegada resulta em erro. O único componente admitido na subnet de integração é a própria delegação do App Service Plan. Esse comportamento difere, por exemplo, de subnets usadas por Private Endpoints, que podem coexistir com outros recursos.