Design security solutions for infrastructure practice questions

CodeQL code scanning

Why it fails: CodeQL code scanning is a static analysis tool that models and queries data flow and control flow to identify vulnerabilities like SQL injection, cross-site scripting, and insecure deserialization. It does not search for raw secret strings or credential patterns in the repository; instead, it analyzes source code semantics. Therefore, CodeQL is the wrong tool for detecting a leaked API key or password, which is a content-matching problem rather than a code-quality problem.

Dependabot alerts

Why it fails: Dependabot alerts rely on a database of known Common Vulnerabilities and Exposures (CVEs) and compare the manifest and lock files (e.g., package.json, Pipfile.lock) in a repository against that database. Its sole purpose is to identify vulnerable and outdated dependencies, not to inspect the files or commit history for embedded secrets. A leaked secret will never appear in a dependency graph; thus, Dependabot cannot satisfy the secret-detection requirement.

Defender for Cloud DevOps security posture management

Why it fails: Defender for Cloud's DevOps security posture management (or CSPM features for DevOps) provides continuous assessment of your DevOps environment by evaluating configuration posture, identity/permissions, and compliance of CI/CD pipelines and infrastructure-as-code. It can surface misconfigurations and missing security controls, but it does not natively scan repository contents for secret patterns with the same fidelity as GitHub secret scanning. Hence, while it may recommend enabling secret scanning, it is not a replacement for the detection capability itself.

The rule only allows traffic on port 443 from a specific IP range

Why it fails: This is incorrect because the NSG rule's sourceAddressPrefix is set to 'Internet', which is a service tag that represents all public IP addresses, not a specific IP range. The rule does not restrict the source to any particular CIDR block or individual IP; it permits any host on the Internet to initiate connection to TCP port 443. The port 443 is the destination port, not the source address, so the claim about a specific IP range is false.

The rule allows outbound traffic from the subnet to the Internet

Why it fails: This is incorrect because the rule's direction is explicitly 'Inbound', meaning it governs traffic arriving at the subnet from the Internet, not traffic leaving the subnet. An outbound rule would require the direction to be 'Outbound' and would apply to the source being the subnet and the destination being external. This rule has no effect on outbound connectivity; it only evaluates incoming packets whose source is the Internet and destination is the subnet.

The rule blocks all inbound traffic from the Internet

Why it fails: This is incorrect because the rule's access is set to 'Allow', not 'Deny', so it explicitly permits inbound traffic on port 443 from the Internet rather than blocking it. The rule does not block all inbound traffic; it actually allows a specific subset (HTTPS) and leaves other inbound traffic to be handled by default rules. If the intention were to block all inbound Internet traffic, you would need a 'Deny' rule with a broader scope, such as any source on all ports.

Microsoft Purview

Why it fails: Microsoft Purview is a unified data governance and compliance solution that focuses on discovering, classifying, and governing sensitive data across on-premises, multi-cloud, and SaaS environments. It does not provide any host-based security controls for Azure VMs, such as antimalware, vulnerability scanning, or just-in-time access protection. While Purview can help identify where sensitive data resides, it cannot remediate or defend against malware infections on virtual machines.

Microsoft Sentinel

Why it fails: Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automated Response) solution that aggregates logs and alerts from various sources, including Defender for Cloud, for security analytics and incident response. It does not actively protect VMs from malware or perform vulnerability assessment; instead, it relies on other security tools to generate the telemetry it analyzes. Using Sentinel alone would leave the VM unprotected, as it lacks native antimalware or host-based security controls.

Microsoft Intune

Why it fails: Microsoft Intune is a cloud-based unified endpoint management (UEM) and mobile device management (MDM) service that manages user-facing devices like Windows PCs, Macs, iOS, and Android devices, focusing on compliance and application deployment. It is not designed to secure infrastructure-as-a-service (IaaS) workloads such as Azure VMs, nor does it provide antimalware, vulnerability scanning, or security hardening for virtual machines. Intune's scope is device and application management, not workload protection within Azure.

Analytics rules with incident creation

Why it fails: Analytics rules in Microsoft Sentinel contain scheduled or near-real-time detection queries that create alerts and incidents when suspicious activity is detected. They are designed purely for detection and alerting; in their default configuration they do not perform any response or remediation steps. To attach an automated response, an automation rule must be created to invoke a playbook upon the analytics rule’s incident creation.

Hunting queries

Why it fails: Hunting queries are KQL-based searches that security analysts run interactively in the Microsoft Sentinel hunting area to proactively look for threats or intrusion artifacts. These queries are a manual, exploratory activity; they do not automatically generate incidents or trigger any response. While analysts can create bookmarks and livestream from hunting queries, the queries themselves have no capability to invoke playbooks or execute remediation actions.

Workbooks

Why it fails: Workbooks in Microsoft Sentinel are interactive dashboards built on Azure Workbooks that provide visualizations, metrics, and trend analysis from log data for security operations reporting. They are read-only reporting tools and do not contain logic to detect threats or launch any automated response. Their purpose is to present information to analysts and stakeholders, not to directly affect the lifecycle of an incident.

Azure Logic Apps with Defender XDR connector

Why it fails: Azure Logic Apps with the Defender XDR connector can orchestrate automated playbooks, such as sending notifications or updating tickets, but they are not designed to serve as the primary incident ingestion pipeline. Logic Apps are triggered by events and can perform actions, yet creating incidents from every alert via Logic Apps would require building a custom workflow that calls the Sentinel API, replicating the connector's functionality without its reliability or scalability. The data connector is the designated mechanism for automatically creating incidents, while Logic Apps are best reserved for post-incident automation.

Microsoft Power Automate flow triggered by Defender XDR alerts

Why it fails: Power Automate flows are a valid way to automate responses, but they are not the out-of-the-box method for creating Sentinel incidents from Defender XDR alerts. A flow would need to be manually configured to trigger on each alert, parse the alert payload, and then call the Sentinel API to create an incident, introducing latency, potential throttling, and a single point of failure. This workaround bypasses the native incident correlation and deduplication that the Defender XDR data connector provides, making it unsuitable as the standard integration.

Microsoft Graph API subscription to Defender XDR alerts

Why it fails: Microsoft Graph API subscriptions for Defender XDR alerts require custom development to manage webhooks, validate tokens, and handle event delivery. While possible, this approach lacks the built-in incident creation logic, schema normalization, and automated correlation that the Sentinel data connector offers. You would need to write your own code to ingest alerts, deduplicate them, and create incidents, which increases complexity and maintenance overhead. It is not a practical or supported method for routine incident creation in Sentinel.

Azure SQL Scanner (Purview)

Why it fails: There is no discrete component in Microsoft Purview called 'Azure SQL Scanner.' Purview's data classification workflow is based on registering data sources and creating scans, where each scan uses a specific scanning rule set—such as the built-in system rule set for Azure SQL Database—to detect and classify sensitive columns. Referring to it as a 'scanner' implies a standalone product, which misrepresents how Purview's scanning engine actually operates.

Purview Insights

Why it fails: Purview Insights is a reporting and analytics layer that visualizes information gathered after scans complete—such as classification coverage, glossary term usage, and catalog adoption metrics—by aggregating metadata from the Purview Catalog. It does not actively scan or classify data itself; instead, it consumes the results of previous scans, so it cannot be the tool that performs data classification.

Microsoft Defender for SQL

Why it fails: Microsoft Defender for SQL, a cloud workload protection service in Defender for Cloud, focuses on security monitoring: vulnerability assessments, threat detection, and anomaly alerts for Azure SQL and SQL servers. While it may surface data sensitivity as part of its security posture management, its purpose is protection, not the systematic classification scanning that Purview's rule sets provide; moreover, it is not a Purview component at all.

Enable private cluster mode

Why it fails: Private cluster mode is an AKS networking feature that restricts the Kubernetes API server to a private IP address, preventing exposure to the public internet. This reduces the network attack surface but is not a Microsoft Defender for Cloud capability, nor does it provide threat detection, compliance auditing, or security policy enforcement. Secure access is only one small piece of the overall security posture, so this setting alone cannot fulfill the requirement to secure AKS through Defender for Cloud.

Configure Network Security Groups (NSGs) on AKS subnets

Why it fails: AKS automatically manages Network Security Groups on node subnets, and adding user-defined NSGs is not supported because it can interfere with AKS's own networking rules. Moreover, NSGs filter by IP address and port, making them ineffective for pod-level segmentation, which instead should be handled by Kubernetes network policies. Microsoft Defender for Cloud's guidance for AKS relies on these native Kubernetes controls and Defender for Containers, not on manual NSG configuration.

Deploy Azure Firewall in the AKS virtual network

Why it fails: Azure Firewall is a perimeter network security service that filters traffic based on IP addresses, ports, and protocols, but it lacks container-aware visibility and cannot inspect pod-level identities or Kubernetes API semantics. Deploying it inside the AKS virtual network is unnecessary for protecting the cluster from platform security perspective, and Microsoft Defender for Cloud does not list it as a requirement. While Azure Firewall can assist with egress filtering, it does not substitute for the threat detection and policy enforcement provided by Defender for Containers and Azure Policy.

Microsoft Entra application proxy

Why it fails: Entra Internet Access secures internet and SaaS traffic via Entra Private Access, Global Secure Access clients and Conditional Access; Application Proxy publishes on-premises web apps, not internet-bound traffic. It is tempting because Application Proxy also uses Entra ID, and would be correct if the scenario required remote access to internal web applications.

Site-to-site VPN

Why it fails: Entra Internet Access routes user traffic through Microsoft's Security Service Edge using Global Secure Access clients and Conditional Access, not site-to-site tunnels between networks. It is tempting because VPNs provide encrypted connectivity, and would be correct if the requirement were branch-to-datacentre or hybrid network connectivity rather than per-user internet security.

Azure RBAC roles for AKS

Why it fails: Azure RBAC for AKS governs which user or service principal can perform actions on cluster resources through role assignments such as Azure Kubernetes Service Contributor or Reader. However, RBAC only checks whether an identity is authorized to issue a create or update request; it never inspects the payload of that request. A user with contributor rights could therefore deploy a pod with privileged: true or hostNetwork: true, and RBAC would allow it. Denying such pod definitions requires an admission-time policy, not an access-control permission model.

Microsoft Defender for Containers

Why it fails: Microsoft Defender for Containers is a Cloud Workload Protection solution that ingests Kubernetes audit logs and runtime signals to detect active threats such as credential theft, cryptomining, or suspicious process execution. It provides security alerts, vulnerability assessments, and attack-path analysis, but it operates as a detective control after the fact; it cannot deny a pod creation request or enforce that containers run without added privileges. Therefore, while Defender would likely alert on a privileged container that is later used for an attack, it is not the mechanism that blocks the deployment in the first place.

AKS Pod Identity

Why it fails: AKS Pod Identity is an integration where a pod is labeled with an Microsoft Entra ID identity; the Node Managed Identity (NMI) daemon intercepts the pod's token request to the IMDS endpoint and returns an Microsoft Entra ID token for services like Key Vault or Storage. It is purely an authentication bridge between the pod and Azure resource APIs; it does not inspect or constrain the pod's security context, Linux capabilities, or networking settings. Thus Pod Identity cannot act as an admission controller to deny privileged or host-network pods.

Always Encrypted

Why it fails: Always Encrypted is a client-side encryption feature that protects data at rest and in transit by ensuring the database server never sees the plaintext column values — encryption keys remain in the client application. However, once an authorized application or administrator presents the correct column master key to the client driver, queries return fully decrypted results in the client environment. This means Always Encrypted does not prevent a legitimate admin from copying that decrypted data out of the application or from running a query that exports the entire column to a file; it only prevents unauthorized viewing at the storage and server level.

Azure SQL Database firewall rules

Why it fails: Azure SQL Database firewall rules operate at the network layer, restricting access to the database based on client IP address ranges. They cannot distinguish between an attacker and a legitimate administrator who has connected from an approved IP address — once the connection is established, the admin can run any query and copy the results. Firewall rules also do not inspect the query's purpose or the sensitivity of the data being returned, so they provide no protection against an insider intentionally exfiltrating data over an allowed connection.

Azure Information Protection

Why it fails: Azure Information Protection (AIP) is a classification and labeling solution that applies sensitivity labels to documents and emails, and can attach rights-management usage restrictions to those labeled artifacts. However, AIP does not inspect or intercept live database query results as they are being rendered in a SQL client GUI or exported to CSV; its enforcement happens downstream after data has been saved to a labeled file. A labeled SQL result set that gets pasted into an unlabeled file or communicated via a non-integrated channel is not blocked by AIP, so it fails to prevent the admin from copying data directly out of the database.

Common Event Format (CEF) via AMA

Why it fails: Common Event Format (CEF) via AMA uses a syslog-style forwarder to convert logs into a standard format and send them to Sentinel, typically requiring a dedicated Linux forwarder VM. That forwarder must maintain direct internet connectivity to reach the Log Analytics workspace, which violates the requirement that the isolated servers have no internet access. Since the CEF pipeline itself depends on that connectivity, it cannot be adapted to a fully isolated environment without an extra outbound relay.

Syslog via AMA

Why it fails: Using Syslog via Azure Monitor Agent (AMA) typically works by having the AMA listen for syslog messages on the server and then forward them to the Log Analytics workspace. However, this forwarding still requires an outbound network path to Azure or a configured Log Analytics gateway, which isolated servers with no internet connectivity lack. Therefore, simply enabling syslog input on AMA does not solve the data delivery problem, because the agent cannot emit events to Sentinel without some form of outbound access.

Log Analytics agent (MMA)

Why it fails: The Log Analytics agent (MMA) is the legacy data-collection agent and is officially deprecated, with end-of-support dates that make it unacceptable for new Microsoft Sentinel deployments. Although it could work in some isolated scenarios via the Log Analytics gateway, Microsoft is focusing all development on the Azure Monitor Agent, so choosing MMA now would require a future migration and is not an appropriate solution.

Microsoft Sentinel solution

Why it fails: The 'Microsoft Sentinel solution' is a misnomer in this context—Sentinel is itself a cloud-native SIEM product, not a discrete installable component within its own deployment. When you enable Sentinel on a Log Analytics workspace, you are activating the product, not adding a separate solution from the content hub. The content hub does contain solution packs, but they are optional for basic ingestion, so this is not one of the three required components.

Azure Arc

Why it fails: Azure Arc is a hybrid management and governance service for servers, Kubernetes clusters, and databases, but it is not a component in Sentinel's AWS ingestion pipeline. Arc does not collect or forward AWS S3 logs, and enabling Arc on AWS EC2 instances is optional and unrelated to CloudTrail ingestion. Since the question asks for components required to implement Sentinel with AWS logs, Arc is a distractor that does not participate in any required data path.

Privileged Identity Management (PIM)

Why it fails: Privileged Identity Management (PIM) is an Microsoft Entra ID identity governance feature that provides just-in-time, time-bound, and approval-based role activation for elevated roles. While PIM can optionally require MFA to activate those roles, that requirement applies to the activation step, not to normal user sign-in. PIM does not enforce MFA on a per-user basis across sign-ins, so it is not a valid method for enforcing MFA as the question requires.

Security defaults

Why it fails: Security defaults is a tenant-wide baseline configuration in Microsoft Entra ID that automatically enforces MFA for every user, while also blocking legacy authentication protocols. Because it turns on uniformly across the entire tenant, an administrator cannot apply it selectively to an individual user or group. Thus, while it does enforce MFA, it does so as an all-or-nothing tenant setting and is not a per-user MFA enforcement method.

Identity Protection policies

Why it fails: Microsoft Entra ID Protection is a risk engine that evaluates signals from sign-ins and user behavior to flag suspicious activity. Its risk-based policies can trigger a requirement for MFA through Conditional Access when risk is detected, but Identity Protection itself does not directly enforce MFA for any given user. A user with no detected risk would not be challenged for MFA, so this mechanism is not a straightforward method to enforce MFA per user or independently.

Use Azure Bastion for management and VNet peering between web and database subnets.

Why it fails: While Azure Bastion secures administrative access to virtual machines, it does nothing to inspect or filter application traffic between the web and database tiers; VNet peering simply provides connectivity, not security controls. Without a central firewall or forced tunneling, east-west traffic bypasses inspection, and the web tier's public exposure remains controlled only by NSGs or other per-subnet rules, which lack stateful, application-aware filtering. Thus this architecture fails to meet the requirement for centralized security and enforced traffic flow.

Place web and database tiers in the same virtual network and use Network Security Groups (NSGs) to restrict access.

Why it fails: Placing both tiers in a single VNet with only NSG rules lacks centralized visibility and enforcement, as NSGs are distributed, per-subnet or per-NIC tools that filter based on five-tuple rules without application-aware inspection. Although NSGs are stateful, they cannot force traffic through a specific security appliance or provide centralized logging and threat intelligence. Relying solely on NSGs leaves the database reachable by any compromised resource in the web subnet and offers no way to enforce a corporate security policy uniformly.

Use Azure Application Gateway to expose the web tier and place the database tier in a separate subnet with a deny-all NSG.

Why it fails: Azure Application Gateway serves as an inbound Layer-7 load balancer for HTTP(S) traffic and cannot be inserted into the data path between the web and database tiers; it only receives client requests and forwards them to the web backend. A deny-all NSG on the database subnet would block legitimate web-to-database requests unless explicit allow rules are added, but such rules operate without centralized inspection or the ability to monitor traffic for threats. This configuration neither forces traffic through a security appliance nor provides a mechanism to scale security policy across multiple tiers.

Azure Activity logs with an anomaly rule

Why it fails: Azure Activity logs contain only control-plane telemetry from Azure Resource Manager, such as resource creation, role assignments, or NSG modifications—they do not capture host-level process execution, network connections, or interactive logons within a corporate network. An anomaly rule applied to these logs learns baseline behavior for Azure subscription operations, but it cannot observe the on-premises or hybrid network traffic, RDP sessions, or SMB connections that characterize lateral movement. Therefore, this option fails because it monitors the wrong plane (management vs. data) and misses all domain-joined endpoint activity that Sentinel needs to correlate.

Windows Security Events with a scheduled query rule

Why it fails: Windows Security Events are indeed valuable, but a scheduled query rule executes a fixed KQL query on a predetermined schedule (e.g., every 5 minutes) and is designed to flag a single event pattern or simple aggregation, not an ordered multi-event sequence spanning hours. Detecting lateral movement often requires correlating many different event IDs (e.g., 4624 logons, 4688 command lines, 5140 file shares) across multiple machines and time windows—something a single scheduled query handles poorly. To even approximate this, you would need complex joins and lookups that are costly, hard to tune, and prone to false positives because the rule has no built-in knowledge of attack chains.

Sysmon logs with a scheduled query rule

Why it fails: Sysmon provides excellent endpoint telemetry, including Process Creation (Event 1), Network Connection (Event 3), and File Creation (Event 11), but using it only with a scheduled query rule imposes a narrow, single-pattern detection approach. A scheduled query can only evaluate a fixed condition—such as a specific process executing or a particular connection to an IP—so it cannot reconstruct the full lateral movement path that unfolds over time across multiple hosts. Furthermore, since Sysmon generates high-volume, verbose events, a scheduled query that attempts to join multiple Event IDs requires heavy KQL and often times out; without additional orchestration or analytics rules, it will only catch isolated indicators, not the correlated kill-chain steps that Fusion would surface.

modify

Why it fails: In the context of Azure Policy for AKS, the 'modify' effect is used to add, update, or remove fields on resources during creation or update. However, it does not have the capability to evaluate or block based on the source registry or image location of containers. It can't enforce that images only come from approved registries like Azure Container Registry. Modify simply changes resource properties but doesn't act as an admission controller policy for validating image origins. Therefore, choosing modify would not meet the requirement to restrict image sources.

audit

Why it fails: The 'audit' effect in Azure Policy for AKS evaluates resources and reports compliance but does not block creation. For a security requirement to 'secure' clusters by restricting image sources, auditing only would not be sufficient because non-compliant images would still be deployed. It would log or flag the violation but not prevent it. Since the goal is to enforce a restriction, audit falls short.

deny

Why it fails: The 'deny' effect is commonly used with Azure Policy to deny non-compliant resource creation. However, for AKS admission control via Azure Policy, the 'deny' effect is not supported for custom Rego policies. The supported effects for Gatekeeper integration are 'audit' and 'enforceRegoPolicy'. Using 'deny' would be invalid or unsupported for the specific scenario of enforcing image source restrictions within AKS. Thus, it's the wrong choice.

Enable Always Encrypted for sensitive columns

Why it fails: Always Encrypted is a client-side encryption feature that protects sensitive column data by ensuring the database engine never sees plaintext values, mitigating attacks from high-privileged database administrators. However, it does not enforce client IP restrictions or force encryption in transit, because transport security is handled by TLS. While valuable for column-level confidentiality, it does not address the network-level access and transport requirements central to this secure access strategy.

Configure an Azure Private Endpoint for the SQL server

Why it fails: An Azure Private Endpoint assigns your Azure SQL logical server a private IP address within a virtual network, enabling connections via Private Link instead of the public Internet. While this improves security by removing public exposure, it does not implement server-level IP-based firewall rules; access through the private endpoint is governed by network security groups (NSGs) and subnet policies, not by the SQL firewall. Since the question specifically requires a firewall rule allowing client IP ranges, a private endpoint addresses a different connectivity model and does not substitute for the IP-based restriction.

Require a minimum password length of 8 characters

Why it fails: Requiring a minimum password length of 8 characters is incorrect for a device-health check because password policy is an identity and access-control measure, not a reflection of the endpoint's own security posture. Defender for Endpoint's health signals focus on whether the device has active malware protection, encryption, and up-to-date patches—not on the strength of user credentials. A long password does nothing to indicate if the device is compromised, missing updates, or vulnerable to threats. Thus, while important, it addresses user authentication, not device health from a threat perspective.

Require that the device is not jailbroken or rooted

Why it fails: Requiring that the device is not jailbroken or rooted is incorrect in this Windows-centric scenario because jailbreak and root detection are mobile-specific integrity checks. Windows endpoints rely on different security mechanisms like Secure Boot, Hypervisor-protected Code Integrity (HVCI), and Device Guard, not jailbreak status. Defender for Endpoint does assess mobile device health with such signals, but the question explicitly targets Windows devices. Therefore, this option is simply not applicable to the Windows endpoint health assessment being described.

Require the device to be on a specific OS version

Why it fails: Requiring a specific OS version is incorrect because it is a static compliance baseline, not a dynamic health check. Having a particular OS version does not guarantee that critical security patches are installed or that the device is free from vulnerabilities. Defender for Endpoint evaluates whether the device is actually patched by comparing its installed updates against known vulnerabilities, rather than just checking a version number. A device on the latest OS could still be unhealthy if its real-time protection is disabled or it lacks encryption, making this option insufficient and not a direct threat-protection signal.

It blocks all outbound traffic to the internet from the subnet.

Why it fails: This option incorrectly interprets the rule's direction. The PowerShell script creates an inbound security rule, which applies to traffic entering the subnet from outside. Outbound traffic is governed by separate outbound rules, so this inbound deny rule has no effect on internet-bound traffic originating from the subnet. Therefore, the statement is false.

It blocks inbound traffic only from specific IP ranges.

Why it fails: The rule's source is defined as the 'Internet' service tag, not a set of specific IP addresses. A service tag dynamically represents predefined groups of Azure IP ranges, including all public IP addresses and certain Azure services, rather than a static list you manually specify. Consequently, the deny rule influences inbound traffic from the entire internet, not just particular IP ranges, making this description inaccurate.

It allows inbound traffic from the internet, then denies it.

Why it fails: This option wrongly suggests a sequence of allow then deny. The script only defines a single inbound security rule with the Deny action; there is no preceding allow rule for internet traffic in the script. Network security group rules are evaluated in priority order, and a deny rule will block matching traffic regardless of any lower-priority allow rule, but no such allow exists here. Therefore, the statement misrepresents both the rule count and evaluation flow.

It allows all traffic because the deny rule has a higher priority number.

Why it fails: This statement misreads NSG priority semantics. In Azure Network Security Groups, a lower numeric priority value is evaluated first, so the deny rule at priority 200 is only reached if the allow rule at priority 100 does not match. Traffic from 192.168.0.0/24 matches the allow and is permitted, while all other source IPs fall through to the deny rule and are blocked. Thus, the actual effect is not 'allow all' but rather a specific allow plus a default-deny.

It denies traffic from 192.168.0.0/24 and allows all other traffic.

Why it fails: This is the inverse of what the rules produce. The priority-100 rule grants an explicit allow to 192.168.0.0/24, and because 100 is lower than 200, that allow is processed first, instantly permitting matching traffic before the deny rule can evaluate it. Traffic from any other source will not match the allow and will subsequently be blocked by the priority-200 deny-all rule. Consequently, the outcome is that the corporate subnet is allowed and all other traffic is denied, not the reverse.

It denies all traffic because the deny rule covers any IP.

Why it fails: Although the deny rule indeed specifies 'Any' as its source and destination, NSG evaluation is sequential and stops at the first matching rule. The priority-100 allow rule matches and permits traffic from 192.168.0.0/24 before the priority-200 deny rule is ever consulted. Only non-matching source IPs, i.e., those outside the allowed subnet, reach the deny-all rule and are blocked. Therefore, the combined behavior is not a global denial; it is an allow-list for the corporate subnet with a default-deny for everything else.