Technical Lab: Query and Analyze Logs in Azure Monitor
Questions
Question 1 — Multiple Choice
An administrator needs to calculate the percentage of HTTP 500 error requests relative to the total requests recorded in the AppRequests table in the last day. Which KQL structure correctly represents this approach?
A)
AppRequests
| where ResultCode == "500"
| summarize Errors = count(), Total = count() by bin(TimeGenerated, 1d)
| extend Percentage = Errors * 100.0 / Total
B)
AppRequests
| summarize Errors = countif(ResultCode == "500"), Total = count() by bin(TimeGenerated, 1d)
| extend Percentage = Errors * 100.0 / Total
C)
AppRequests
| summarize Total = count()
| join kind=inner (AppRequests | where ResultCode == "500" | summarize Errors = count()) on $left.Total
| extend Percentage = Errors * 100.0 / Total
D)
AppRequests
| where ResultCode == "500" or ResultCode != "500"
| summarize Errors = countif(ResultCode == "500"), Total = count()
| extend Percentage = Errors / Total
Question 2 — Technical Scenario
A team configured a Log Analytics Workspace and enabled diagnostic log collection from an Azure Key Vault. After 30 minutes, a member executes the query below and gets no results:
AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName == "SecretGet"
| take 10
The Key Vault was successfully accessed during this period and secrets were read by an application. What is the most likely cause of the empty result?
A) The AzureDiagnostics table doesn't support Key Vault logs; the correct approach would be to query the KeyVaultLogs table.
B) The Diagnostic Settings configuration on the Key Vault was not done or doesn't include the AuditEvent log category, which records operations like SecretGet.
C) The take operator prevents previous filters from being processed correctly in diagnostic tables.
D) Key Vault diagnostic logs are only available after 24 hours of ingestion in the workspace.
Question 3 — True or False
In Azure Monitor, a Saved Search (saved query) in a Log Analytics Workspace can be used directly as a data source for a log-based Alert Rule, eliminating the need to retype the KQL query in the alert configuration.
Question 4 — Technical Scenario
An administrator needs to cross-reference VM performance data with security events to identify if CPU spikes coincide with suspicious logons. The relevant tables are Perf and SecurityEvent. He writes the following query:
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 90
| join kind=inner (
SecurityEvent
| where EventID == 4624
| where LogonType == 10
) on Computer
The query returns results, but the administrator notices that logon events from computers without CPU spikes are also appearing. What is the problem?
A) The join kind=inner should be join kind=leftouter, since inner discards rows from the left table without matches.
B) The Computer column may have values with inconsistent capitalization between tables, causing row duplication instead of incorrect filtering.
C) A temporal condition is missing in the join to restrict that logon events occur close to the time interval of CPU spikes, since the join on Computer combines all corresponding rows regardless of time.
D) The filter CounterValue > 90 should be inside the join block to be applied after the table union.
Question 5 — Multiple Choice
When creating a Log Search Alert in Azure Monitor, an administrator sets the evaluation period as 5 minutes and the frequency as 1 minute. The threshold is configured to trigger when the number of results is greater than 0. Which statement correctly describes the behavior of this alert?
A) The query will execute every 1 minute, analyzing data from the last 5 minutes; therefore, the same event can be detected in up to 5 consecutive executions.
B) The query will execute every 5 minutes, and the 1-minute interval only defines the minimum time between two consecutive triggers.
C) The 1-minute frequency is invalid when the evaluation period is 5 minutes; Azure Monitor requires the frequency to be equal to or greater than the period.
D) Each query execution analyzes only data generated since the last execution, avoiding any overlap of evaluation windows.
Answer Key and Explanations
Answer — Question 1
Answer: B
The countif function allows conditional counting within a single summarize operator, calculating both the total count and the subset of errors simultaneously. This is more correct and efficient than pre-filtering with where, as in alternative A, which discards rows without errors before summarize, making it impossible to calculate the real total of requests.
Alternative C attempts to use join to combine two distinct summaries, but the join key logic is incorrect and would produce an undesired Cartesian product. Alternative D uses where ResultCode == "500" or ResultCode != "500", which is a tautology with no real effect, and calculates the percentage with integer division (without * 100.0), resulting in zero for proportions less than 1.
The key point is that countif solves the problem in a single pass through the table, without modifying the analyzed dataset.
Answer — Question 2
Answer: B
Diagnostic logs in Azure don't automatically flow to a Log Analytics Workspace after resource association. It's necessary to explicitly configure the resource's Diagnostic Settings, selecting which log categories and metrics should be sent and to which destination. For Key Vault, the AuditEvent category is responsible for recording data plane operations like SecretGet, SecretSet and similar.
Alternative A is incorrect: Key Vault can record data in the AzureDiagnostics table depending on the collection mode; the KeyVaultLogs table exists in workspaces that use resource-specific mode, but the absence of results isn't explained by table choice in this scenario. Alternative C is false, as take doesn't interfere with filtering. Alternative D is wrong because typical ingestion delay is a few minutes, not 24 hours.
Answer — Question 3
Answer: False
Although Saved Searches allow saving and reusing queries in the Log Analytics Workspace, they don't function as a direct data source when configuring an Alert Rule in Azure Monitor. When creating a log-based alert, the KQL query must be explicitly entered in the alert configuration. The alert maintains its own copy of the query, independent of any saved query. There's no dynamic link between a Saved Search and an Alert Rule that automatically updates the alert query when the saved query is modified.
This is a common point of confusion: the functionality of saving queries serves the operational productivity of analysts, not alert automation.
Answer — Question 4
Answer: C
The join operator in KQL combines rows based on the specified key, which in this case is Computer. This means each row from the Perf table with CPU spike will be combined with all rows from SecurityEvent that have the same Computer value, regardless of when the logon occurred. A logon recorded days earlier will be included in the results.
For the cross-reference to be temporally meaningful, it's necessary to add a temporal proximity condition, usually using bin(TimeGenerated, Xm) in both tables before the join, or filtering with | where TimeGenerated between ... within the subquery.
Alternative A reverses the logic: inner discards rows without matches, which would be the desired behavior; switching to leftouter would worsen the problem. Alternative B describes a real data quality issue but doesn't explain why events from other times appear. Alternative D is technically incorrect: moving the filter inside the join doesn't change the temporal matching logic.
Answer — Question 5
Answer: A
In a Log Search Alert, the frequency defines how often the query is executed, and the evaluation period defines the time window analyzed in each execution. With 1-minute frequency and 5-minute window, the query runs every minute and always "looks back" 5 minutes. This creates intentional window overlap: an event occurring at minute 3 will be present in executions at minutes 3, 4, 5, 6, and 7.
Alternative B reverses the roles of frequency and period. Alternative C is wrong because Azure Monitor allows frequency to be less than the evaluation period; this is actually the recommended configuration for greater event sensitivity. Alternative D contradicts the documented behavior: windows overlap by design, and there's no "checkpoint" mechanism that records where the last execution stopped.