Laboratório Técnico: Configure service endpoints for Azure platform as a service (PaaS)
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento precisa garantir que uma Azure SQL Database seja acessível apenas a partir de uma sub-rede específica em uma Virtual Network, sem expor o serviço à internet pública. O administrador habilita um service endpoint para Microsoft.Sql na sub-rede.
Qual é o efeito imediato dessa configuração na perspectiva do tráfego de rede?
A) O tráfego entre a sub-rede e o Azure SQL Database passa a fluir por um endereço IP privado dentro da VNet, eliminando completamente qualquer rota pela internet.
B) O tráfego permanece na rede backbone da Microsoft, mas o endereço IP de origem visível para o Azure SQL Database ainda é o endereço público da sub-rede.
C) O tráfego passa a usar um endereço IP privado alocado dinamicamente dentro da sub-rede, substituindo o endereço público da VNet.
D) O service endpoint redireciona o tráfego via VPN Gateway, garantindo criptografia adicional entre a sub-rede e o serviço PaaS.
Questão 2 — Cenário Técnico
Um administrador configura um service endpoint para Microsoft.Storage em uma sub-rede chamada snet-app. Em seguida, acessa o Storage Account e adiciona a seguinte regra no firewall do recurso:
Virtual networks: snet-app (VNet: vnet-prod)
Firewall: Nenhum IP público adicionado
Default action: Deny
Após a configuração, uma aplicação hospedada em uma VM dentro de snet-app tenta acessar o Storage Account e recebe erro de conexão recusada.
Qual é a causa mais provável do problema?
A) O service endpoint para Microsoft.Storage não foi propagado ainda, pois o processo pode levar até 24 horas para ser efetivado.
B) A VM está usando um Network Security Group (NSG) que bloqueia o tráfego de saída na porta 443 para o prefixo de serviço Storage.
C) O service endpoint foi habilitado na sub-rede, mas o Storage Account ainda não tem a regra de rede configurada para permitir tráfego originado especificamente de snet-app.
D) O Storage Account com Default action: Deny requer obrigatoriamente um Private Endpoint e não é compatível com service endpoints.
Questão 3 — Verdadeiro ou Falso
Um service endpoint habilitado em uma sub-rede protege automaticamente o serviço PaaS associado, bloqueando todo o acesso externo à internet assim que é ativado, independentemente de qualquer configuração adicional no recurso de destino.
(Verdadeiro / Falso)
Questão 4 — Cenário Técnico
Uma organização utiliza a seguinte arquitetura:
VNet A (região East US)
snet-backend --> service endpoint: Microsoft.KeyVault
VNet B (região West US) [peering com VNet A]
snet-frontend
Uma aplicação hospedada em snet-frontend (VNet B) precisa acessar o Azure Key Vault configurado para aceitar conexões somente via service endpoint a partir de snet-backend.
O administrador afirma que, como há peering entre as VNets, o tráfego de snet-frontend será automaticamente encaminhado pelo service endpoint de snet-backend e o acesso ao Key Vault será permitido.
Qual é o erro nessa afirmação?
A) O peering entre VNets de regiões diferentes não é suportado pelo Azure, portanto a conectividade em si é inválida.
B) Service endpoints não são transitivos: o tráfego originado em snet-frontend não utiliza o endpoint configurado em snet-backend, e o Key Vault rejeitará a conexão.
C) O Azure Key Vault não suporta service endpoints, apenas Private Endpoints, tornando toda a configuração inválida.
D) O peering de VNets exige que o service endpoint seja habilitado na VNet inteira, não em sub-redes individuais, o que invalida a configuração atual.
Questão 5 — Múltipla Escolha
Um administrador precisa decidir entre usar um service endpoint ou um Private Endpoint para expor um Azure Storage Account exclusivamente a workloads internas. Considerando os critérios abaixo, qual cenário justifica tecnicamente a escolha do service endpoint em vez do Private Endpoint?
| Critério | Requisito do cenário |
|---|---|
| IP privado no namespace da VNet | Não obrigatório |
| Acesso de on-premises via VPN | Não necessário |
| Custo de solução | Minimizar |
| Escopo de acesso | Apenas uma sub-rede |
A) Quando o requisito é que o Storage Account tenha um endereço IP privado resolvível via DNS dentro da VNet.
B) Quando a solução deve suportar acesso ao Storage Account a partir de uma rede on-premises conectada via ExpressRoute.
C) Quando o objetivo é restringir o acesso ao Storage Account a uma sub-rede específica com o menor custo e sem necessidade de IP privado dedicado.
D) Quando a organização exige que o tráfego ao Storage Account nunca transite pelo backbone público da Microsoft, mesmo que de forma lógica.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Quando um service endpoint é habilitado, o tráfego entre a sub-rede e o serviço PaaS é roteado diretamente pelo backbone da Microsoft, sem passar pela internet pública. Entretanto, o endereço IP de origem que o serviço PaaS enxerga ainda é o endereço IP público da VNet, não um IP privado.
A alternativa A descreve o comportamento de um Private Endpoint, não de um service endpoint. Com Private Endpoint, o serviço recebe um IP privado dentro da VNet e o tráfego nunca usa endereço público. A alternativa C inventa um comportamento de alocação dinâmica de IP privado que não existe. A alternativa D confunde service endpoint com VPN Gateway, que são mecanismos completamente distintos.
Entender essa distinção é crítico para escolher corretamente entre service endpoint e Private Endpoint em cenários que exigem IP privado para resolução DNS ou acesso de on-premises.
Gabarito — Questão 2
Resposta: B
A configuração do service endpoint e a regra de firewall do Storage Account estão corretas. O ponto negligenciado é o NSG na sub-rede ou na NIC da VM. Por padrão, NSGs bloqueiam tráfego de saída que não esteja explicitamente permitido. Após habilitar um service endpoint, é necessário adicionar uma regra de saída no NSG que permita tráfego para a Service Tag correspondente (neste caso, Storage), caso a política de saída seja restritiva.
A alternativa A é falsa: service endpoints são efetivados em poucos minutos, não em 24 horas. A alternativa C descreve um erro de configuração real, mas o enunciado afirma explicitamente que a regra de rede foi adicionada corretamente. A alternativa D é incorreta porque service endpoints e Default action: Deny são plenamente compatíveis.
Gabarito — Questão 3
Resposta: Falso
Habilitar um service endpoint em uma sub-rede não restringe automaticamente o acesso ao serviço PaaS. O endpoint apenas altera o roteamento do tráfego e habilita a possibilidade de usar regras baseadas em VNet no recurso de destino. Para efetivamente bloquear acessos externos, é necessário configurar separadamente as regras de firewall ou de rede virtual no próprio recurso PaaS (como Storage Account, Key Vault ou SQL Database), definindo Default action: Deny e permitindo apenas as sub-redes desejadas.
Confundir a ativação do endpoint com a aplicação automática de restrição de acesso é um dos erros operacionais mais comuns nesse tema, e pode resultar em recursos PaaS expostos à internet mesmo após o endpoint ser habilitado.
Gabarito — Questão 4
Resposta: B
Service endpoints não são transitivos. Cada sub-rede que precisa de acesso a um serviço PaaS via endpoint deve ter o endpoint habilitado diretamente nela. O fato de VNet A e VNet B estarem em peering não faz com que o tráfego originado em snet-frontend seja tratado como se viesse de snet-backend.
Na prática, o Key Vault receberá a conexão com origem em snet-frontend, que não possui endpoint habilitado nem está listada nas regras de rede do Key Vault, resultando em rejeição. A alternativa A é falsa: o Global VNet Peering entre regiões diferentes é suportado. A alternativa C é falsa: o Key Vault suporta tanto service endpoints quanto Private Endpoints. A alternativa D descreve um comportamento que não existe no Azure; endpoints são configurados por sub-rede, e essa granularidade é válida e esperada.
Gabarito — Questão 5
Resposta: C
O service endpoint é a escolha tecnicamente adequada quando os requisitos são: restringir acesso a uma sub-rede específica, minimizar custos (service endpoints não têm custo adicional, ao contrário de Private Endpoints que cobram por hora e por dados processados) e não há necessidade de IP privado dedicado ou acesso de redes on-premises.
A alternativa A descreve exatamente o caso de uso de um Private Endpoint, que é o único que fornece um IP privado resolvível via DNS dentro da VNet. A alternativa B também exige Private Endpoint, pois service endpoints não são alcançáveis a partir de redes on-premises via VPN ou ExpressRoute. A alternativa D é um requisito que nem service endpoint nem Private Endpoint atendem da forma descrita: o tráfego sempre utiliza a infraestrutura da Microsoft, mas service endpoints ainda usam IPs públicos logicamente.