Troubleshooting Lab: Implement virtual network flow logs
Diagnostic Scenarios
Scenario 1 — Root Cause
A security team configured VNet flow logs to monitor traffic on a production VNet called vnet-prod-eastus. The resource was enabled three days ago via the Azure Portal. The team expects to view the logs in the Log Analytics workspace law-security-prod, but when executing KQL queries, no data is returned for the period since activation.
The administrator checks the configurations and obtains the following output via CLI:
az network watcher flow-log show \
--location eastus \
--name flowlog-vnet-prod
{
"enabled": true,
"flowAnalyticsConfiguration": {
"networkWatcherFlowAnalyticsConfiguration": {
"enabled": true,
"trafficAnalyticsInterval": 60,
"workspaceId": "law-security-prod",
"workspaceRegion": "eastus",
"workspaceResourceId": "/subscriptions/.../workspaces/law-security-prod"
}
},
"retentionPolicy": {
"days": 30,
"enabled": true
},
"storageId": "/subscriptions/.../storageAccounts/stflowlogsprod",
"targetResourceId": "/subscriptions/.../virtualNetworks/vnet-prod-eastus",
"version": 2
}
The administrator confirms that the storage account stflowlogsprod is accessible and that the workspace law-security-prod is active. Network Watcher is enabled in the eastus region. The team also mentions that the workspace name was changed from law-monitor-prod to law-security-prod five days ago, two days before flow logs activation.
When checking the workspace in the Portal, the administrator observes that the Traffic Analytics solution appears as installed and active. A direct query to the NTANetAnalytics table returns zero rows.
What is the root cause of the absence of data in the workspace?
A) Traffic Analytics is configured with a 60-minute interval, which excessively delays ingestion and the data has not yet appeared in the workspace.
B) The workspaceId field in the flow log configuration contains the workspace name instead of the workspace GUID, causing silent failure in sending to Log Analytics.
C) VNet flow log version 2 is not compatible with Traffic Analytics and requires downgrade to version 1 to send data to Log Analytics.
D) The storage account stflowlogsprod is in the same region as the workspace, which prevents Traffic Analytics from processing the collected data.
Scenario 2 — Collateral Impact
A company's operations team decided to reduce storage costs and changed the retention policy of VNet flow logs from 90 days to 7 days in the storage account stflowlogs-corp. The change was successfully applied and confirmed via Portal. Network traffic continues to be logged normally and log files continue to arrive in the storage container.
What secondary consequence can this change cause?
A) Log files older than 7 days will be automatically deleted from the storage account, making forensic investigations of incidents that occurred before this period impossible without external backup.
B) Traffic Analytics will stop processing new data because it depends on a minimum retention buffer of 30 days to calculate traffic trends.
C) Network Watcher will automatically disable the flow log after detecting that the configured retention is below the required minimum of 30 days.
D) The retention reduction will cause failure in ingesting new logs into the Log Analytics workspace because the connector between storage and Log Analytics requires a minimum retention of 30 days to function.
Scenario 3 — Action Decision
A company's security team identified the root cause of a problem: the VNet flow log of VNet vnet-hr-westeurope is sending data to the wrong storage account, stflowlogs-dev, instead of stflowlogs-prod. This occurs because a provisioning script applied the incorrect configuration during the last deployment.
The environment has the following restrictions:
- VNet vnet-hr-westeurope processes HR data and is in active production
- Flow log data from the last 14 days is stored in stflowlogs-dev, which is accessible
- The company's security policy requires that production data never remain in development storage accounts for more than 24 hours
- A compliance audit begins in 2 hours and requires that flow logs be correctly configured and accessible in the production environment
- Changing the configuration of an existing flow log does not interrupt ongoing data collection
What is the correct action to take now?
A) Disable the flow log, wait for audit completion, and recreate the configuration pointing to stflowlogs-prod after the audit.
B) Immediately update the flow log configuration to point to stflowlogs-prod and start the process of migrating existing data from stflowlogs-dev to stflowlogs-prod before the audit.
C) Maintain the current configuration during the audit to avoid risking interruption, and correct the pointer to stflowlogs-prod after audit completion.
D) Delete the current flow log and recreate a new one pointing to stflowlogs-prod, accepting the loss of 14 days of historical data as necessary for immediate compliance.
Scenario 4 — Root Cause
An administrator enabled VNet flow logs for VNet vnet-spoke-centralus and configured sending to storage account stflowlogs-central. After 48 hours, they check the destination container and find files being written normally. However, when trying to access the files via Azure Portal Storage Explorer, they receive the following error:
AuthorizationPermissionMismatch
This request is not authorized to perform this operation using this permission.
RequestId: 8fa2c3d1-0011-004f-6a2b-9c3def000000
The administrator confirms that their account has the Storage Blob Data Reader role assigned directly to the storage account. They also confirm that files exist in the insights-logs-flowlogflowevent container and that the container has public access disabled.
Additional information: the storage account uses Azure Data Lake Storage Gen2 with hierarchical namespace enabled. The administrator accessed other standard blob storage accounts without problems with the same role assigned. The storage account was created 6 months ago and flow logs were enabled 2 days ago.
What is the root cause of the authorization error?
A) The Storage Blob Data Reader role is not sufficient to access data in accounts with hierarchical namespace; execute permission on parent directories via ACL is also required.
B) Public access disabled on the container prevents any access via Storage Explorer, regardless of roles assigned to the user.
C) The Storage Blob Data Reader role does not have permission to access the insights-logs-flowlogflowevent container because it is automatically created by the system and requires the Storage Account Contributor role for reading.
D) The error occurs because flow log files are quarantined for 72 hours after creation before becoming accessible for reading by non-privileged users.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The workspaceId field in the Traffic Analytics configuration must contain the GUID of the Log Analytics workspace, not the readable name. The CLI output shows "workspaceId": "law-security-prod", which is a name, not a unique identifier. When this field receives a name instead of the GUID, the configuration is accepted without explicit error, but data sending fails silently because the service cannot resolve the correct destination.
The critical clue in the statement is that the workspace was recently renamed. In a correct workflow, the workspace GUID does not change with renaming, but the name does. If the configuration had been copied from a previous environment using the old name, it would be invalid. The CLI output confirms the use of the name in place of the GUID.
The irrelevant information is the workspace renaming from law-monitor-prod to law-security-prod. It was included to lead the reader to suspect name incompatibility, when the real problem is the type of identifier used in the field.
The most dangerous distractor is alternative A. The 60-minute interval is valid and expected for Traffic Analytics, but three days of waiting completely eliminates this hypothesis. Acting based on it would lead the administrator to wait indefinitely without correcting the actual configuration.
Answer Key — Scenario 2
Answer: A
Reducing retention to 7 days activates the storage account lifecycle policy to automatically delete blobs older than 7 days. Since flow logs are stored as files in blob storage, any data from before this period will be removed without possibility of direct recovery. This compromises forensic investigations of incidents that occurred before the 7-day window.
Alternatives B, C, and D represent behaviors that do not exist in the platform. Traffic Analytics has no minimum retention requirement to process new data. Network Watcher does not automatically disable flow logs based on configured retention. And the connector between storage and Log Analytics has no dependency on storage retention policy to function.
The real collateral impact is operational and compliance-related: security investigations that depend on historical logs become silently compromised, without any system alert.
Answer Key — Scenario 3
Answer: B
The statement establishes two simultaneous restrictions that need to be satisfied: the security policy requires production data to leave the development account in less than 24 hours, and the audit begins in 2 hours. Alternative B is the only one that satisfies both: immediately corrects the pointer (respecting the restriction of not interrupting collection) and starts migrating existing data to the correct account before the audit.
Alternative A disables the flow log, which unnecessarily interrupts collection and violates continuity during the audit.
Alternative C is the most dangerous distractor: it keeps production data in a development environment during the audit, directly violating the security policy and exposing the company to documented non-compliance.
Alternative D sacrifices 14 days of history unnecessarily, since data migration is viable and the statement mentions no technical impediment to it.
Answer Key — Scenario 4
Answer: A
In storage accounts with Azure Data Lake Storage Gen2 and hierarchical namespace enabled, the access control model combines RBAC with ACLs (Access Control Lists) at the directory and file level. The Storage Blob Data Reader role grants read permission at the data plane level via RBAC, but in accounts with hierarchical namespace, access to a file within a directory structure also requires execute permission on each parent directory in the hierarchy. Without this execute ACL on parent directories, file access is denied with the AuthorizationPermissionMismatch error.
The critical clue is that the administrator accesses other standard storage accounts without problems with the same role. This eliminates the hypothesis of generically insufficient role and points to a specific difference in the account, which is the hierarchical namespace.
The irrelevant information is that the account was created 6 months ago. This data induces thinking about some legacy configuration, but the cause is in the ADLS Gen2 permissions model, independent of the account's age.
The most dangerous distractor is alternative C. Assigning Storage Account Contributor to resolve the problem would be a serious security error: this role grants permissions at the management plane, far beyond necessary, and does not resolve the ACL problem in the hierarchical namespace directories.
Troubleshooting Tree: Implement virtual network flow logs
Color legend:
- Dark blue: initial symptom, investigation entry point
- Blue: objective diagnostic question with verifiable answer
- Red: identified and confirmed cause
- Green: recommended action or resolution to execute
- Orange: validation or intermediate verification before proceeding
How to navigate the tree when facing a real problem: always start from the root node, which represents the observed symptom. Answer each blue question based on what is directly verifiable in the environment, whether via Azure Portal, CLI, or KQL query. Follow the branch corresponding to your answer. When reaching an orange node, execute the described verification before continuing. When reaching a red node, the cause is confirmed. When reaching a green node, execute the indicated action and return to the nearest validation node to confirm that the problem has been resolved.