Pular para o conteúdo principal

Laboratório Técnico: Configure health probes

Questões​

Questão 1 — Múltipla Escolha​

Um engenheiro de redes está configurando um Azure Load Balancer na camada Standard para distribuir tráfego HTTP entre três máquinas virtuais. O backend pool possui instâncias que respondem na porta 80. Ele cria uma health probe com as seguintes configurações:

ParâmetroValor
ProtocoloTCP
Porta80
Intervalo5 segundos
Limiar de falha2

Após a implantação, o engenheiro percebe que uma das VMs está servindo respostas HTTP com status 503, mas o Load Balancer continua enviando tráfego para ela.

Qual é a causa mais provável desse comportamento?

A) O protocolo TCP não verifica o código de status HTTP, portanto a probe considera a VM saudável enquanto a conexão TCP for estabelecida com sucesso.

B) O limiar de falha configurado como 2 é insuficiente para detectar falhas intermitentes no protocolo HTTP.

C) O intervalo de 5 segundos é muito curto para que o Load Balancer atualize o estado da instância.

D) O Azure Load Balancer Standard não suporta health probes na porta 80 quando o protocolo é TCP.

Questão 2 — Cenário Técnico​

Uma equipe configurou um Application Gateway v2 com o seguinte trecho de definição de health probe customizada:

{
  "name": "custom-probe",
  "protocol": "Https",
  "host": "app.internal.corp",
  "path": "/health",
  "interval": 30,
  "timeout": 30,
  "unhealthyThreshold": 3,
  "pickHostNameFromBackendHttpSettings": false
}

O backend retorna HTTP 200 na rota /health, mas o Application Gateway marca todos os membros do pool como unhealthy. Certificados e conectividade de rede foram verificados e estão corretos.

Qual é o erro mais provável na configuração da probe?

A) O campo timeout não pode ser igual ao campo interval; o timeout deve ser menor que o intervalo para que o ciclo de probe funcione corretamente.

B) O campo path deve sempre iniciar com o hostname completo, e não apenas com o caminho relativo.

C) O campo host está configurado com um valor específico, mas pickHostNameFromBackendHttpSettings está definido como false, podendo causar incompatibilidade se o backend exigir o header Host correto.

D) O unhealthyThreshold configurado como 3 impede que o Application Gateway marque membros como unhealthy antes de três falhas consecutivas, gerando um estado intermediário inválido.

Questão 3 — Verdadeiro ou Falso​

Afirmação: Em um Azure Load Balancer Standard, se todas as instâncias do backend pool forem marcadas como unhealthy pela health probe, o Load Balancer interrompe completamente o encaminhamento de tráfego e nenhuma requisição é entregue ao pool.

Verdadeiro ou Falso?

Questão 4 — Cenário Técnico​

Um arquiteto precisa configurar health probes para um Azure Load Balancer interno que distribui tráfego entre instâncias de um serviço que não expõe nenhum endpoint HTTP ou TCP dedicado para verificação de saúde. A aplicação só pode ser considerada saudável se o processo principal estiver em execução, o que é verificado por um agente local na VM.

Qual abordagem resolve esse requisito de forma mais adequada dentro das capacidades nativas das health probes do Azure Load Balancer?

A) Criar uma health probe do tipo HTTP apontando para a porta da aplicação principal e interpretar qualquer resposta como sinal de saúde, independentemente do código de status.

B) Criar um endpoint HTTP dedicado na VM, controlado pelo agente local, que retorne 200 apenas quando o processo principal estiver saudável, e configurar a probe para esse endpoint.

C) Usar uma health probe do tipo TCP na porta do processo principal, pois o Azure Load Balancer consegue inspecionar o estado do processo a partir da conexão TCP estabelecida.

D) Configurar a health probe com protocolo HTTPS apontando para o IP da VM, dispensando qualquer endpoint adicional, pois o TLS handshake valida o estado do serviço.

Questão 5 — Múltipla Escolha​

Ao comparar health probes do Azure Load Balancer com health probes do Application Gateway, qual das afirmações abaixo descreve corretamente uma diferença de comportamento entre os dois serviços?

A) O Azure Load Balancer suporta probes com protocolo HTTPS, enquanto o Application Gateway suporta apenas HTTP e TCP.

B) O Application Gateway permite configurar o campo path em probes HTTP/HTTPS, enquanto o Azure Load Balancer não oferece esse nível de granularidade na verificação de caminho.

C) O Azure Load Balancer envia probes a partir de um IP fixo e documentado, enquanto o Application Gateway envia probes a partir dos endereços IP das suas instâncias de infraestrutura no intervalo 168.63.129.16.

D) O Application Gateway ignora o código de status HTTP retornado pelo backend e considera qualquer resposta como indicador de saúde, ao contrário do Azure Load Balancer.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: A

Explique:

  • Uma probe TCP apenas verifica se é possível estabelecer uma conexão TCP na porta especificada. Ela não interpreta o conteúdo da resposta HTTP nem inspeciona o código de status. Se a porta 80 aceita conexões, a VM é considerada saudável pelo Load Balancer, mesmo que a aplicação responda com 503.
  • As alternativas B e C representam equívocos sobre parâmetros de tunagem: o limiar de 2 e o intervalo de 5 segundos são configurações válidas e funcionais. A alternativa D é incorreta porque o Azure Load Balancer Standard suporta plenamente TCP na porta 80.
  • A consequência prática de escolher TCP quando se precisa validar a camada de aplicação é exatamente esse cenário: instâncias degradadas continuam recebendo tráfego. Para detectar 503, a probe deve ser configurada com protocolo HTTP, apontando para um path adequado.

Gabarito — Questão 2​

Resposta: A

Explique:

  • No Application Gateway, o campo timeout define quanto tempo a probe aguarda resposta antes de considerar a tentativa como falha. Quando timeout é igual a interval, o gateway não tem margem de tempo para iniciar o próximo ciclo após o encerramento do anterior, gerando um comportamento de probe inválido que pode resultar em todos os membros sendo marcados como unhealthy.
  • A alternativa C descreve uma situação real e válida de problema com o header Host, mas o enunciado especifica que certificados e conectividade foram verificados, deslocando a causa para a relação timeout/interval.
  • A boa prática documentada pela Microsoft exige que timeout seja estritamente menor que interval. Manter os dois iguais é um erro de configuração comum que passa despercebido até que o ambiente seja colocado em produção.

Gabarito — Questão 3​

Resposta: Falso

Explique:

  • O Azure Load Balancer Standard implementa um comportamento chamado "probe down, all up": quando todas as instâncias do backend pool são marcadas como unhealthy, o Load Balancer retoma o encaminhamento de tráfego para todas elas, tratando o pool como se todas estivessem saudáveis.
  • Esse comportamento existe para evitar interrupção total de serviço em situações onde a probe está mal configurada ou o endpoint de saúde falhou, mas a aplicação ainda pode atender requisições.
  • A distinção é importante: o comportamento descrito na afirmação se aplicaria intuitivamente, mas não é o que o serviço faz. Ignorar essa característica pode levar a diagnósticos incorretos durante incidentes.

Gabarito — Questão 4​

Resposta: B

Explique:

  • O Azure Load Balancer não possui capacidade de inspecionar o estado interno de processos de sistema operacional. Ele verifica conectividade TCP ou respostas HTTP/HTTPS em uma porta e path configurados. A solução correta é instrumentar a VM com um endpoint HTTP controlado pelo próprio agente, que retorne 200 somente quando o processo principal estiver em execução.
  • A alternativa A é parcialmente plausível, mas o Load Balancer HTTP probe considera apenas os códigos de status 200-399 como sucesso. Qualquer resposta fora dessa faixa marca a instância como unhealthy, portanto a premissa de "ignorar o código de status" está errada.
  • A alternativa C representa um equívoco frequente: a conexão TCP bem-sucedida indica apenas que a porta está ouvindo, não que o processo subjacente está funcional.
  • A alternativa D é tecnicamente incoerente: o TLS handshake verifica a validade do certificado, não o estado da aplicação.

Gabarito — Questão 5​

Resposta: B

Explique:

  • O Application Gateway opera na camada 7 e suas health probes suportam a configuração de um path específico (como /health ou /status), permitindo validar um endpoint dedicado no backend. O Azure Load Balancer, por sua natureza de camada 4 (com suporte a probes HTTP/HTTPS), não permite especificar um path nas probes HTTP; ele verifica apenas se a porta responde com um código de status de sucesso.
  • A alternativa A inverte os fatos: o Azure Load Balancer não suporta HTTPS em suas probes; o Application Gateway sim.
  • A alternativa C confunde as origens de probe: o endereço 168.63.129.16 é o IP de origem das probes do Azure Load Balancer, não do Application Gateway.
  • A alternativa D está errada porque o Application Gateway verifica o código de status HTTP e considera apenas respostas dentro de faixas configuráveis como indicador de saúde.