Laboratório de Troubleshooting: Implement Azure Bastion
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador tenta implantar o Azure Bastion em uma VNet de produção chamada vnet-prod na região East US. A VNet possui as seguintes sub-redes já criadas:
| Sub-rede | Prefixo CIDR |
|---|---|
| snet-frontend | 10.0.1.0/24 |
| snet-backend | 10.0.2.0/24 |
| snet-bastion | 10.0.3.0/27 |
| snet-management | 10.0.4.0/26 |
O administrador seleciona a sub-rede snet-bastion como destino da implantação. A implantação falha com a seguinte mensagem:
Error: AzureBastionSubnet requires an address prefix of at least /26.
The current prefix /27 is too small.
Ele nota que a sub-rede snet-management tem prefixo /26 e considera migrar o Bastion para ela. O time de segurança informa que o NSG associado à snet-management bloqueia toda entrada que não seja da faixa 10.0.0.0/8. A conta utilizada para a implantação possui a role Contributor na assinatura.
Qual é a causa raiz da falha na implantação?
A. A role Contributor não possui permissão para criar recursos do Azure Bastion; é necessária a role Owner ou uma role customizada com permissões específicas de rede.
B. A sub-rede selecionada possui prefixo /27, que é insuficiente para o Azure Bastion, e o nome da sub-rede não é AzureBastionSubnet, que é obrigatório.
C. O NSG associado à sub-rede bloqueia o tráfego necessário para o plano de controle do Azure Bastion, impedindo a implantação.
D. O prefixo /27 é insuficiente para o Azure Bastion, que exige no mínimo /26.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que o Azure Bastion implantado em vnet-hub com SKU Standard não consegue alcançar VMs em vnet-spoke-01. O peering entre as duas VNets existe e está no estado Connected em ambos os lados. A opção Allow forwarded traffic está habilitada. O time confirma que as VMs em vnet-spoke-01 respondem normalmente a conexões internas originadas de outras VMs na mesma VNet.
A causa foi identificada: a opção Allow gateway transit não está habilitada no peering do lado de vnet-hub, e a opção Use remote gateways não está habilitada no lado de vnet-spoke-01.
O ambiente está em produção. Alterar configurações de peering causa uma breve interrupção de conectividade entre as VNets durante a reconfiguração. Há uma janela de manutenção agendada para daqui a 4 horas. O gerente solicita que o acesso Bastion às VMs de vnet-spoke-01 seja restaurado com urgência, sem esperar a janela.
Qual é a ação correta a tomar neste momento?
A. Implantar um segundo Azure Bastion diretamente em vnet-spoke-01, pois isso resolve o problema sem alterar o peering existente e sem impacto em produção.
B. Corrigir imediatamente as opções de peering nas duas VNets fora da janela de manutenção, pois o impacto é mínimo e a urgência justifica a ação.
C. Aguardar a janela de manutenção para corrigir as opções de peering, pois a alteração causa interrupção e o ambiente está em produção.
D. Desativar e recriar o peering completo entre as VNets para garantir que todas as opções sejam aplicadas corretamente.
Cenário 3 — Causa Raiz
Um analista reporta que ao tentar se conectar a uma VM Windows via Azure Bastion pelo portal do Azure, a sessão abre normalmente, mas o botão de Upload/Download de arquivo não aparece na barra de ferramentas da sessão RDP. Outros membros da equipe relatam o mesmo comportamento. O Bastion está operacional e todas as outras conexões funcionam normalmente.
O administrador verifica o ambiente e coleta as seguintes informações:
Bastion Name: bastion-prod
SKU: Basic
Location: Brazil South
Provisioning State: Succeeded
Scale Units: 2
Public IP SKU: Standard
O time de rede informa que o NSG da AzureBastionSubnet foi recentemente revisado e todas as regras obrigatórias estão presentes e corretas. A VM de destino roda Windows Server 2022 e tem o agente do Azure instalado e atualizado.
Qual é a causa raiz do comportamento observado?
A. O NSG da AzureBastionSubnet está bloqueando o canal de dados necessário para transferência de arquivos, mesmo que as regras obrigatórias estejam presentes.
B. O agente do Azure na VM de destino precisa ser atualizado para uma versão que suporte transferência de arquivos via Bastion.
C. O SKU Basic não suporta transferência de arquivos em sessões RDP; esse recurso está disponível apenas no SKU Standard ou superior.
D. A unidade de escala configurada como 2 é insuficiente para habilitar funcionalidades avançadas como transferência de arquivos.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "Não consigo me conectar a nenhuma VM pelo Azure Bastion. O portal abre a tela de conexão, mas após inserir as credenciais, a sessão não estabelece e aparece uma tela em branco."
O administrador precisa diagnosticar o problema. Os passos de investigação disponíveis são:
- Verificar se o Provisioning State do Bastion é Succeeded no portal do Azure
- Verificar se a VM de destino está no estado Running e com o agente do Azure responsivo
- Confirmar se o NSG da AzureBastionSubnet possui todas as regras obrigatórias de entrada e saída
- Testar a conexão com uma segunda VM diferente para isolar se o problema é da VM ou do Bastion
- Verificar nos logs de diagnóstico do Bastion se há erros de sessão registrados
Qual é a sequência correta de investigação?
A. 1 → 3 → 2 → 4 → 5
B. 2 → 4 → 1 → 3 → 5
C. 1 → 2 → 4 → 3 → 5
D. 3 → 1 → 2 → 5 → 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro informa explicitamente que o prefixo /27 é insuficiente, o que confirma metade do problema. Porém, o erro mais completo e a causa raiz real envolvem dois requisitos violados simultaneamente: o prefixo inadequado (/27 em vez de /26) e o nome incorreto da sub-rede (snet-bastion em vez de AzureBastionSubnet). O Azure Bastion exige ambos para aceitar a implantação.
A alternativa D identifica apenas o problema do prefixo e ignora o requisito do nome, que é igualmente obrigatório. Tentar corrigir só o prefixo resultaria em outra falha imediata por nome incorreto.
A alternativa C é a informação irrelevante inserida propositalmente: o NSG da snet-management é irrelevante porque o Bastion não está sendo implantado nessa sub-rede, e NSGs não impedem a implantação, apenas o tráfego operacional posterior.
A alternativa A é incorreta porque a role Contributor possui permissões suficientes para criar recursos de rede, incluindo o Azure Bastion. Agir com base no distrator C levaria o administrador a gastar tempo ajustando NSGs sem nunca resolver a falha real de implantação.
Gabarito — Cenário 2
Resposta: A
A causa já foi identificada no enunciado, portanto o raciocínio aqui é sobre a restrição de contexto: o ambiente está em produção, a alteração de peering causa interrupção, e há urgência declarada. Implantar um segundo Azure Bastion diretamente em vnet-spoke-01 resolve o acesso imediato sem tocar no peering existente e sem gerar interrupção, respeitando todas as restrições simultaneamente.
A alternativa B ignora a restrição crítica de produção. Mesmo que o impacto seja breve, agir fora da janela em ambiente produtivo sem autorização explícita representa um risco operacional e de governança.
A alternativa C seria correta se não houvesse a urgência declarada pelo gerente, mas o enunciado explicita que o acesso precisa ser restaurado antes da janela.
A alternativa D é a mais perigosa: recriar o peering interrompe completamente a conectividade entre as VNets até que seja restabelecido, agravando o impacto em produção em vez de mitigá-lo.
Gabarito — Cenário 3
Resposta: C
A saída coletada pelo administrador mostra claramente SKU: Basic. A transferência de arquivos em sessões RDP é uma funcionalidade exclusiva do SKU Standard. No SKU Basic, a sessão funciona normalmente para acesso interativo, mas sem o conjunto de funcionalidades avançadas que inclui upload/download.
A alternativa A é a informação irrelevante do cenário: o NSG foi revisado e está correto, e o enunciado confirma isso. Focar no NSG seria um erro clássico de desvio para o último ponto alterado no ambiente, mesmo que ele não seja a causa.
A alternativa B é incorreta porque o agente do Azure não tem relação com a funcionalidade de transferência de arquivos do Bastion; essa funcionalidade é controlada pelo SKU do serviço, não pelo estado da VM.
A alternativa D é incorreta porque as unidades de escala controlam a capacidade de sessões simultâneas, não a disponibilidade de funcionalidades. Agir com base na alternativa A levaria o administrador a rever e modificar NSGs sem nenhum efeito sobre o comportamento observado.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 1 → 3 → 2 → 4 → 5, seguindo a lógica de diagnóstico progressivo do serviço para o recurso específico:
- Passo 1 confirma se o próprio Bastion está operacional antes de investigar qualquer outra coisa. Se o provisionamento falhou, todos os outros passos são irrelevantes.
- Passo 3 valida a camada de rede do Bastion. Um NSG mal configurado na AzureBastionSubnet impede todas as sessões, o que é consistente com o sintoma relatado (nenhuma VM acessível).
- Passo 2 verifica o estado da VM de destino após confirmar que o Bastion está saudável.
- Passo 4 isola se o problema é específico de uma VM ou geral do serviço, refinando o diagnóstico.
- Passo 5 consulta os logs apenas após esgotar as verificações observáveis diretamente, usando-os como confirmação ou para identificar causas não visíveis nas etapas anteriores.
A alternativa B começa pela VM, o que inverte a lógica: verificar a VM antes de confirmar que o serviço está operacional desperdiça tempo quando a causa pode ser sistêmica. A alternativa D começa pelo NSG antes de confirmar o estado do Bastion, o que também é prematuro.
Árvore de Troubleshooting: Implement Azure Bastion
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada do diagnóstico
- Azul médio: pergunta diagnóstica, decisão de ramificação
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
- Laranja: validação ou verificação intermediária
Diante de um problema real com o Azure Bastion, comece pelo nó raiz e responda cada pergunta com base no que é observável diretamente no portal ou via CLI. Siga o caminho que corresponde ao estado real do ambiente, sem pular etapas. Os nós vermelhos indicam onde o problema está; os nós verdes indicam o que deve ser feito. O nó laranja confirma que o caminho de resolução foi percorrido corretamente antes de encerrar o diagnóstico.