Laboratório Técnico: Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights
Questões
Questão 1 — Múltipla Escolha
Uma equipe de operações precisa identificar automaticamente degradações de desempenho em máquinas virtuais sem criar alertas individuais para cada métrica. O ambiente possui dezenas de VMs distribuídas em múltiplas regiões.
Qual funcionalidade do Azure Monitor atende melhor a esse requisito?
A) Criar regras de alerta baseadas em métricas para cada VM individualmente, com limiares fixos definidos pela equipe.
B) Habilitar o VM Insights e utilizar os mapas de dependência e as análises de desempenho agregadas por grupo de recursos.
C) Configurar um Log Analytics Workspace com consultas KQL agendadas que enviam e-mails quando um limiar é ultrapassado.
D) Usar o Azure Advisor para receber recomendações de desempenho consolidadas por assinatura.
Questão 2 — Cenário Técnico
Um administrador habilitou o VM Insights em uma VM Linux, mas após 30 minutos a aba Map continua vazia e nenhuma dependência de processo é exibida. A aba Performance já mostra dados normalmente.
VM: prod-linux-01
OS: Ubuntu 22.04
VM Insights: habilitado
Workspace: linked
Dependency Agent: status = not running
Azure Monitor Agent: status = running
Qual é a causa mais provável do problema?
A) O Log Analytics Workspace não está na mesma região que a VM, impedindo a coleta de dados de mapa.
B) O Azure Monitor Agent não possui as permissões de identidade gerenciada necessárias para enviar dados ao workspace.
C) O Dependency Agent não está em execução, e ele é o componente responsável por coletar dados de processos e conexões de rede usados no mapa.
D) A aba Map requer que o recurso esteja associado a um Application Insights separado, além do workspace padrão.
Questão 3 — Verdadeiro ou Falso
O Network Insights no Azure Monitor é capaz de exibir a topologia de rede de uma assinatura e, dentro da mesma interface, apresentar métricas de fluxo de tráfego de um Network Security Group específico, desde que o NSG Flow Log esteja habilitado e direcionado a um workspace do Log Analytics com Traffic Analytics ativado.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa armazena logs de transações financeiras em uma Storage Account do tipo General Purpose v2. A equipe de segurança precisa monitorar tentativas de acesso não autorizado a containers de blob específicos. O administrador habilitou as métricas da Storage Account no Azure Monitor, mas as tentativas de acesso negado não aparecem nos dashboards.
Diagnóstico habilitado: métricas agregadas (Transactions, Availability)
Log Analytics Workspace: vinculado
Diagnostic Settings: sem logs de recurso configurados
O que está faltando na configuração atual?
A) Habilitar o Azure Defender for Storage para que os eventos de acesso negado sejam roteados automaticamente ao workspace.
B) Configurar os Diagnostic Settings da Storage Account para enviar as categorias de logs de recurso, como StorageRead, StorageWrite e StorageDelete, ao workspace.
C) Criar uma regra de alerta de métrica usando a métrica Transactions filtrada pela dimensão ResponseType = AuthorizationError.
D) Ativar o Blob Versioning na Storage Account para que os logs de controle de acesso sejam gerados automaticamente.
Questão 5 — Múltipla Escolha
Um administrador está interpretando o painel do Network Insights e observa que uma conexão entre dois recursos aparece com status Reachable no Connection Monitor, mas com latência consistentemente acima de 150 ms, bem acima da linha de base histórica do ambiente.
Qual conclusão é tecnicamente válida com base nessa observação?
A) O status Reachable confirma que a conexão está saudável e a latência elevada deve ser ignorada, pois é um comportamento esperado de monitoramento passivo.
B) O Connection Monitor valida apenas acessibilidade de camada 3; latência persistentemente elevada pode indicar congestionamento, roteamento subótimo ou saturação de largura de banda, exigindo investigação adicional.
C) O problema está necessariamente em um Network Security Group bloqueando parcialmente o tráfego, pois regras de NSG podem aumentar a latência sem bloquear completamente a conexão.
D) O Connection Monitor não é capaz de medir latência; os valores exibidos são estimativas baseadas em logs e não devem ser usados para diagnóstico de desempenho.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O VM Insights é a solução nativa do Azure Monitor projetada exatamente para esse cenário: monitoramento em escala de VMs sem configuração manual por métrica. Ele fornece visualizações agregadas de desempenho (CPU, memória, disco, rede) e mapas de dependência automáticos, com capacidade de filtrar por grupo de recursos, assinatura ou tag.
O principal equívoco dos distratores é confundir ferramentas complementares com a solução adequada ao requisito. Regras de alerta por métrica (A) exigem configuração individual e reativa, não agregação automática. Consultas KQL agendadas (C) são poderosas, mas demandam expertise em consulta e não substituem a experiência integrada do Insights. O Azure Advisor (D) foca em recomendações de custo e conformidade, não em monitoramento contínuo de desempenho.
Gabarito — Questão 2
Resposta: C
O VM Insights usa dois agentes com responsabilidades distintas: o Azure Monitor Agent coleta métricas e logs do sistema operacional (por isso a aba Performance funciona normalmente), enquanto o Dependency Agent é o componente que intercepta chamadas de rede e informações de processos em execução para alimentar a aba Map. Se o Dependency Agent não está em execução, o mapa simplesmente não recebe dados.
A alternativa A é um equívoco comum: a localização do workspace não impede a coleta, apenas pode aumentar a latência de ingestão. A alternativa B descreve um problema real de configuração, mas o sintoma seria ausência de dados em ambas as abas, não somente no mapa. A alternativa D é incorreta: o VM Insights não tem dependência de Application Insights para exibir o mapa de dependência.
Gabarito — Questão 3
Resposta: Verdadeiro
O Network Insights integra visualização de topologia e análise de tráfego em uma única experiência. Para que os dados de fluxo de NSG apareçam, é necessário que dois pré-requisitos estejam satisfeitos: o NSG Flow Log habilitado no Network Watcher e o Traffic Analytics ativado apontando para um workspace do Log Analytics. Sem ambos, a topologia é exibida, mas sem dados de fluxo de tráfego associados.
A afirmação é tecnicamente precisa e representa um comportamento não óbvio: muitos administradores habilitam o NSG Flow Log mas esquecem de ativar o Traffic Analytics, resultando em topologia visível sem análise de fluxo.
Gabarito — Questão 4
Resposta: B
As métricas agregadas de uma Storage Account (como Transactions e Availability) mostram volumes e disponibilidade, mas não contêm informações sobre operações individuais de acesso. Para auditar tentativas de acesso negado, é necessário habilitar os logs de recurso nos Diagnostic Settings, especificamente as categorias StorageRead, StorageWrite e StorageDelete, que registram operações individuais incluindo o resultado de cada requisição (sucesso, autorização negada, etc.).
A alternativa A descreve uma capacidade real do Microsoft Defender for Storage, mas ele serve para detecção de ameaças e alertas de segurança, não para auditoria detalhada de operações. A alternativa C é parcialmente válida como complemento (alertas reativos por dimensão de métrica), mas não substitui os logs para investigação forense. A alternativa D é incorreta: o Blob Versioning controla versões de objetos, sem relação com logs de controle de acesso.
Gabarito — Questão 5
Resposta: B
O Connection Monitor opera nas camadas 3 e 4, validando acessibilidade e medindo latência de ponta a ponta com sondas sintéticas. O status Reachable confirma que o destino é alcançável, mas não indica que a qualidade da conexão é aceitável. Latência persistentemente elevada é um sinal legítimo de problema de desempenho de rede que exige investigação adicional, como análise de rotas com Next Hop, verificação de saturação de gateways ou revisão de configurações de peering.
A alternativa A representa o erro mais perigoso: confundir acessibilidade com saúde da conexão. A alternativa C atribui o problema diretamente a NSGs sem evidência, sendo um diagnóstico prematuro. NSGs bloqueiam ou permitem tráfego, mas não introduzem latência por si mesmos. A alternativa D é factualmente incorreta: o Connection Monitor mede latência de forma ativa e esses dados são utilizáveis para diagnóstico.