4 of the 14 questions we have for this objective, shown with the answer and the reasoning.
Monitor resources in Azure
Cobalt Systems has a virtual network named vnet-core with two subnets. A web server named vm-web (10.1.1.10) in subnet-web cannot connect to a database server named vm-db (10.1.2.10) on TCP port 1433 in subnet-db. Network security groups are attached to both subnets and to both network interfaces. Both virtual machines are in the same region and the routing has been verified as correct. The administrator needs to identify the exact security rule that is denying the traffic.
Which Network Watcher tool should the administrator use?
- AIP flow verify, run against vm-db with direction Inbound, protocol TCP, remote address 10.1.1.10, and local port 1433.IP flow verify evaluates the effective security rules for a specific flow on a virtual machine and returns the name of the rule that allows or denies it.
- BNext hop, run against vm-web with destination address 10.1.2.10.Next hop reports the routing decision for a destination; the scenario states routing is already verified.
- CPacket capture on vm-db filtered on port 1433.A packet capture shows whether packets arrive but does not identify which security rule dropped them.
- DEffective routes for the network interface of vm-web.Effective routes is a routing diagnostic and does not evaluate network security group rules.
Why: Network Watcher provides separate diagnostics for routing and for security filtering. IP flow verify is the security-rule tool: you specify a virtual machine, a direction, a protocol, and the local and remote addresses and ports, and it evaluates every network security group that applies to that machine's interface and subnet, returning the rule that made the decision. If the inbound check on vm-db returns Allow, repeat the check on vm-web with direction Outbound, because the deny may be in the source machine's outbound rules. Because the question asks for the exact denying rule and routing is already ruled out, the routing tools (next hop, effective routes) and packet capture are the wrong instruments.
Monitor resources in Azure
Larkspur Media has 25 storage accounts spread across three resource groups in a subscription named Sub-Media. A support engineer wants a single view that compares transaction counts, end-to-end latency, and availability for all 25 accounts over the last 24 hours. No diagnostic settings have been configured on any of the accounts, and the engineer must not create any new resources.
What should the engineer use?
- AStorage insights, opened from Azure Monitor by selecting Storage accounts under Insights.Storage insights is a built-in workbook that visualizes platform metrics for every storage account in the selected subscriptions with no configuration required.
- BA Log Analytics workspace with a KQL query on the StorageBlobLogs table.StorageBlobLogs is only populated after a diagnostic setting is created on each account and a workspace exists, which the scenario forbids.
- CAzure Storage Explorer connected to the subscription.Storage Explorer is a data management tool for browsing containers, shares, and queues; it does not chart performance metrics.
- DThe Activity log filtered by the Microsoft.Storage resource provider.The Activity log shows control-plane operations on the accounts, not transaction latency or availability.
Why: Azure Monitor Insights are curated, pre-built monitoring experiences for specific resource types. Storage insights aggregates the platform metrics that every storage account emits automatically (Transactions, SuccessE2ELatency, Availability, and capacity) into a subscription-wide view and lets you drill into a single account. Because it relies on platform metrics, it works with zero configuration, which is the constraint that decides this question.
Monitor resources in Azure
Northgate Travel runs a booking application on a virtual machine named vm-book01 in the North Europe region. The application calls a partner payment API at https://pay.example-partner.net. The partner occasionally reports timeouts. Northgate wants to measure reachability and round-trip latency from vm-book01 to the API every 30 seconds, keep the results for trend analysis in a Log Analytics workspace, and raise an alert when the failure percentage exceeds 10 percent.
What should you configure?
- AA connection monitor in Network Watcher with vm-book01 as the source, the partner URL as the destination, an HTTP test configuration with a 30-second frequency, and the workspace as the output.Connection monitor provides continuous, scheduled connectivity and latency tests from Azure virtual machines to endpoints, stores results in Log Analytics, and supports alerting on failure thresholds.
- BConnection troubleshoot in Network Watcher from vm-book01 to the partner URL on port 443.Connection troubleshoot is a one-time, point-in-time check; it does not run on a schedule or retain history.
- CIP flow verify on vm-book01 with direction Outbound to the partner's public IP address on port 443.IP flow verify evaluates network security group rules for a hypothetical flow; it does not send traffic or measure latency.
- DAn availability test in Application Insights that pings the partner URL from Azure test locations.Availability tests run from Microsoft test locations, not from vm-book01, so they do not measure the path the application actually uses.
Why: Connection monitor is the Network Watcher capability for ongoing, agent-based connectivity monitoring. It installs the Network Watcher agent extension on the source virtual machine, runs TCP, ICMP, or HTTP tests at a configurable interval, and writes results to a Log Analytics workspace where they can be charted and used in alert rules. The decisive requirements are continuous measurement from a specific source machine with retained history and alerting; the point-in-time diagnostics and externally sourced availability tests fail one or more of those.
Monitor resources in Azure
Tidewater Shipping sends heartbeat data from 120 virtual machines to a Log Analytics workspace named law-tw-ops. You create a log search alert rule with the following query, evaluated every 5 minutes over a 15-minute window, with the measure set to the number of table rows and the threshold set to greater than 0:
Heartbeat
| summarize LastCall = max(TimeGenerated) by Computer
| where LastCall < ago(10m)
During a test, three machines were stopped at the same time, but the operations team received only a single alert that did not identify any of the machines. The team requires one alert per unresponsive machine that includes the machine name.
What should you change in the alert rule?
- AEnable Split by dimensions and select the Computer column.Splitting by the Computer dimension causes the rule to evaluate the condition per unique value and fire a separate alert, with the dimension value in the payload, for each machine.
- BChange the evaluation frequency to 1 minute.Evaluating more often changes how quickly the single alert fires, not how many alerts are produced.
- CCreate a separate log search alert rule for each of the 120 virtual machines with a where clause on Computer.This produces per-machine alerts but requires 120 rules to maintain and ignores the built-in dimension feature.
- DChange the measure from table rows to metric measurement on the LastCall column.LastCall is a datetime, not a numeric value, and changing the measure does not by itself split the result into one alert per computer.
Why: By default a log search alert rule evaluates the whole result set once and fires one alert whenever the row count crosses the threshold. The Split by dimensions setting tells the rule to group the results by one or more columns and to treat each group as its own monitored entity, so each unresponsive computer raises its own alert and the computer name is included in the alert context. Frequency and window affect timing, not cardinality, and per-machine rules are the maintenance trap.