Design identity, governance, and monitoring solutions practice questions

Azure Log Analytics workspace with Microsoft Entra ID diagnostic settings

Why it fails: While you can configure Microsoft Entra ID diagnostic settings for 'SignInLogs' and 'AuditLogs' in each tenant to stream into a single shared Log Analytics workspace, that workspace only provides a data store and a KQL query interface. It lacks Sentinel's integrated security analytics features: no built-in analytics rules, no UEBA, no automated incident management, and no native multi-tenant correlation. You would have to manually build and maintain every alert and investigation query, and there is no central overview of health or state across tenants beyond raw log aggregation—so it is not an adequate monitoring solution on its own.

Microsoft Entra ID Reports and Monitoring

Why it fails: Microsoft Entra ID Reports & Monitoring (the built-in sign-in logs, audit logs, and provisioning logs in the Entra admin center) show logging for exactly one tenant at a time; there is no native cross-tenant aggregation or comparison. These reports also rely on the diagnostics/activity blade that offers limited filtering, exports, and retention periods, with no custom detection rules, scheduled queries, or cross-data-source correlation. To monitor sign-ins across several tenants, you would have to navigate into each tenant separately and manually piece together trends, which is not a scalable or analysis-ready approach.

Azure Monitor Workbooks

Why it fails: Azure Monitor Workbooks are interactive reporting canvases that visualize data already stored in sources like a Log Analytics workspace, Azure Data Explorer, or Application Insights, but they do not ingest or collect data themselves. A workbook cannot directly connect to multiple Microsoft Entra ID tenants or pull sign-in logs on its own; it depends on an underlying repository where logs must first be aggregated. Even if you pointed a workbook at a shared workspace, you would still need Sentinel's ingestion, analytics, and alerting to make that data usable for multi-tenant sign-in monitoring—so workbooks are merely a visualization component, not a monitoring solution.

Azure Policy with built-in policy to enforce MFA and Azure Activity Log to monitor changes.

Why it fails: Azure Policy can audit whether MFA is enabled on accounts, but it cannot enforce MFA during sign-in. It is not the correct tool for requiring MFA at authentication time. Activity Log can capture policy changes, but the enforcement method is wrong.

Microsoft Entra ID Identity Protection to enforce MFA and Azure Sentinel for monitoring.

Why it fails: Microsoft Entra ID Identity Protection primarily enforces multi-factor authentication (MFA) based on detected sign-in or user risks, such as impossible travel or unfamiliar locations. It is not the direct mechanism for a blanket, unconditional MFA requirement for all administrators accessing the Azure portal, which is best achieved using Microsoft Entra ID Conditional Access policies. This option is tempting as Identity Protection *can* trigger MFA, and would be correct if the scenario demanded risk-based MFA enforcement. Azure Sentinel is suitable for monitoring policy changes.

Azure Policy to assign built-in policy 'MFA should be enabled on accounts with write permissions' and Azure Security Center for monitoring.

Why it fails: This policy audits whether MFA is enabled, but again does not enforce MFA during authentication. Azure Security Center (now Defender for Cloud) focuses on security posture and workload protection, not on monitoring identity policy changes.

B

Why it fails: Azure Service Health and Azure Advisor are not data-collection and analytics platforms. Service Health only reports on Azure service incidents, planned maintenance, and health advisories; Advisor provides personalized best-practice recommendations for workloads based on configuration, not live performance. Neither ingests VM performance counters, nor do they allow custom log queries, dashboard authoring, or alert rules based on CPU and memory metrics, so they cannot satisfy the customer's operational monitoring requirements.

C

Why it fails: Application Insights is part of Azure Monitor, but it is purpose-built for application-level telemetry—requests, dependencies, and exceptions—not for collecting guest-OS performance counters from VMs. Its SDK and auto-instrumentation monitor the behavior of applications, not the underlying server (CPU, memory, disk, or network). Even when used with virtual machines, it cannot replace Log Analytics for centralized OS performance collection and long-term retention of infrastructure metrics.

D

Why it fails: Azure Sentinel (now Microsoft Sentinel) is a cloud-native SIEM/SOAR solution focused on security information and event management. It ingests security logs like Azure Activity, Microsoft Entra ID, and firewall/IDS data, and is designed for threat detection, incident response, and hunting—not for general operational performance monitoring of server health. While it could technically store Windows event logs, it does not serve as the primary platform for custom performance dashboards and alerting based on CPU/memory counters, making it an incorrect choice for this scenario.

Use Microsoft Entra ID Identity Protection to detect risky activations and trigger a Logic App

Why it fails: Microsoft Entra ID Identity Protection analyzes user and sign-in risk—such as leaked credentials, anonymous IP addresses, or impossible travel—and does not consume PIM role-activation events as a first-class signal. A PIM activation that is approved out-of-hours is not a 'risky' sign-in, so Identity Protection would have nothing to flag. Moreover, triggering a Logic App from Identity Protection would require a risk detection to emit a signal, but there is no built-in risk detection type for role activation timing; unsupported workarounds would merely poll audit logs, duplicating what Log Analytics does natively.

Enable Microsoft Entra ID diagnostic settings to send logs to Event Hubs and process with Azure Stream Analytics

Why it fails: This option fails because Azure Stream Analytics is designed for real-time data processing and analytics, not for directly triggering email alerts based on specific log events and time conditions. While it can process logs from Event Hubs, it lacks the native alerting capabilities required to send an email to the security team upon out-of-hours role activation. This solution is tempting as it offers real-time log ingestion and processing. It would be appropriate if the goal was complex real-time data transformation, aggregation, or enrichment of Microsoft Entra ID logs before storage or further custom analysis, rather than immediate, condition-based alerting.

Use Azure Sentinel with a built-in connector for PIM and create a scheduled analytics rule

Why it fails: Using Azure Sentinel with a scheduled analytics rule fails to provide the immediate, real-time email notification required "whenever" a PIM activation occurs outside business hours, due to the inherent latency of scheduled queries. While Sentinel is excellent for collecting Microsoft Entra ID PIM logs for quarterly audits and correlating security events across an estate, its strength lies in broader threat detection and long-term analysis, not instant, event-driven alerts for specific triggers.

Microsoft Entra ID Privileged Identity Management (PIM)

Why it fails: Privileged Identity Management (PIM) is incorrect because it is scoped exclusively to Microsoft Entra ID roles, Azure resource roles, and other privileged roles like Global Administrator; it enables time-bound, just-in-time activation of these administrative roles. It does not handle requests for access to standard business applications or Microsoft 365 groups, nor does it provide access packages with approval and review cycles for regular employees. Therefore, it cannot automate the two-step governance process described in the question.

Microsoft Entra ID Conditional Access

Why it fails: Conditional Access is a policy engine that evaluates real-time signals such as user location, device compliance, and risk level to allow or block access to applications; it does not provide any mechanism for users to request access or for approvers to review requests. It operates after a user already has an account and attempts to sign in, enforcing session-level controls rather than managing access lifecycle. Thus, it is irrelevant for automating approvals and recurring access reviews.

Microsoft Entra ID Self-Service Group Management

Why it fails: Self-Service Group Management enables users to create their own Microsoft 365 groups, security groups, or distribution lists and manage membership themselves, but it lacks the governance features needed here: no built-in approval workflow for membership requests, no expiration policies, and no recurring access review scheduling. When enabled, it simply lets a group owner approve or deny requests without any time limits or periodic attestation. Consequently, it cannot automate the two-step access request and review process required by the company.

Privileged Identity Management (PIM)

Why it fails: PIM focuses on just-in-time and time-bound access to privileged roles. It does not detect risks like leaked credentials or impossible travel, and is not designed for threat reporting.

Microsoft Entra ID Connect Health

Why it fails: Microsoft Entra ID Connect Health monitors the health of on-premises identity infrastructure (AD FS, AD DS, etc.). It does not detect cloud-based sign-in risks or generate risk reports.

Microsoft Entra ID Audit Logs

Why it fails: Audit logs record user and admin activities but do not automatically analyze or detect risks. They can be exported but lack built-in risk detection and reporting features.

Microsoft Entra ID B2C

Why it fails: Microsoft Entra ID B2C is a customer identity and access management (CIAM) service that manages identities in a separate, isolated directory designed for external consumers (e.g., social or local accounts). It does not federate with an existing Microsoft Entra ID tenant, so a partner's users cannot use their corporate credentials for SSO without a custom SAML/WS-Fed identity provider configuration, which is not B2C's intended role for partner access.

Microsoft Entra ID Application Proxy

Why it fails: Microsoft Entra ID Application Proxy is a reverse proxy that publishes on-premises web applications to remote users through the Microsoft Entra ID cloud service. It provides secure remote access to legacy internal apps, not SSO for external partner applications; it does not handle SAML or OIDC federation between an external partner's identity provider and Microsoft Entra ID, and it cannot configure the sign-on or branding for a partner-facing SaaS application.

Microsoft Entra ID Conditional Access

Why it fails: Microsoft Entra ID Conditional Access is a policy engine that evaluates signals like user, device, location, and risk during an active sign-in event to grant or block access or require MFA. It does not create a federation trust, configure SAML assertions, or expose an application with SSO endpoints; it only enforces access policies on top of an already configured SSO solution, so it cannot by itself enable partner application single sign-on.

Microsoft Entra Domain Services.

Why it fails: Microsoft Entra Domain Services provides a managed domain with Kerberos/NTLM authentication, LDAP, and Group Policy for legacy applications that cannot use modern cloud APIs. It is a domain-join and identity service for virtual machines, not a mechanism for managing Azure RBAC or Entra ID role elevation. Since it does not support user-initiated, time-bound activation of administrative privileges, it is incorrect for just-in-time elevation.

Azure Policy guest configuration.

Why it fails: Azure Policy guest configuration is an Azure Policy feature that audits and remediates settings inside virtual machines, such as OS security baselines, installed applications, and local user account configuration. It applies to the VM's operating system, not to an administrator's role in Entra ID or Azure RBAC, and it has no workflow for activating or approving temporary elevated access. Therefore, it cannot deliver just-in-time elevation and is clearly wrong.

Step 1: Create health probe, Step 2: Create backend pool, Step 3: Create rule, Step 4: Associate public IP, Step 5: Test

Why it fails: This order is incorrect because a health probe must reference the backend pool's endpoints to check their availability. If you attempt to create the probe first, no backend pool exists to attach it to, so the configuration cannot be completed. In the Azure portal and API, the probe resource depends on a valid pool of target instances, so the pool must be defined as the first step.

Step 1: Create rule, Step 2: Create backend pool, Step 3: Create health probe, Step 4: Associate public IP, Step 5: Test

Why it fails: Creating the load balancer rule before the backend pool and health probe violates the dependency chain: the rule is the object that binds the frontend IP, listener port, and backend pool together, and it must also specify a health probe to determine which backend hosts are healthy. Without the pool and probe resources having been created already, the rule has no target group or liveness signal to reference. Thus, the rule must be created only after the backend pool and health probe exist.

Step 1: Associate public IP, Step 2: Create backend pool, Step 3: Create health probe, Step 4: Create rule, Step 5: Test

Why it fails: Associating a public IP first is technically possible, but it is not the first step in the sequence this question asks for; the frontend IP configuration is merely an input to the rule, not a prerequisite for defining the backend pool or health probe. In the Azure portal workflow, the rule creation step is what actually links the frontend IP to the backend pool, so placing the IP association before the rule makes the workflow misleading. The correct order places the public IP association immediately before testing, after the rule has wired the frontend to the backend.

Use Application Insights continuous export to send all telemetry to a storage account.

Why it fails: Application Insights continuous export sends every telemetry item to Azure Storage with no filtering, sampling, or conditional logic. This results in massive, noisy data sets that are expensive to store and difficult to query during incident response, and it does not specifically trigger extra detailed diagnostics when degradation begins. It also duplicates storage if the same telemetry is sent to Log Analytics, creating unnecessary cost and complexity.

Configure a Log Analytics workspace to collect all performance counters and IIS logs.

Why it fails: Collecting all performance counters and IIS logs continuously would bloat the Log Analytics workspace, driving up ingestion and retention costs, and produce excessive noise that obscures the actual root cause during an incident. This blanket approach lacks the conditional intelligence to start or stop based on application health, so you are either over-collecting during normal operation or missing application-level details like exceptions, dependency calls, and user logs. It also ignores the application's business signals, making it insufficient for end-to-end monitoring of a global e-commerce solution.

Enable Azure Metrics for the application to monitor performance in real-time.

Why it fails: Azure Metrics collects predefined, aggregated numeric values at fixed intervals (typically one minute) and retains them for a limited period, so they can alert you to a problem but cannot reveal the underlying exception, SQL query, user session, or dependency that caused the degradation. Metrics lack the detailed diagnostic payloads and custom dimensions needed for root-cause analysis, and they are not a replacement for log-based troubleshooting. They are best used as a trigger to activate deeper logging rather than as the sole monitoring data source.

Conditional Access policies to block access for inactive users

Why it fails: Conditional Access policies are real-time authentication controls that can block sign-in attempts based on risk, location, or device compliance, but they do not revoke already-issued tokens or remove persisted entitlements such as group memberships, app roles, or licenses. An inactive user who never attempts to sign in will never trigger the policy, and even when a user is blocked, their underlying access objects remain intact in Microsoft Entra ID. Consequently, Conditional Access is a preventive security control, not an identity-lifecycle remediation mechanism for stale or inactive access.

Azure Automation runbooks to delete user accounts upon termination

Why it fails: Azure Automation runbooks can delete user objects programmatically via the Microsoft Graph API, yet a hard delete permanently removes the account, along with all group memberships, access history, and compliance metadata, making recovery or post-termination investigation nearly impossible. Building a robust deprovisioning workflow requires custom script logic, error handling, approval gates, and backup mechanisms, which is fragile and operationally heavy for a governance solution. A governance solution should instead use a staged, reversible process like an access review with a grace period, not an irreversible account deletion.

Microsoft Entra Privileged Identity Management (PIM) to require approval for access assignments

Why it fails: Microsoft Entra PIM is designed specifically to manage just-in-time, time-bound, and approval-based activation for highly privileged Microsoft Entra ID roles, Azure resource roles, and eligible privileged groups—not to govern ordinary application access or remove inactive users. Even when approval is required in PIM, it only gates the activation of an eligible role; once a role is activated, it persists for the assigned duration, and PIM does not automatically review or remove existing standard-access assignments. Therefore, PIM addresses privilege-escalation risk, not the lifecycle of general application entitlements.

The policy should be assigned at the subscription level to audit custom role creation.

Why it fails: Assignment scope is not the root cause. The policy can be assigned at the subscription level, a management group, or even a resource group, and it would still fail to detect custom role creation because the policy's 'if' condition is fundamentally misconfigured. The condition uses 'Microsoft.Authorization/roleDefinitions' with a 'type' check that matches all role definitions, not specifically custom ones, and the audit effect will never fire for the creation event as intended. Moving the assignment to a different scope would not correct the logical flaw in the policy definition.

The policy definition is a custom policy, and custom policies cannot audit RBAC role definitions.

Why it fails: This statement is false because Azure Policy custom definitions can absolutely target RBAC role definitions. The policy mode 'All' is specifically intended to evaluate all resource types, including 'Microsoft.Authorization/roleDefinitions', and custom policies in that mode are fully supported by Azure Policy. The failure is not due to the policy being custom, but due to the condition inside the definition not accurately representing the desired audit scenario.

The policy mode is set to 'All', which does not include RBAC role definitions.

Why it fails: The policy mode 'All' does not exclude RBAC role definitions; in fact, mode 'All' is the only mode that supports evaluating Microsoft.Authorization/roleDefinitions, whereas mode 'Indexed' would omit them because they are not indexable resources. The problem is not the mode—it is the condition logic. The 'All' mode is correctly set, but the condition checks for 'Microsoft.Authorization/roleDefinitions' without a custom-role discriminator, so the policy evaluates but never triggers correctly for creation of custom roles.

Configure a sign-in risk policy in Microsoft Entra ID Protection to block access for high risk

Why it fails: The Microsoft Entra ID Protection sign-in risk policy can block high-risk sign-ins, but it operates purely as a preventive control at the time of sign-in and provides no self-service remediation workflow for the user. When access is blocked, an administrator must manually intervene or the user must attempt to sign in again under a different context, which fails the requirement for automated, user-driven recovery. It also lacks the ability to enforce a password change or MFA enrollment during the blocked session, leaving the user without a secure path back to productivity.

Use the Identity Protection dashboard to manually review and block risky sign-ins

Why it fails: The Identity Protection dashboard is a monitoring and forensic tool, not an enforcement mechanism. It surfaces risky sign-ins and allows an admin to manually review, dismiss, or confirm compromise, but it cannot automatically block access in real time or trigger a self-remediation workflow without additional policies. Relying on manual review introduces human latency and does not meet the requirement for automated response, nor does it evaluate deterministic conditions like anonymous IP addresses—that requires a Conditional Access policy.

Configure a user risk policy to require password change for high risk users

Why it fails: A user risk policy that requires a password change for high-risk users is applied after the user has already authenticated, so it does not block the initial high-risk sign-in or prevent access to resources during that session. It is valuable for forcing credential rotation on a compromised account, but it is only a post-authentication remediation control, not an access-blocking one. This option fails the stated requirement because it neither blocks anonymous IP sign-ins nor addresses the network-level risk; it only mitigates risk after the fact.

User account with multi-factor authentication

Why it fails: Multi-factor authentication (MFA) on a user account requires interactive user presence, such as entering a code from an authenticator app or responding to a push notification. This makes it unsuitable for non-interactive scenarios like automated scripts or daemon applications, because the MFA challenge cannot be completed without human intervention.

User account with password and MFA

Why it fails: Combining a user password with MFA still forces every sign-in to be interactive due to the MFA requirement, so it cannot be used for unattended automation. Additionally, using a user account for service-to-service authentication violates Azure best practices, which mandate service principals for automated processes, regardless of whether MFA is enabled.

Managed identity for Azure resources

Why it fails: Managed identity is an Microsoft Entra ID identity that is automatically tied to an Azure resource (e.g., a VM or App Service) and can only be used from inside that resource. Since this question addresses authenticating to Azure generally, managed identity is invalid for scenarios where the caller runs outside Azure, as it is not portable to on-premises or external environments.

deny

Why it fails: Deny will reject any create or update operation that does not match the policy rule, so a missing required tag would make the deployment fail before the resource is ever provisioned. However, deny is purely preventive — it never modifies the resource payload or applies a tag value, and it has no way to read the subscription's tag and inherit it. It also cannot remediate pre-existing resources that were created before the policy was assigned.

audit

Why it fails: Audit merely records compliance status in the activity log by writing a warning event when a resource is found non-compliant; it does not block the deployment or alter any tag field. Since no action is taken on the resource itself, audit cannot enforce a tagging standard or inherit values, it only surfaces visibility for reporting. This makes audit useful for discovery before enforcement, but it fails as a standalone enforcement mechanism.

append

Why it fails: Append can add a tag during resource creation or update, but the value must be defined statically in the policy definition as a constant — it cannot reference the subscription or resource group tag as a dynamic expression. Moreover, if the tag already exists on a resource, append does not replace it, so it cannot correct an incorrectly valued tag. Because of these constraints, append only handles the narrow case of a fixed default tag and is insufficient for real inheritance.

Assign a policy at the management group level that denies all locations except West US, and assign a separate policy at the subscription level that allows East US.

Why it fails: A subscription-level policy that allows East US cannot supersede the management group deny because Azure Policy evaluation is additive: the effective denial from the higher scope remains in force, and any applicable Deny effect at any scope blocks the deployment. The lower-scope 'allow' is not a legal override. To permit the resource group to use East US, you must create an explicit policy exemption for that resource group on the management group deny assignment.

Assign a policy at each subscription level allowing only West US, and grant the resource group owner role to bypass.

Why it fails: Azure Policy enforcement is independent of RBAC. Having the Owner role on a resource group grants full management control, but it does not provide any bypass of a Deny effect from a subscription-level policy. During the deployment pipeline, policy evaluation can block the request even for an Owner, because only a policy exemption (or a change to the policy assignment) can exclude a scope from evaluation, not assignment of a built-in role.

Use Azure Blueprints to assign a policy at the management group and then edit the blueprint for the exception.

Why it fails: Azure Blueprints is a deployment orchestration tool: it assigns policies, but merely re-editing a blueprint definition does not create a policy exemption and does not change the effective evaluation for an existing assignment. Even after redeploying a modified blueprint, the management group deny would still apply to the resource group unless an explicit policy exemption is created. This approach incorrectly assumes blueprint content can override evaluation rather than using the intended exemption mechanism.

The VM is created successfully.

Why it fails: The VM is created successfully is wrong because the assigned policy definition uses a Deny effect for SKU restrictions. During an ARM template deployment or REST API call, Azure Policy evaluates the VM's sku.name field against the allowed list; since Standard_D8s_v3 is absent, the deployment fails before any resource is provisioned. A successful creation would require the requested SKU to satisfy the policy condition or the assignment to exclude the scope.

The VM is created but flagged as non-compliant.

Why it fails: The VM is created but flagged as non-compliant is incorrect because a Deny effect, unlike an Audit effect, does not allow the resource to be created. When the policy condition is true, Azure Policy blocks the deployment request and returns an error, so there is no resource left to flag as non-compliant. Non-compliance reporting only applies to resources that already exist—typically those created before the policy assignment—or for policies that explicitly use the Audit effect.

The VM SKU is automatically changed to Standard_D4s_v3.

Why it fails: The VM SKU is automatically changed to Standard_D4s_v3 is wrong because Azure Policy's Deny effect does not perform any modification or replacement of resource properties. A different effect, such as Modify, could alter a field, but that is not the configured effect here, and the policy never selects an allowed alternative SKU from the list. The only possible outcomes are a passed deployment or a blocked deployment—never an automated SKU substitution.

Users with the highest number of sign-in attempts.

Why it fails: The query does not rank or sort by total sign-in volume. It first filters the Microsoft Entra ID sign-in logs to only events where the risk level equals 'medium' and then aggregates them by user, requiring a count greater than 5. Thus, a user with the highest overall number of login attempts would only appear if they also had more than five medium-risk events, which is not what 'highest number' implies. Also, no 'top' or 'order by' operator is present in the KQL query.

Users who had sign-ins from anonymous IP addresses.

Why it fails: While 'anonymousIPAddress' may be one of the risk event types captured in the 'SigninLogs' table, the KQL query does not simply look for that feature. It filters on the overall risk level of 'medium'—meaning the sign-in has been assigned that aggregated risk classification—and then only returns users with more than five such events. A single anonymous IP sign-in, or even several, would not satisfy the query's grouping and having clause. Therefore, this option mischaracterizes the query's logic.

Users who have unfamiliar features in their sign-ins.

Why it fails: The query's core filter is the medium risk level, not a specific risk event type like 'unfamiliarFeatures'. Even if some of the matched sign-ins include unfamiliar features as a contributing risk signal, the query only determines whether the user has more than five medium-risk sign-ins. Users with unfamiliar features in their sign-ins but fewer than six medium-risk events are excluded, while users with other medium-risk indicators may be included. Thus, 'have unfamiliar features' overstates the query's scope.

The VM agent is not installed.

Why it fails: The Azure VM Agent (WALA) is a prerequisite for all VM extensions, but the exhibit does not indicate it is missing or unhealthy. If the agent were absent, the extension provisioning would fail with a guest agent-specific error such as "VMAgent is not supported" or "The guest agent is not running", rather than a configuration parsing failure. The misconfigured 'protectedSettings' is independent of agent presence, so this cannot be the cause.

The VM has no outbound internet connectivity.

Why it fails: The script for this deployment is provided locally or via a direct path, not downloaded from the internet, so outbound connectivity is irrelevant. Even if the VM lacked internet, the extension would still be able to execute a local script if the configuration were valid. Moreover, a connectivity failure would surface as a "Failed to download script" error during execution, whereas the reported error is about invalid configuration. Thus, this is not the root cause.

The extension type is incorrect.

Why it fails: The extension type "Microsoft.Compute.CustomScriptExtension" is the correct, built-in extension type for executing custom scripts on a Windows VM. A deployment with an incorrect extension type would generate a WebException or "The extension type is not registered" error during provisioning, not a configuration validation failure. Since the error aligns with a malformed settings object, the extension type is not the issue.

Log Analytics workspace

Why it fails: A Log Analytics workspace becomes relevant only if you opt into Traffic Analytics, which ingests processed flow log data for advanced querying and visualization. Raw NSG flow logs are delivered to a storage account as JSON files, so the workspace is not a prerequisite for basic flow log collection. Selecting a Log Analytics workspace is an optional, secondary dependency that does not enable traffic capture itself.

Traffic Analytics

Why it fails: Traffic Analytics is an optional, built-in add-on that turns raw NSG flow log records into visibility by grouping flows, identifying top talkers, and detecting anomalies using machine learning. It does not capture data itself; instead, it processes the flow log blobs already stored in the storage account and enriches them with Azure's intelligence. Enabling Traffic Analytics adds significant querying and alerting value, but you must first have NSG flow logs feeding data.