Laboratório de Troubleshooting: Create a Virtual Machine
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador tenta criar uma VM via portal do Azure na região East US, dentro do grupo de recursos rg-financeiro. A assinatura está ativa e o administrador possui a role Contributor no grupo de recursos. A VNet vnet-financeiro já existe e possui sub-redes configuradas. O disco do SO será gerenciado pelo Azure (managed disk).
Durante a criação, ao clicar em "Review + Create", a seguinte mensagem de erro é exibida:
The subscription does not have enough vCPU quota to create the resource.
Details: Subscription quota for Standard BSv2 Family vCPUs: 0 available, 4 required.
Location: East US
O administrador observa que outras VMs do tamanho Standard_B2ms foram criadas com sucesso na mesma região no dia anterior. A equipe de rede confirmou que não há bloqueios de NSG na sub-rede de destino. O time de segurança informou que uma política de Microsoft Entra Conditional Access foi atualizada na semana anterior.
Qual é a causa raiz do erro?
A) A role Contributor não tem permissão para provisionar VMs; é necessária a role Virtual Machine Contributor.
B) A quota de vCPUs para a família Standard BSv2 está esgotada na região East US para a assinatura.
C) A política de Microsoft Entra Conditional Access bloqueou o acesso do administrador ao Azure Resource Manager.
D) O managed disk não está disponível para o tamanho de VM selecionado na região East US.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que uma VM crítica de produção, vm-erp-prod, está inacessível via RDP. Após investigação, a causa foi confirmada: a regra de entrada que permitia a porta 3389 no NSG associado à interface de rede da VM foi excluída acidentalmente por um membro da equipe. A VM está em execução, o disco do SO não apresenta erros e a VNet está funcionando normalmente.
O ambiente possui as seguintes restrições:
- A VM não pode ser reiniciada durante o horário comercial (08h às 18h)
- O acesso ao portal do Azure está disponível
- O horário atual é 14h30
- Existe um Azure Bastion provisionado na mesma VNet
Qual é a ação correta a tomar neste momento?
A) Recriar a regra de entrada no NSG permitindo a porta 3389 da origem necessária.
B) Recriar a regra de entrada no NSG e reiniciar a VM para que as mudanças de rede sejam aplicadas.
C) Conectar à VM usando o Azure Bastion via porta 443, sem alterar o NSG, para executar as correções necessárias.
D) Aguardar o fim do horário comercial para reiniciar a VM e aplicar o novo NSG.
Cenário 3 — Causa Raiz
Um desenvolvedor relata que uma VM Linux recém-criada, vm-devapp-01, não aceita conexões SSH. A VM foi criada via CLI com os seguintes parâmetros relevantes:
az vm create \
--resource-group rg-desenvolvimento \
--name vm-devapp-01 \
--image Ubuntu2204 \
--size Standard_D2s_v3 \
--admin-username devuser \
--authentication-type password \
--admin-password "P@ssw0rd2024!" \
--public-ip-sku Standard \
--nsg-rule NONE
A VM está com status "Running" no portal. O endereço IP público foi atribuído corretamente. O desenvolvedor tentou conectar com o comando:
ssh devuser@40.112.72.134
A conexão trava indefinidamente sem retornar erro de autenticação. A equipe de rede confirmou que não há firewall corporativo bloqueando a porta 22. A assinatura tem quota suficiente para o tamanho escolhido.
Qual é a causa raiz do problema?
A) O tipo de autenticação por senha não é compatível com imagens Ubuntu no Azure; é necessário usar chave SSH.
B) O IP público com SKU Standard requer configuração manual de rota antes de aceitar tráfego de entrada.
C) O parâmetro --nsg-rule NONE criou a VM sem nenhuma regra de entrada no NSG, bloqueando o tráfego na porta 22.
D) O tamanho Standard_D2s_v3 não inclui interface de rede pública por padrão e requer configuração adicional.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta de que a VM vm-webserver-02 está inacessível via HTTP (porta 80). A VM está com status "Running", possui IP público e está em uma sub-rede com NSG associado. O administrador precisa diagnosticar o problema.
Os passos de investigação disponíveis são:
- Passo P: Verificar se o serviço web (IIS ou nginx) está em execução dentro da VM via conexão de gerenciamento
- Passo Q: Verificar o status de execução da VM no portal do Azure
- Passo R: Inspecionar as regras de entrada do NSG associado à sub-rede e à interface de rede
- Passo S: Usar o recurso Connection Troubleshoot do Network Watcher para testar conectividade da porta 80
- Passo T: Verificar se há um Azure Load Balancer na frente da VM com regras de balanceamento configuradas para a porta 80
Qual sequência de diagnóstico é a mais lógica e eficiente?
A) Q → R → S → T → P
B) P → Q → R → S → T
C) S → Q → T → R → P
D) R → T → Q → S → P
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é explícita: a quota de vCPUs para a família Standard BSv2 está em zero para a região East US. Esse é o ponto central do diagnóstico e não deixa ambiguidade.
A pista determinante está na própria saída do erro, que especifica a família de vCPUs e o valor disponível. O fato de VMs Standard_B2ms terem sido criadas com sucesso não contradiz isso: B2ms pertence à família Standard Bsv2, enquanto o tamanho selecionado pertence à família Standard BSv2, que é uma família diferente com quota independente.
A informação sobre a atualização da política de Microsoft Entra Conditional Access é a informação irrelevante inserida propositalmente. Políticas de acesso condicional afetam autenticação, não o provisionamento de recursos via cota. O NSG também não tem relação com o erro apresentado.
A alternativa A é um equívoco comum: a role Contributor tem permissão plena para criar VMs. A alternativa C representa o erro de raciocínio mais perigoso: atribuir a falha a uma mudança recente de segurança sem avaliar a mensagem de erro objetiva. A alternativa D é tecnicamente incoerente, pois managed disks são suportados em praticamente todos os tamanhos de VM.
Gabarito — Cenário 2
Resposta: C
A causa já foi identificada (NSG sem a regra RDP), mas a restrição crítica é que a VM não pode ser reiniciada durante o horário comercial e o horário atual é 14h30. O Azure Bastion está disponível na VNet e opera pela porta 443 (HTTPS), que não depende de regras de NSG para RDP.
O Bastion permite acesso administrativo imediato à VM sem expor a porta 3389 e sem exigir reinicialização. Isso resolve a necessidade operacional urgente dentro das restrições impostas.
A alternativa A seria válida fora do horário restrito, mas recria a exposição da porta RDP diretamente, o que não é necessário se o Bastion está disponível. A alternativa B comete o erro duplo de recriar a regra RDP e reiniciar durante o horário proibido. A alternativa D ignora que o Azure Bastion resolve o problema imediatamente sem reinicialização, desperdiçando disponibilidade do sistema.
O distrator mais perigoso é A: tecnicamente parece a solução mais direta, mas ignora que o Bastion já existe e é a abordagem correta para o contexto.
Gabarito — Cenário 3
Resposta: C
O parâmetro --nsg-rule NONE instrui o Azure a criar a VM sem adicionar nenhuma regra de entrada ao NSG gerado automaticamente. Por padrão, quando esse parâmetro não é especificado, a CLI adiciona uma regra de entrada para SSH (porta 22). Ao usar NONE, nenhuma regra é criada, e o NSG bloqueia todo tráfego de entrada, incluindo a porta 22.
O comportamento observado, a conexão que trava sem retornar erro de autenticação, é consistente com um NSG bloqueando o tráfego: o pacote TCP não recebe resposta (sem RST), diferente de uma senha incorreta, que retornaria prompt de autenticação.
A informação irrelevante é a confirmação da equipe de rede sobre ausência de firewall corporativo. Ela elimina uma hipótese de camada externa, mas não aponta para a causa real dentro da configuração da VM.
A alternativa A é falsa: autenticação por senha é suportada em imagens Ubuntu no Azure, embora não seja recomendada. A alternativa B representa um equívoco sobre o comportamento de IPs públicos com SKU Standard: eles são seguros por padrão (exigem NSG), mas não requerem configuração de rota manual. A alternativa D é tecnicamente incoerente para a arquitetura Azure.
Gabarito — Cenário 4
Resposta: A
A sequência correta é Q → R → S → T → P, que segue a lógica de diagnóstico progressivo do mais simples e externo para o mais interno e específico.
Q verifica primeiro se a VM está em execução, pois todo diagnóstico de rede é irrelevante se a VM está parada. R inspeciona o NSG, que é a barreira de rede mais próxima da VM e a causa mais comum de inacessibilidade de porta. S usa o Network Watcher para validar conectividade de ponta a ponta na porta 80, confirmando ou descartando hipóteses de rede. T verifica se há um Load Balancer com regras incorretas ou ausentes, o que poderia interceptar o tráfego antes de chegar à VM. P só faz sentido como último passo: acessar o interior da VM para verificar o serviço pressupõe que toda a camada de rede está funcional.
A alternativa B inverte a lógica ao começar dentro da VM antes de validar se há conectividade de rede. A alternativa C começa com uma ferramenta de diagnóstico de rede sem antes confirmar o estado básico da VM. A alternativa D inicia pela inspeção do NSG sem antes confirmar que a VM está ativa, o que pode desperdiçar tempo investigando rede de uma VM parada.
Árvore de Troubleshooting: Create a Virtual Machine
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou confirmação de resolução |
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz, que representa o sintoma observado. A cada nó de decisão, responda com base no que é verificável diretamente no portal, na CLI ou na saída de comandos. Siga o ramo correspondente à resposta observada sem pular etapas. Os nós vermelhos indicam que a causa foi isolada e exigem ação corretiva específica. Os nós verdes descrevem exatamente o que fazer. Chegue ao nó laranja de validação para confirmar que o problema foi resolvido antes de encerrar o diagnóstico.