Technical Lab: Implement Virtual Network Flow Logs
Questions
Question 1 — Multiple Choice
Your team needs to monitor all IP traffic passing through a production virtual network, including traffic between subnets and traffic passing through resources like Load Balancers and VMs. The requirement is to capture this traffic at the VNet level, without having to configure monitoring individually on each NIC or subnet.
Which Azure resource directly meets this requirement?
A) NSG Flow Logs configured on each NSG associated with the VNet subnets.
B) Virtual Network Flow Logs enabled directly on the virtual network resource.
C) Azure Network Watcher Connection Monitor configured for the target VNet.
D) Gateway diagnostics configured on the VNet's Virtual Network Gateway.
Question 2 — Technical Scenario
An engineer executed the following command to enable VNet Flow Logs:
az network watcher flow-log create \
--name vnet-flowlog-prod \
--nsg "/subscriptions/.../resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/vnet-prod" \
--storage-account "/subscriptions/.../storageAccounts/stflowlogs" \
--enabled true \
--location eastus \
--resource-group rg-network
The command executes without errors, but after 30 minutes no logs appear in the storage account. Network Watcher is enabled in the eastus region.
What is the most likely cause of the missing logs?
A) The --nsg parameter does not accept a VNet resource ID; the correct parameter for VNet Flow Logs should be used.
B) VNet Flow Logs require the storage account to be in the same region as the VNet, and this condition was not verified in the command.
C) Network Watcher needs to be explicitly associated with the VNet before enabling the Flow Log.
D) The default retention interval is zero days, discarding logs immediately after writing.
Question 3 — Multiple Choice
When comparing VNet Flow Logs with NSG Flow Logs, which difference correctly represents the coverage scope of each resource?
| Characteristic | NSG Flow Logs | VNet Flow Logs |
|---|---|---|
| Capture scope | Per individual NSG | Entire virtual network |
| Traffic between subnets in the same VNet | Depends on NSG presence | Captured natively |
| Traffic to resources without associated NSG | Not captured | Captured |
Based on this comparison, which statement is correct?
A) NSG Flow Logs and VNet Flow Logs can be enabled simultaneously on the same VNet without generating duplicate records, as they use distinct capture pipelines.
B) VNet Flow Logs completely replace NSG Flow Logs in all scenarios, making them obsolete after enabling the former.
C) NSG Flow Logs capture traffic that was explicitly evaluated by an NSG rule, while VNet Flow Logs capture IP flow at the VNet layer regardless of NSG presence.
D) VNet Flow Logs only capture traffic entering or leaving the VNet via peering or gateway, excluding internal traffic between subnets.
Question 4 — True or False
Traffic Analytics, when integrated with VNet Flow Logs, processes raw flow data in real-time and makes it available in the Log Analytics Workspace with less than one minute latency after capture.
True or False?
Question 5 — Technical Scenario
An organization uses VNet Flow Logs with Traffic Analytics enabled. The security analyst needs to identify which external IP addresses are generating the highest volume of inbound traffic to VMs in a specific subnet over the last 7 days.
What is the correct approach to obtain this information?
A) Download the JSON files from the storage account and manually process the flowTuples fields for each time interval.
B) Query the NTANetAnalytics or AzureNetworkAnalytics_CL table in the Log Analytics Workspace using KQL, filtering by destination subnet and flow direction.
C) Use Azure Monitor Metrics for the target VNet, filtering by source IP address dimension.
D) Configure a Network Watcher Connection Monitor alert to retroactively capture the highest volume IPs.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
VNet Flow Logs are enabled directly on the virtual network resource and capture all IP traffic flowing within that VNet's scope, including traffic between subnets and traffic involving resources that don't have an associated NSG. This is the key distinction from the alternatives.
Alternative A represents the approach prior to VNet Flow Logs: it was necessary to configure NSG Flow Logs on each NSG individually, creating coverage gaps where no NSG existed. Alternative C monitors end-to-end connectivity, not comprehensive IP flows. Alternative D captures gateway metrics, not general VNet flows.
Answer Key — Question 2
Answer: A
The --nsg parameter in the az network watcher flow-log create command accepts the resource ID of an NSG, not a VNet. To create a VNet Flow Log, the target resource must be specified with the --target-resource-id parameter pointing to the VNet's resource ID. Incorrect parameter usage can result in execution without apparent error, but without the expected behavior.
Alternative B describes a real constraint of NSG Flow Logs and VNet Flow Logs regarding storage accounts, but it's not the primary cause here, as the command itself is structurally incorrect. Alternative C is false: having Network Watcher enabled in the region is already sufficient. Alternative D describes retention behavior that would affect already written logs, not prevent initial writing.
Answer Key — Question 3
Answer: C
NSG Flow Logs record flows that were processed by an NSG rule, meaning only traffic evaluated by an existing NSG is recorded. If a NIC or subnet doesn't have an associated NSG, that traffic doesn't appear in NSG Flow Logs. VNet Flow Logs operate at the virtual network layer and capture all IP flows regardless of NSG presence or absence.
Alternative A is incorrect: when both are enabled on the same VNet, duplicate records can occur for the same traffic, which should be considered in storage sizing and costs. Alternative B is incorrect because both resources coexist and have distinct use cases. Alternative D reverses the expected behavior: VNet Flow Logs cover internal traffic between subnets, which is exactly one of the cases not covered by NSG Flow Logs in topologies without internal NSGs.
Answer Key — Question 4
Answer: False
Traffic Analytics does not operate in real-time. It processes flow data at configurable intervals, with the minimum supported being 10 minutes and the default being 60 minutes. After the aggregation interval, data is sent to the Log Analytics Workspace. Therefore, the claim of sub-minute latency is incorrect.
This behavior is relevant for architecture decisions: Traffic Analytics is suitable for historical analysis and pattern identification, not real-time threat detection. For immediate response, other mechanisms like Microsoft Defender for Cloud or Azure Firewall with real-time logging are more appropriate.
Answer Key — Question 5
Answer: B
When Traffic Analytics is enabled, processed data is written to the Log Analytics Workspace in the NTANetAnalytics or AzureNetworkAnalytics_CL tables, depending on the schema version. The KQL language allows filtering by fields like destination subnet, flow direction (FlowDirection), and aggregating by byte or packet volume per source IP, directly answering the described need.
Alternative A is technically viable but operationally unfeasible for 7 days of data: raw JSON files are fragmented by time interval and would require extensive manual processing. Alternative C is incorrect because Azure Monitor Metrics for VNets don't expose dimensions by source IP address. Alternative D confuses Connection Monitor, which monitors prospective connectivity, with the retrospective flow analysis capability that belongs to Traffic Analytics.