Laboratório Técnico: Query and Analyze Logs in Azure Monitor
Questões
Questão 1 — Múltipla Escolha
Um administrador precisa calcular o percentual de requisições com erro HTTP 500 em relação ao total de requisições registradas na tabela AppRequests no último dia. Qual estrutura KQL representa corretamente essa abordagem?
A)
AppRequests
| where ResultCode == "500"
| summarize Erros = count(), Total = count() by bin(TimeGenerated, 1d)
| extend Percentual = Erros * 100.0 / Total
B)
AppRequests
| summarize Erros = countif(ResultCode == "500"), Total = count() by bin(TimeGenerated, 1d)
| extend Percentual = Erros * 100.0 / Total
C)
AppRequests
| summarize Total = count()
| join kind=inner (AppRequests | where ResultCode == "500" | summarize Erros = count()) on $left.Total
| extend Percentual = Erros * 100.0 / Total
D)
AppRequests
| where ResultCode == "500" or ResultCode != "500"
| summarize Erros = countif(ResultCode == "500"), Total = count()
| extend Percentual = Erros / Total
Questão 2 — Cenário Técnico
Uma equipe configurou um Log Analytics Workspace e habilitou a coleta de logs de diagnóstico de um Azure Key Vault. Após 30 minutos, um membro executa a query abaixo e não obtém nenhum resultado:
AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName == "SecretGet"
| take 10
O Key Vault foi acessado com sucesso durante esse período e os segredos foram lidos por uma aplicação. Qual é a causa mais provável do resultado vazio?
A) A tabela AzureDiagnostics não suporta logs de Key Vault; o correto seria consultar a tabela KeyVaultLogs.
B) A configuração de Diagnostic Settings no Key Vault não foi feita ou não inclui a categoria de log AuditEvent, que registra operações como SecretGet.
C) O operador take impede que filtros anteriores sejam processados corretamente em tabelas de diagnóstico.
D) Logs de diagnóstico do Key Vault só ficam disponíveis após 24 horas de ingestão no workspace.
Questão 3 — Verdadeiro ou Falso
No Azure Monitor, uma Saved Search (consulta salva) em um Log Analytics Workspace pode ser usada diretamente como fonte de dados para um Alert Rule baseado em log, eliminando a necessidade de redigitar a query KQL na configuração do alerta.
Questão 4 — Cenário Técnico
Um administrador precisa cruzar dados de desempenho de VMs com eventos de segurança para identificar se picos de CPU coincidem com logons suspeitos. As tabelas relevantes são Perf e SecurityEvent. Ele escreve a seguinte query:
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 90
| join kind=inner (
SecurityEvent
| where EventID == 4624
| where LogonType == 10
) on Computer
A query retorna resultados, mas o administrador percebe que eventos de logon de computadores sem pico de CPU também estão aparecendo. Qual é o problema?
A) O join kind=inner deveria ser join kind=leftouter, pois o inner descarta linhas da tabela esquerda sem correspondência.
B) A coluna Computer pode ter valores com capitalização inconsistente entre as tabelas, causando duplicação de linhas ao invés de filtragem incorreta.
C) Falta uma condição temporal no join para restringir que os eventos de logon ocorram próximos ao intervalo de tempo dos picos de CPU, pois o join em Computer une todas as linhas correspondentes independentemente do horário.
D) O filtro CounterValue > 90 deve estar dentro do bloco join para ser aplicado após a união das tabelas.
Questão 5 — Múltipla Escolha
Ao criar um Log Search Alert no Azure Monitor, um administrador define o período de avaliação como 5 minutos e a frequência como 1 minuto. O limiar é configurado para disparar quando o número de resultados for maior que 0. Qual afirmação descreve corretamente o comportamento desse alerta?
A) A query será executada a cada 1 minuto, analisando os dados dos últimos 5 minutos; portanto, um mesmo evento pode ser detectado em até 5 execuções consecutivas.
B) A query será executada a cada 5 minutos, e o intervalo de 1 minuto define apenas o tempo mínimo entre dois disparos consecutivos.
C) A frequência de 1 minuto é inválida quando o período de avaliação é de 5 minutos; o Azure Monitor exige que a frequência seja igual ou maior que o período.
D) Cada execução da query analisa apenas os dados gerados desde a última execução, evitando qualquer sobreposição de janelas de avaliação.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
A função countif permite contar condicionalmente dentro de um único operador summarize, calculando ao mesmo tempo o total geral e o subconjunto de erros. Isso é mais correto e eficiente do que filtrar previamente com where, como na alternativa A, que descarta as linhas sem erro antes do summarize, tornando impossível calcular o total real de requisições.
A alternativa C tenta usar join para combinar dois resumos distintos, mas a lógica da chave de junção está incorreta e produziria um produto cartesiano indesejado. A alternativa D usa where ResultCode == "500" or ResultCode != "500", que é uma tautologia sem efeito real, e calcula o percentual com divisão inteira (sem * 100.0), resultando em zero para proporções menores que 1.
O ponto central é que countif resolve o problema em uma única passagem pela tabela, sem modificar o conjunto de dados analisado.
Gabarito — Questão 2
Resposta: B
Logs de diagnóstico no Azure não fluem automaticamente para um Log Analytics Workspace após a associação do recurso. É necessário configurar explicitamente as Diagnostic Settings do recurso, selecionando quais categorias de log e métricas devem ser enviadas e para qual destino. No caso do Key Vault, a categoria AuditEvent é a responsável por registrar operações de plano de dados como SecretGet, SecretSet e similares.
A alternativa A está incorreta: Key Vault pode registrar dados na tabela AzureDiagnostics dependendo do modo de coleta; a tabela KeyVaultLogs existe em workspaces que usam o modo de recurso específico, mas a ausência de resultados não é explicada pela escolha de tabela nesse cenário. A alternativa C é falsa, pois take não interfere na filtragem. A alternativa D está errada porque o atraso típico de ingestão é de poucos minutos, não 24 horas.
Gabarito — Questão 3
Resposta: Falso
Embora Saved Searches permitam salvar e reutilizar queries no Log Analytics Workspace, elas não funcionam como fonte de dados direta ao configurar um Alert Rule no Azure Monitor. Ao criar um alerta baseado em log, a query KQL deve ser inserida explicitamente na configuração do alerta. O alerta mantém sua própria cópia da query, independente de qualquer consulta salva. Não há vínculo dinâmico entre uma Saved Search e um Alert Rule que atualize automaticamente a query do alerta quando a consulta salva for modificada.
Esse é um ponto de confusão comum: a funcionalidade de salvar consultas serve à produtividade operacional de analistas, não à automação de alertas.
Gabarito — Questão 4
Resposta: C
O operador join no KQL une linhas com base na chave especificada, que nesse caso é Computer. Isso significa que cada linha da tabela Perf com pico de CPU será combinada com todas as linhas de SecurityEvent que tenham o mesmo valor de Computer, independentemente do momento em que o logon ocorreu. Um logon registrado dias antes será incluído nos resultados.
Para que o cruzamento seja temporalmente significativo, é necessário adicionar uma condição de proximidade temporal, geralmente usando bin(TimeGenerated, Xm) em ambas as tabelas antes do join, ou filtrando com | where TimeGenerated between ... dentro do subquery.
A alternativa A inverte a lógica: inner descarta linhas sem correspondência, o que seria o comportamento desejado; trocar por leftouter pioraria o problema. A alternativa B descreve um problema real de qualidade de dados, mas não explica por que eventos de outros momentos aparecem. A alternativa D é tecnicamente incorreta: mover o filtro para dentro do join não altera a lógica de correspondência temporal.
Gabarito — Questão 5
Resposta: A
Em um Log Search Alert, a frequência define de quanto em quanto tempo a query é executada, e o período de avaliação define a janela de tempo analisada em cada execução. Com frequência de 1 minuto e janela de 5 minutos, a query roda a cada minuto e sempre "olha para trás" 5 minutos. Isso cria sobreposição intencional de janelas: um evento ocorrido no minuto 3 estará presente nas execuções dos minutos 3, 4, 5, 6 e 7.
A alternativa B inverte os papéis de frequência e período. A alternativa C está errada porque o Azure Monitor permite que a frequência seja menor que o período de avaliação; essa é inclusive a configuração recomendada para maior sensibilidade a eventos. A alternativa D contradiz o funcionamento documentado: as janelas se sobrepõem por design, e não há mecanismo de "checkpoint" que registre onde a última execução parou.