Monitor and maintain Azure resources practice questions

Many platform metrics carry dimensions - name-value properties such as API name or response type. Metrics explorer can filter on a dimension (limit which values are included) or split on a dimension (draw a separate series per value).

Splitting by the API name dimension is exactly the feature that turns a single aggregated Transactions line into one line per operation type. A namespace only selects which set of metrics is available, an aggregation only changes how each time bucket is summarized into one number, and dynamic thresholds are an alerting concept that never appears on an explorer chart.

1. In metrics explorer, select the storage account, the Transactions metric, and an aggregation such as Sum.
2. Select Apply splitting and choose the API name dimension.
3. Optionally add a filter on the same dimension to limit the chart to specific operations of interest.

Exam tip: Use dimension splitting in metrics explorer to render one series per dimension value; use filtering to narrow which values are charted.

Metrics explorer aggregates raw metric samples into one value per time granularity interval using Avg, Min, Max, Sum, or Count. The chosen aggregation determines what the chart reveals or hides.

Max surfaces the peak sample in every interval, making it the right choice for spotting short-lived spikes. Avg smooths bursts into the background, Sum is nonsensical for a percentage utilization metric, and Count reflects the number of collected samples rather than their values.

1. Open metrics explorer for the VM and select the Percentage CPU metric.
2. Change the aggregation dropdown from Avg to Max.
3. Reduce the time granularity if needed so intervals are short enough to isolate individual spikes.

Exam tip: Pick the aggregation to match the question you are asking: Max exposes spikes, Avg shows typical load.

Resource logs describe operations performed within an Azure resource, and they are discarded unless a diagnostic setting routes them to a Log Analytics workspace, a storage account, or an event hub. A Log Analytics workspace is the only destination that supports interactive KQL analysis.

The scenario requires KQL queries and correlation with data already in a workspace, which only the Log Analytics destination provides; the diagnostic setting is the mechanism that starts collection. Storage-account archival stores the same events but offers no query engine, a metric alert monitors numbers rather than collecting events, and Azure Policy checks configuration compliance rather than routing operational logs.

1. Open the key vault and select Diagnostic settings under Monitoring.
2. Add a diagnostic setting and select the AuditEvent log category.
3. Choose Send to Log Analytics workspace, pick the central workspace, and save; then query the events with KQL.

Exam tip: Diagnostic settings turn on resource log collection, and Log Analytics is the destination to pick when you need KQL analysis.

Diagnostic settings offer three main destinations with distinct purposes: Log Analytics workspace for interactive KQL analysis, storage account for cheap long-term archival, and event hub for streaming to external systems such as a third-party SIEM.

Seven-year retention of logs that are rarely read is the textbook archival case, and the storage account destination is priced for exactly that, especially with cool or archive tiers. A workspace charges for ingestion and analytics capability the scenario never uses, an event hub retains data only briefly and exists to stream rather than store, and Application Insights is not a diagnostic destination at all.

1. Create or identify a storage account for log archival and consider cool or archive tier lifecycle rules.
2. On each firewall, add a diagnostic setting selecting the required log categories.
3. Choose Archive to a storage account as the destination and configure lifecycle management to meet the seven-year requirement.

Exam tip: For long-term, rarely accessed log retention, archive to a storage account; reserve Log Analytics for data you actually query.

The event hub destination of a diagnostic setting exists to stream monitoring data out of Azure to external consumers - typically third-party SIEM and analytics platforms - with low latency.

The requirement is a continuous near-real-time feed to an external system, which is precisely the event hub integration pattern. A Log Analytics workspace keeps data inside Azure for KQL analysis rather than pushing it out, a storage account delivers batched blobs that a SIEM must poll, and an action group is an alert notification mechanism, not a log transport.

1. Create an Event Hubs namespace and an event hub in the same region as the resources.
2. Add a diagnostic setting on each production resource selecting the required log categories.
3. Choose Stream to an event hub as the destination, then configure the SIEM's Azure connector to consume from that hub.

Exam tip: Stream to an event hub when monitoring data must leave Azure in near real time, such as to a third-party SIEM.

The activity log is the subscription-level record of control-plane (management) operations - create, update, delete, and role changes - captured automatically with 90 days of retention. Resource logs are data-plane records that exist only when a diagnostic setting collects them.

Deleting an NSG is a control-plane write, so it appears in the activity log with the caller's identity and timestamp, and the two-day-old event is well within the 90-day window. Resource logs would not help even if configured because deletion is not a data-plane event, metrics carry no identity or operation records, and NSG flow logs describe traffic, not administrative actions.

1. Open Monitor in the Azure portal and select Activity log.
2. Filter by the resource group or resource type Network security groups and set the time range to the last week.
3. Locate the Delete Network Security Group operation and inspect the Event initiated by field for the user identity.

Exam tip: Who did what to a resource is always the activity log; what happened inside a resource is resource logs and needs a diagnostic setting.