Monitor and maintain Azure resources practice questions

Answer: A) Storage insights, opened from the Insights section in Azure Monitor

Storage insights is a prebuilt Azure Monitor workbook experience that shows availability, latency and capacity across many storage accounts, with drill-down and no configuration. The other tools either need manual charts or queries, or don't report per-account storage metrics.

• ACorrect. Storage insights gives a unified, prebuilt workbook view of storage performance, capacity and availability across groups of storage accounts, with drill-down into individual accounts. It works with storage metrics that are collected by default, so nothing needs to be enabled.
• BIncorrect. Metrics explorer can chart storage metrics, but you have to choose the metrics and build each chart yourself, so it isn't a ready-made view across many accounts.
• CIncorrect. This needs diagnostic settings to send resource logs to a workspace and custom KQL queries, which is exactly the manual work the administrator wants to avoid.
• DIncorrect. Service Health reports Azure platform incidents, planned maintenance and advisories. It doesn't show capacity, latency or availability metrics for your individual storage accounts.

Answer: A) Azure Network Watcher

Azure Network Watcher provides flow logs (virtual network flow logs, which replace the retiring NSG flow logs) and diagnostic tools such as connection troubleshoot, IP flow verify, next hop and packet capture.

• ACorrect. Network Watcher provides virtual network flow logs for logging IP traffic. Its connection troubleshoot tool tests connectivity from a VM to another VM, an FQDN, a URI or an IP address.
• BIncorrect. Service Health reports Azure service incidents, planned maintenance and health advisories. It doesn't log VNet traffic or test connections.
• CIncorrect. Application Insights monitors application performance and telemetry. It doesn't capture VNet IP flows or run network connectivity tests.
• DIncorrect. Advisor gives best-practice recommendations for cost, security, reliability and performance. It doesn't provide network diagnostics.

Answer: A) Azure Backup to a Recovery Services vault, plus Azure Site Recovery replication to a secondary region

Azure Backup (Recovery Services vault) handles point-in-time restore, and Azure Site Recovery handles replication and failover to a secondary region. You need both.

• ACorrect. Azure Backup stores scheduled recovery points in a Recovery Services vault, and you can restore from any of them. Site Recovery continuously replicates the VM to a target region and lets you fail over there and fail back later.
• BIncorrect. A lock only blocks deletion and creates no recovery points. Zone-redundant storage replicates across availability zones within one region, so it doesn't let you fail over to another region.
• CIncorrect. Snapshots can give you restore points, but an availability set only spreads VMs across fault domains in one datacenter region. It gives you no cross-region failover.
• DIncorrect. Azure Backup meets the point-in-time restore requirement, but a ReadOnly lock only prevents changes. It doesn't replicate the VM or orchestrate failover to another region.

Answer: A) Set analytics retention to 30 days and total retention to 730 days, and use search jobs for older data

Log Analytics keeps data in two states: analytics retention for everyday queries and low-cost long-term retention for the rest of the total retention period. A short analytics period plus a 730-day total, with search jobs for older data, meets the audit need at the lowest cost.

• AAfter the 30-day analytics period, data moves to low-cost long-term retention for the rest of the 730-day total. Auditors can get it back with search jobs (or a restore) when they need it.
• BAnalytics retention beyond the included period costs extra. Keeping 2 years of data queryable is the expensive option, and day-to-day work only uses 30 days.
• CBasic tables have a 30-day total retention by default, so data older than 30 days would be deleted and the 2-year audit requirement fails. Basic also limits query features.
• DA daily cap only stops collection after a set volume each day. With 30-day retention, the audit history is still deleted long before 2 years.

Answer: A) Metrics

• APlatform metrics are lightweight numeric time-series collected at one-minute frequency by default and are the standard trigger for autoscale rules.
• BLogs are richer records queried with KQL but are ingested with more latency and aren't the native, low-latency autoscale trigger.
• CThe activity log records control-plane operations (who did what to a resource), not performance data.
• DResource Health reports whether a resource is reported healthy by the platform; it isn't a granular numeric metric stream.

Answer: A) A data collection rule with a custom XPath query

With the Azure Monitor Agent, a data collection rule decides what data is collected. A custom XPath query in its Windows Event Logs data source narrows collection to specific event IDs such as 4625.

• ACorrect. A data collection rule (DCR) defines what the Azure Monitor Agent collects and where it sends it. The Windows Event Logs data source supports custom XPath queries, such as Security!*[System[EventID=4625]], for event-level filtering.
• BIncorrect. Diagnostic settings route platform metrics, resource logs and the activity log. They don't collect Windows event logs from inside the guest OS, and they can't filter within a category.
• CIncorrect. A data collection endpoint provides the configuration and ingestion endpoints (for example, for Private Link). It doesn't define which events are collected; the DCR does that.
• DIncorrect. VM insights focuses on performance data and, optionally, dependency mapping. It isn't the mechanism for choosing specific Windows Security event IDs to collect.

Answer: A) An alert processing rule with a suppression action and a one-time schedule

Alert processing rules change alerts as they fire. A suppression rule scoped to a resource group with a scheduled window silences maintenance notifications without touching the alert rules themselves.

• AAn alert processing rule can be scoped to a resource group and set to suppress notifications on a one-time or recurring schedule. Alerts still fire and are visible, but their action groups aren't triggered. The alert rules themselves stay unchanged and keep working for resources outside the scope.
• BAny alert rule can use an action group, including rules for resources outside RG-App. Changing it would silence those notifications too, and someone has to remember to restore it by hand.
• CMaintenance configurations control when platform or guest updates are applied. They don't suppress Azure Monitor alert notifications.
• DA resource lock stops resources from being deleted or modified. It has no effect on whether alerts fire or notifications are sent.

Answer: A) Two rules, one scoped to each Azure region

Multi-resource metric alert rules can target many VMs at once, but only VMs in the same Azure region. Covering two regions takes at least two rules.

• ACorrect. A multi-resource metric alert rule can monitor resources of the same type only if they're in the same Azure region. For VMs, the scope can be all VMs in one region within a subscription, so you need one rule per region.
• BIncorrect. A metric alert rule can be scoped to a subscription, but only for VMs in one region. A single rule can't cover both East US and West Europe.
• CIncorrect. You don't need one rule per resource group, because a rule can cover all VMs in a region across the subscription or across several resource groups. A rule per resource group would also fail if a group contained VMs from both regions.
• DIncorrect. Multi-resource metric alerts exist to avoid one rule per VM. The rule evaluates each VM's time series separately and fires an alert per VM.

Answer: A) A metric alert rule on the CPU metric with the threshold and window, linked to an action group that contains the email and webhook actions

• AThe alert rule defines the condition; an action group is a reusable set of notifications/actions (email, SMS, push, webhook, Logic App, runbook) that the rule triggers when it fires.
• BDiagnostic settings route logs/metrics to destinations; they don't evaluate thresholds or send notifications.
• CA workspace stores data; without an alert rule nothing is evaluated or sent.
• DAzure Policy governs configuration compliance, not runtime metric alerting.

Answer: A) Set the table's analytics retention to 30 days and its total retention to 730 days

Log Analytics lets you set analytics retention and total retention per table. Any period beyond analytics retention is low-cost long-term retention that you can reach through search jobs.

• AThis per-table setting keeps 30 days of analytics retention. The remaining 700 days become low-cost long-term retention, which you can reach with search jobs when an audit needs the data.
• BThis keeps two years of data in the more expensive analytics state. It also changes every Analytics table that still uses the workspace default.
• CThis meets the duration but keeps all two years in analytics retention, which costs extra. It misses the lowest-cost requirement.
• DBy default, total retention equals analytics retention, so the table gets no long-term retention. Data would be removed after about 30 days and the two-year audit requirement would fail.