Laboratório de Troubleshooting: Create service endpoints
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma aplicação hospedada em uma VM na subnet-api parou de conseguir gravar dados em uma conta de armazenamento chamada stgprodeastus. O ambiente foi modificado ontem durante uma janela de manutenção que envolveu ajustes de NSG e uma atualização de política de rede corporativa.
O administrador coleta as seguintes informações:
# Verificação do Service Endpoint na subnet-api
az network vnet subnet show \
--vnet-name vnet-prod \
--name subnet-api \
--resource-group rg-network \
--query "serviceEndpoints"
# Saída:
[
{
"locations": ["eastus"],
"provisioningState": "Succeeded",
"service": "Microsoft.Storage"
}
]
# Verificação das regras de rede da conta de armazenamento
az storage account network-rule list \
--account-name stgprodeastus \
--resource-group rg-app \
--query "virtualNetworkRules"
# Saída:
[
{
"action": "Allow",
"state": "networkSourceDeleted",
"virtualNetworkResourceId": "/subscriptions/.../vnet-prod/subnets/subnet-api"
}
]
A NSG associada à subnet-api foi revisada e não possui regras de bloqueio de saída para o storage. O administrador de rede confirma que nenhuma alteração foi feita no Service Endpoint durante a manutenção.
Qual é a causa raiz da falha de acesso?
A. O Service Endpoint foi desabilitado da sub-rede durante a manutenção e a saída do comando está em cache.
B. A regra de rede virtual na conta de armazenamento está com o estado networkSourceDeleted, indicando que a sub-rede ou VNet referenciada foi excluída ou recriada, tornando a regra inválida.
C. A NSG está bloqueando o tráfego de saída para o storage apesar da revisão, pois regras implícitas de menor prioridade podem estar ativas.
D. O Service Endpoint está provisionado apenas para a região eastus, mas a conta de armazenamento utiliza replicação geo-redundante que roteia o tráfego para outra região.
Cenário 2 — Causa Raiz
Uma VM em subnet-data acessa normalmente um Azure Key Vault protegido por firewall de rede. Um engenheiro adiciona uma segunda sub-rede, subnet-mgmt, à mesma VNet e habilita o Service Endpoint para Microsoft.KeyVault nessa nova sub-rede. Minutos depois, a VM original em subnet-data começa a relatar falhas intermitentes ao tentar recuperar segredos do Key Vault.
O engenheiro verifica o seguinte:
# Estado dos Service Endpoints em subnet-data
az network vnet subnet show \
--vnet-name vnet-corp \
--name subnet-data \
--resource-group rg-net \
--query "serviceEndpoints"
# Saída:
[
{
"locations": ["brazilsouth"],
"provisioningState": "Succeeded",
"service": "Microsoft.KeyVault"
}
]
# Regras de rede no Key Vault
Virtual networks permitidas:
- vnet-corp / subnet-data -> state: Succeeded
- vnet-corp / subnet-mgmt -> state: Succeeded
O Key Vault possui acesso público habilitado com a configuração "Selected networks". Não houve alteração nas regras de rede do Key Vault. O time de segurança informa que não houve mudanças em políticas de acesso ou RBAC do Key Vault nesse período.
Qual é a causa raiz das falhas intermitentes em subnet-data?
A. A adição de subnet-mgmt nas regras do Key Vault gerou um conflito de roteamento entre as duas sub-redes, causando pacotes duplicados.
B. A habilitação do Service Endpoint em subnet-mgmt provocou uma breve reconfiguração de rede no host, que afetou momentaneamente a programação de rede das sub-redes vizinhas na mesma VNet, causando interrupção temporária nas conexões TCP ativas de subnet-data.
C. O Key Vault atingiu o limite de regras de rede virtual simultâneas, rejeitando conexões da sub-rede mais antiga como forma de balanceamento.
D. A informação do time de segurança está incompleta; a causa real é uma alteração silenciosa em uma política de acesso do Key Vault disparada automaticamente pela adição de uma nova sub-rede.
Cenário 3 — Decisão de Ação
A causa foi identificada: a regra de rede virtual de uma conta de armazenamento crítica (stg-finance) referencia uma sub-rede que foi excluída e recriada durante uma migração de infraestrutura realizada há duas semanas. O estado da regra está como networkSourceDeleted. Nenhuma aplicação consegue gravar na conta de armazenamento desde então.
O ambiente possui as seguintes restrições:
- A conta de armazenamento está em uso ativo por um pipeline de processamento financeiro que roda a cada 15 minutos
- O pipeline possui lógica de retry e tolera falhas de até 5 minutos sem impacto nos dados
- A sub-rede recriada já possui o Service Endpoint para
Microsoft.Storagehabilitado e provisionado com sucesso - O administrador possui permissão de
Contributorno resource group da conta de armazenamento - Uma segunda conta de armazenamento de contingência (
stg-finance-bkp) está disponível mas nunca foi testada em produção
Qual é a ação correta a tomar neste momento?
A. Remover a regra inválida com estado networkSourceDeleted e adicionar imediatamente uma nova regra de rede virtual apontando para a sub-rede recriada, aproveitando a janela de retry do pipeline.
B. Redirecionar o pipeline para a conta de armazenamento de contingência stg-finance-bkp antes de qualquer alteração na conta principal, pois qualquer modificação de regra de rede pode causar indisponibilidade adicional.
C. Abrir um ticket de suporte para que a Microsoft restaure o estado da regra para Succeeded, pois alterações em regras de rede de contas de armazenamento ativas requerem aprovação de suporte em ambientes de produção.
D. Aguardar a próxima janela de manutenção programada para remover a regra inválida e adicionar a nova, pois modificações em regras de rede de contas de armazenamento sempre causam indisponibilidade prolongada.
Cenário 4 — Sequência de Diagnóstico
Uma aplicação em produção relata erro 403 This request is not authorized to perform this operation ao tentar acessar um Azure Blob Storage. O administrador sabe que o ambiente usa Service Endpoints e que o firewall da conta de armazenamento está configurado para "Selected networks".
Os seguintes passos de investigação estão disponíveis, fora de ordem:
[P] Verificar se o Service Endpoint para Microsoft.Storage esta habilitado
na sub-rede de origem da VM
[Q] Verificar se a sub-rede de origem esta listada nas regras de rede
virtual da conta de armazenamento e se o estado e "Succeeded"
[R] Verificar se as credenciais ou a Managed Identity da aplicacao
possuem a role correta (ex: Storage Blob Data Contributor) na conta
[S] Verificar se o IP publico da VM ou do NAT Gateway esta na lista de
IPs permitidos do firewall da conta de armazenamento
[T] Confirmar se a conta de armazenamento esta configurada como
"Selected networks" ou "Enabled from all networks"
Qual é a sequência correta de investigação?
A. T -> P -> Q -> R -> S
B. P -> T -> S -> Q -> R
C. R -> T -> P -> Q -> S
D. S -> P -> T -> Q -> R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando que lista as regras de rede virtual da conta de armazenamento: o campo state apresenta o valor networkSourceDeleted. Esse estado indica que o recurso referenciado pela regra, neste caso a combinação de VNet e sub-rede, foi excluído ou recriado após a regra ter sido criada. Quando uma sub-rede é recriada (mesmo com o mesmo nome e CIDR), ela recebe um novo Resource ID, tornando a regra anterior inválida. O Service Endpoint pode estar corretamente provisionado na sub-rede nova, mas a regra no firewall da conta de armazenamento ainda aponta para o ID do recurso antigo.
A informação sobre a manutenção envolvendo NSG é irrelevante e foi incluída deliberadamente para desviar o diagnóstico para a alternativa C. NSG sem regras de bloqueio não explica o erro, e a saída do comando de regras de rede já aponta diretamente para a causa.
O distrator mais perigoso é a alternativa C. Focar na NSG é o erro de diagnóstico mais comum quando há uma mudança de infraestrutura recente, mas o estado networkSourceDeleted é uma evidência objetiva que supera qualquer suspeita sobre NSG. Agir sobre a NSG sem corrigir a regra inválida não restauraria o acesso.
Gabarito — Cenário 2
Resposta: B
A causa raiz é o comportamento documentado de reprogramação de rede que ocorre ao habilitar um Service Endpoint em uma sub-rede. Esse processo afeta a programação no nível do host virtual para as VMs da sub-rede modificada. Em alguns casos, especialmente quando há múltiplas sub-redes em uma VNet com tráfego intenso, essa reconfiguração pode causar uma interrupção momentânea nas conexões TCP ativas das VMs vizinhas ou da própria sub-rede, mesmo que indiretamente.
A correlação temporal é a pista central: as falhas em subnet-data começaram minutos depois da habilitação do endpoint em subnet-mgmt. Não houve alteração nas regras do Key Vault nem em políticas de acesso.
A informação sobre o estado das regras do Key Vault (Succeeded para ambas as sub-redes) e a confirmação do time de segurança sobre ausência de mudanças em RBAC são detalhes relevantes que eliminam causas de autorização, confirmando que o problema é de conectividade temporária, não de permissão.
O distrator mais perigoso é a alternativa D. Ele induz o leitor a desconfiar de uma fonte de informação confiável (o time de segurança) e a buscar uma causa invisível, quando a causa real é um comportamento técnico conhecido e documentado.
Gabarito — Cenário 3
Resposta: A
A ação correta é remover a regra inválida e adicionar a nova imediatamente, utilizando a janela de tolerância a falhas de 5 minutos que o pipeline já possui por design. Todos os pré-requisitos para a correção estão satisfeitos: o Service Endpoint já está provisionado e com estado Succeeded na sub-rede recriada, e o administrador possui a permissão necessária (Contributor) para modificar regras de rede da conta de armazenamento.
A alternativa B representa a ação correta aplicada no momento errado. Redirecionar para uma conta de contingência nunca testada em produção introduz um risco maior do que a correção direta, especialmente quando a tolerância a falhas existente já cobre o tempo necessário para a operação.
A alternativa D é o distrator mais perigoso porque soa prudente. No entanto, modificar regras de rede virtual em uma conta de armazenamento é uma operação de plano de controle que não causa indisponibilidade prolongada. O receio de aguardar a janela de manutenção prolongaria desnecessariamente uma falha ativa que já está causando impacto há duas semanas.
A alternativa C é falsa: não existe requisito de aprovação de suporte para modificações em regras de rede de contas de armazenamento pelo portal, CLI ou ARM.
Gabarito — Cenário 4
Resposta: A
A sequência correta é T -> P -> Q -> R -> S.
O raciocínio diagnóstico correto segue uma progressão do geral para o específico, eliminando hipóteses na camada mais externa antes de aprofundar:
T confirma a configuração base da conta: se estiver como "Enabled from all networks", toda a investigação de Service Endpoint é desnecessária e o problema está em outra camada. Esse passo filtra o cenário mais rapidamente.
P verifica se o mecanismo de Service Endpoint está ativo na origem. Sem o endpoint habilitado na sub-rede, o tráfego não chega com identidade de rede privada.
Q verifica se a regra de rede está presente, válida e com estado Succeeded. Mesmo com P confirmado, uma regra ausente ou com estado networkSourceDeleted bloqueia o acesso.
R investiga a camada de autorização. O erro 403 pode ter origem em permissão insuficiente de RBAC (ex: Managed Identity sem a role correta), não apenas em firewall de rede.
S é o último passo porque, no contexto de Service Endpoints, o tráfego não usa IP público. Verificar listas de IP permitidos só faz sentido depois de confirmar que o caminho pelo Service Endpoint está corretamente configurado ou descartado.
A alternativa C é o erro mais comum: começar pela camada de autenticação (R) antes de validar a infraestrutura de rede. Um erro 403 induz reflexo de checar credenciais primeiro, mas quando o ambiente usa firewall de rede, a causa mais provável é de roteamento ou regra ausente, não de permissão.
Árvore de Troubleshooting: Create service endpoints
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (sim/não ou estado observável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou caminho alternativo |
Para usar esta árvore diante de um problema real, parta sempre do nó raiz (sintoma de falha de acesso) e responda cada pergunta com base no que for observável diretamente no ambiente, sem presumir estados. Cada ramificação elimina uma hipótese e direciona para a próxima verificação, até que uma causa seja nomeada e uma ação corretiva seja prescrita. Quando a falha for intermitente e recente, verifique também o caminho lateral que parte do nó raiz para o diagnóstico de reconfiguração transitória de rede.