Secure networking practice questions

The Azure Firewall is not in the same region as the spoke.

Why wrong: An Azure Firewall is a regional service, but it can inspect traffic for spokes in other regions when reached over global VNet peering. The hub VNet's firewall is accessed by its private IP address as a virtual-appliance next hop, and Azure's global peering forwards that traffic regardless of region mismatch. A regional difference alone cannot explain why on-premises traffic bypasses the firewall; the actual issue is the missing specific route for the on-premises prefix in the spoke's route table.

The ExpressRoute gateway's BGP routes are still overriding the UDR because gateway propagation is not fully disabled.

Why wrong: Disabling 'Virtual network gateway route propagation' on a route table stops learned ExpressRoute/BGP routes from being added to the spoke subnet's effective routes. If propagation were still partially enabled, the on-premises BGP route would show up, but it would not override a more-specific UDR that points to the firewall — longest-prefix match would prefer that UDR. The problem is not an incomplete propagation setting; it is that no UDR exists for the specific on-premises prefix, so the default 0.0.0.0/0 route never applies to that traffic.

The route table is not associated with the spoke subnet.

Why wrong: If the route table were not associated with the subnet, no UDR would apply at all, and traffic would use default routes. But internet traffic was being routed through the firewall, indicating the route table is associated.

The Azure Firewall is not configured with a default route.

Why wrong: The Azure Firewall is not configured with a default route. This is not the reason traffic bypasses the firewall because Azure Firewall does not require a default route on its own subnet to inspect traffic; it operates as a transparent layer-3/4 filter that processes packets forwarded to it via UDRs. The relevant routing is the user-defined route on the spoke subnet pointing to the firewall's private IP, not the firewall's internal routing table. Even if the firewall lacks a default route, it can still receive and inspect outbound traffic as long as the UDR is correctly configured and the firewall has a route back to the source subnet.

The virtual machines have public IP addresses assigned.

Why wrong: The virtual machines have public IP addresses assigned. This is the correct cause because when an Azure VM has a public IP address assigned to its network interface, Azure automatically performs default outbound SNAT using that public IP, which bypasses any UDRs pointing to the firewall. The traffic from the VM to the internet egresses directly through the public IP, and the route table is ignored for that outbound flow. To force traffic through the firewall, the VMs should use a NAT gateway or be deployed in a subnet without public IPs, with the UDR sending all internet-bound traffic to the firewall's private IP.

The VNet peering is not configured properly.

Why wrong: The VNet peering is not configured properly. This is not the cause because VNet peering is only required when the firewall is in a different virtual network than the VMs, and the scenario does not indicate that peering is misconfigured. Even if peering were involved, the peering connection would only affect routing between VNets; the issue described is about outbound internet traffic from VMs with public IPs, which is independent of peering. The presence of public IPs on the VMs is a far more direct and common explanation for why the firewall is not inspecting the traffic, making the peering configuration irrelevant to this specific failure.

The VNet peering is not configured to allow traffic from VNet-B to route through VNet-A.

Why wrong: VNet peering in Azure is bidirectional by default once established; it permits any-to-any traffic between the peered VNets, including traffic that enters one VNet and is routed to the other via an NVA. The act of routing through an NVA is governed by user-defined routes (UDRs) and IP forwarding, not by a separate peering toggle. Therefore, a missing 'allow traffic to route through' setting is not a valid failure mode because such a setting does not exist in Azure VNet peering.

The route table is not associated with the subnet in VNet-B.

Why wrong: The question explicitly states that the route table is associated with the subnet in VNet-B, so this cannot be the cause. Even if association were absent, traffic between directly peered VNets would still flow using the default system route, bypassing the NVA entirely and reaching VNet-A directly. In the described scenario, the intended NVA path is failing because the NVA itself cannot forward, not because the route table is missing.

The NVA does not have a public IP address.

Why wrong: An NVA in Azure forwards traffic using its private IP address; the public IP (if any) is only used for inbound internet-facing connections or outbound SNAT. In a VNet-to-VNet peering scenario, all traffic remains within the Azure backbone and uses private addressing. A public IP is irrelevant to the NVA's ability to route, so its absence would not cause the connectivity failure described.

The SQL server's firewall also has a rule allowing all Azure services, which overrides the VNet rule

Why wrong: A firewall rule that allows all Azure services is broader in scope than a VNet rule; it permits connections from any Azure public IP used by other services, rather than restricting access. It cannot override a VNet rule because it does not deny traffic, and its presence would make access more permissive, not less. An authorization error indicates the client's source IP was not recognized by any allow rule, which the 'Allow Azure services' rule would have satisfied if the connection actually originated from an Azure service IP.

The virtual machine's operating system firewall is blocking outbound traffic

Why wrong: An operating system firewall blocking outbound traffic would prevent the VM from reaching the SQL server at the network layer, resulting in a connection timeout or unreachable host error, not an authorization failure. The error message from Azure SQL indicates the TCP connection was successfully established and the request reached the server, but the server rejected it based on identity or network rules. OS-level filtering would stop the request before SQL could evaluate any firewall rules, producing a different diagnostic signature.

The subnet's NSG is blocking outbound traffic to Azure SQL

Why wrong: While an NSG rule blocking outbound traffic to Azure SQL would prevent connectivity, the failure would manifest as a timeout or connection refused error, not an authorization error from SQL. Additionally, if the Microsoft.Sql service endpoint were correctly enabled on the subnet, the NSG would still apply, but the connection would still reach SQL, enabling the server to return a specific permission error. The most direct cause of an authorization error in this configuration is the service endpoint not being enabled, which breaks the VNet rule's source matching, not an NSG dropping the traffic.

The UDR on VNet-B must also include a route for the default route (0.0.0.0/0) to force all traffic through the NVA

Why wrong: The scenario only concerns traffic between VNet-B and VNet-A. A default route is not required to force traffic between the two VNets through the NVA; the specific route for the VNet-A address space should be sufficient.

VNet peering does not support user-defined routes

Why wrong: Azure VNet peering fully supports user-defined routes (UDRs). Route tables can be associated with subnets in either the hub or spoke VNet, and a UDR can specify a virtual appliance in a peered VNet as the next hop for traffic destined to the other VNet's address space. The claim that peering does not support UDRs is incorrect; peering actually relies on effective routes, which include both system routes and any user-defined routes applied to the source subnet.

The NVA must be deployed in the same subnet as the source VMs in VNet-B

Why wrong: An NVA does not need to reside in the same subnet as the source VMs in VNet-B. It can be placed in a different subnet within VNet-B or even in a different VNet entirely, such as the hub VNet, as long as the corresponding route tables use its private IP address as the next hop for the destination address range. The core requirement is that the NVA's network interface has IP forwarding enabled so it can accept and forward traffic not originally destined to its own IP, not that it shares the source subnet.

The Azure Firewall subnet is missing a route table entry for the 0.0.0.0/0 route

Why wrong: The Azure Firewall subnet (AzureFirewallSubnet) does require a default route to the Internet for the firewall's own outbound traffic, but this route is not what directs spoke traffic to the firewall. Spoke traffic is steered by a user-defined route (UDR) on the spoke subnet with a 0.0.0.0/0 address prefix and the firewall's private IP as the next hop. Missing a 0.0.0.0/0 route on the firewall subnet would cause the firewall to lose Internet connectivity, not cause spoke traffic to bypass it. The bypass occurs because the spoke subnet's route table either lacks the UDR or has a conflicting route, so the diagnostic focus should be on the spoke route table and its Effective Routes, not the firewall subnet.

The VNet peering does not allow forwarded traffic from the spoke to the firewall

Why wrong: Forwarded traffic is allowed by default when virtual network gateway is not used. The requirement for allowing forwarded traffic is the 'Allow virtual network gateway transit' setting in the hub and 'Use remote virtual network gateways' in the spoke, but this is for gateway transit, not for routing through a firewall instance.

The Azure Firewall is not configured with the 'Allow outbound traffic' rule

Why wrong: Firewall rules affect which traffic is allowed, not the routing path. Even without a rule, traffic would still reach the firewall (if routed), but be dropped. The issue is that traffic never reaches the firewall.

The UDR is not applied to the subnet in VNet-B

Why wrong: The scenario explicitly states that the UDR is already configured and applied to the subnet in VNet-B, so the route table is in effect. If no UDR were applied, traffic would simply follow the default system route to the peered VNet-A, which would also bypass the NVA entirely. Because the UDR is active, the cause must be downstream on the NVA side, not an absent route table assignment.

VNet peering does not support user-defined routes

Why wrong: User-defined routes are fully supported in conjunction with VNet peering. A custom route table applied to a subnet overrides the system route created by the peering, so traffic can be forced to the NVA rather than taking the direct peered path. The absence of a UDR for the peering itself is not the problem; in fact, the UDR is present and working as designed. The reason connectivity fails is that the NVA cannot forward packets without IP forwarding enabled.

The NVA must be in the same virtual network as the spoke

Why wrong: There is no Azure requirement that a network virtual appliance reside in the same virtual network as the spoke from which traffic originates. A hub-and-spoke topology with VNet peering between VNet-A and VNet-B is a standard design, and any UDR can specify an NVA's private IP in a peered VNet as the next hop. As long as the peering connection exists and the NVA's NIC has IP forwarding enabled, traffic can be routed across the peered topology. The NVA's location is not the issue in this scenario.

4

Why wrong: Adding a fourth rule is unnecessary because NSGs already have a built-in default deny-all inbound rule. An explicit deny rule would duplicate this existing behavior, adding rule-processing overhead and management complexity without improving security. If the intent is to allow only those three services, three allow rules are sufficient; the default deny terminates all other inbound traffic.

5

Why wrong: Five rules exceed the requirement and introduce avoidable complexity. With only three services to expose, three allow rules—one per service—are the minimum and correct design. Additional rules would likely be redundant allow rules or unnecessary deny rules; neither improves the security posture because the default deny rule already blocks all traffic that does not match the three allow rules, and extra rules increase the chance of priority misconfigurations.

2

Why wrong: Two rules cannot map three distinct services with different destination ports and separate source address restrictions onto their respective clients. An NSG rule is a single entry tying a source prefix, destination port, and protocol; trying to combine HTTP and HTTPS into one rule would either merge their source restrictions or require a port range that could over-permit, and RDP would still need its own rule. Because each service has its own source address, separate allow rules are required for HTTP, HTTPS, and RDP.

Service tag

Why wrong: A service tag is incorrect because it represents a predefined set of IP address ranges belonging to a specific Azure service (for example, Storage.WestUS, AzureLoadBalancer, or VirtualNetwork), not a custom group of your own VMs. If you use a service tag as the source, the NSG rule would match traffic coming from those Azure service IPs, not specifically from your web server VMs. Service tags are useful for controlling access to Azure PaaS services, but they cannot model an application tier made of your own virtual machines.

Source IP address range

Why wrong: Using a source IP address range is incorrect because it would require you to enumerate every web server's individual CIDR block or IP address in the NSG rule. This approach is brittle and does not scale: whenever a web server is added, removed, or receives a new IP address, you must manually update the rule, and overlapping or fragmented ranges quickly become difficult to manage. The scenario calls for a logical grouping of web servers, which is exactly what an application security group provides rather than relying on static, physical address values.

Virtual network peering

Why wrong: Virtual network peering is incorrect because it is a connectivity construct that links two or more virtual networks so that resources in each VNet can communicate via private IP addresses; it is not a source that can be used in an NSG rule. NSG rules allow sources such as IP address ranges, service tags, or application security groups, but peering itself never appears as a source or destination. While VNet peering might be relevant to routing traffic between a web tier and an application tier in different VNets, it does not solve the problem of grouping your web server VMs for NSG rule matching.

Create one local network gateway that includes both on-premises IP addresses and enable BGP on the connection.

Why wrong: A local network gateway resource represents a single on-premises site and accepts only one public IP address for the remote VPN device; you cannot include two on-premises IP addresses in a single local network gateway definition. Although enabling BGP on the connection supports dynamic routing and automatic failover between tunnels, BGP does not change the fundamental constraint that each local network gateway must point to exactly one on-premises endpoint. To utilize two on-premises IPs, you must create two local network gateways regardless of BGP use, which means this option is not a valid alternative.

Use active-passive mode and configure a second VPN gateway in the same virtual network.

Why wrong: A virtual network can contain only one VPN gateway resource, so you cannot deploy a second active-passive VPN gateway into the same VNet to achieve high availability. Active-passive mode already provides a redundant gateway instance, but that standby instance is not used for active traffic and does not leverage two on-premises devices; it only fails over to the standby tunnel. Furthermore, active-passive mode still uses a single gateway with one public IP (or optional BGP), and it does not meet the requirement of running active-active connections to separate on-premises devices concurrently.

Deploy two separate VPN gateways in different Azure regions.

Why wrong: Deploying two separate VPN gateways in different Azure regions provides regional redundancy, also known as geo-redundancy, which is a different availability scenario than active-active mode within a single gateway. These gateways would belong to different virtual networks and would require additional configuration such as VNet-to-VNet peering or a shared on-premises device, and they do not form two active tunnels from the same gateway to the same on-premises site. The question specifically asks for active-active mode, which is a property of a single VPN gateway instance using two public IPs, so this regional approach does not satisfy the stated architecture.

Network Security Groups (NSG) on the peering connections

Why wrong: NSGs are stateful for individual flows but cannot inspect or filter traffic at the peering level effectively. They are also limited to Layer 3/4 and cannot provide application-layer inspection.

Azure Application Gateway with WAF

Why wrong: Application Gateway is a Layer 7 load balancer with Web Application Firewall (WAF) for HTTP/HTTPS traffic. It does not handle general inter-VNet traffic.

Azure DDoS Protection Standard

Why wrong: DDoS Protection protects against distributed denial-of-service attacks at the network layer but does not inspect or filter normal traffic between VNets.

One inbound rule allowing HTTPS from Internet, and one inbound rule DenyAllInbound.

Why wrong: The DenyAllInbound rule is redundant because every NSG includes an unremovable default rule named DenyAllInbound at priority 65500 that blocks all inbound traffic not explicitly allowed by a higher-priority rule. Adding your own deny rule does not change the effective outcome because the default deny already applies, and it can mislead future administrators into thinking traffic is denied only by their rule. Therefore, the explicit DenyAllInbound should be omitted; a single HTTPS allow rule is sufficient.

Two inbound rules: one allowing HTTPS from Internet, one allowing HTTP from Internet.

Why wrong: Adding an HTTP (TCP 80) allow rule in addition to HTTPS unnecessarily exposes the web tier to unencrypted traffic. HTTP transmits data in plaintext, making it susceptible to interception and tampering, and it violates the principle of least privilege because only HTTPS is required. The default deny rule remains in effect for all other ports, so the only effect of this extra rule is to permit insecure traffic on port 80. Thus, the second rule should be removed, keeping only the HTTPS allow.

Two inbound rules: one allowing HTTPS from Internet, one allowing RDP from Internet.

Why wrong: Permitting RDP (TCP 3389) from the internet directly to the web tier's subnet is a serious security vulnerability. The default deny rule would correctly block this traffic if no allow rule were present; adding an RDP allow rule creates a direct administrative attack surface and violates the recommendation to manage VMs via a bastion host, Azure Bastion, or a VPN. RDP should never be exposed to the internet, especially on a subnet hosting a public web application. Only the HTTPS rule is appropriate.

Network Rule

Why wrong: Network rules in Azure Firewall operate at Layer 3/4 and match traffic based solely on source and destination IP addresses, ports, and protocol—they contain no concept of a fully qualified domain name. To restrict outbound egress to *.microsoft.com, you would need to resolve the FQDN to IPs, which is impractical because addresses can change and wildcard domain sets are not enumerable statically. Thus, a network rule cannot enforce the required domain-scoped allowlist.

NAT Rule

Why wrong: NAT rules in Azure Firewall are designed to translate the destination IP and port of inbound traffic, typically to expose internal services to the internet, rather than to inspect or allow outbound connections. They change the destination address of packets arriving at the firewall's public IP, and they do not evaluate the domain name (FQDN) of outbound requests. Consequently, a NAT rule cannot be used to restrict which external domains a VM is allowed to reach.

DNAT Rule

Why wrong: A DNAT rule is a specific NAT rule type in Azure Firewall used for inbound destination network address translation, mapping a public IP/port to an internal private IP/port. It applies to traffic whose destination is the firewall itself, not to traffic that the firewall is routing outbound, so it has no role in filtering egress traffic. Moreover, DNAT rules do not inspect application-layer parameters like FQDNs, so they cannot restrict outbound connections to *.microsoft.com.

Azure Monitor logs

Why wrong: Azure Monitor logs aggregate metrics, activity logs, and resource diagnostics from Azure services, but they do not natively contain the per-flow IP records produced by NSG flow logs. To store and query those flow records, you must explicitly configure NSG flow logs to ship to a storage account or a Log Analytics workspace, and then use Azure Monitor to analyze them. Simply enabling Azure Monitor does not give an organization the raw flow data; it only serves as a downstream analytics platform once the data is routed to it.

Traffic Analytics

Why wrong: Traffic Analytics is an add-on to Network Watcher that visualizes and summarizes NSG flow logs, offering dashboards with top talkers, denied traffic, and geographic flows. It does not capture or store the underlying flow data itself; it relies on NSG flow logs being already sent to a Log Analytics workspace. Therefore, if flow logs are not enabled, Traffic Analytics has no data to analyze, making it a post-processing tool rather than a data source.

Azure Firewall logs

Why wrong: Azure Firewall logs record traffic that actually passes through the Azure Firewall service, which is only present in a specific subnet and only sees traffic that is route-forced to it. Many VMs use network security groups (NSGs) instead of a firewall, so traffic to and from those VMs would never appear in firewall logs. Even when a firewall is present, NSG flow logs are still needed to cover the full subnet-level activity, because firewall logs omit traffic that is denied by an NSG before it reaches the firewall.

Network Security Groups (NSGs).

Why wrong: Network Security Groups (NSGs) are stateful packet filters that operate at the TCP/UDP layer, inspecting source/destination IPs, ports, and protocols. They do not perform payload inspection or parse application-layer headers, so they cannot distinguish traffic by FQDN—only by individual IP addresses or CIDR ranges. Since destinations like CDNs or SaaS endpoints often use dozens of dynamic IPs, NSGs cannot reliably enforce domain-based allow lists, which is exactly why they fail for this requirement.

Azure Application Gateway.

Why wrong: Azure Application Gateway is a layer-7 load balancer designed to route inbound HTTP(S) traffic to backend pools based on URL path, host, or other routing rules. It sits in front of web applications to provide SSL termination and a Web Application Firewall (WAF), but it is not placed in the outbound egress path from virtual machines to the internet. It has no concept of governing which external FQDNs a workload may reach, so it is irrelevant for controlling outbound application-level access.

Azure VPN Gateway.

Why wrong: Azure VPN Gateway is a tunnel-termination service that establishes encrypted IPsec/IKE connections between on-premises networks and Azure, or between VNets. Its purpose is confidentiality and integrity of traffic in transit, not inspection or policy enforcement—it forwards packets after decrypting them without applying any allow/deny rules based on FQDN or application signature. Even if every packet traversed a VPN tunnel, the gateway would not filter egress traffic, so it cannot satisfy the requirement for application-level filtering.

IKEv1 with DES

Why wrong: DES is a deprecated block cipher that uses a 56-bit key, making it trivially vulnerable to modern brute-force attacks; even the original 3DES variant is no longer recommended, and single DES is completely unacceptable for any IPsec tunnel. IKEv1 compounds this weakness with its older design, which lacks the security enhancements of IKEv2, so this option is severely under-secured and would never be selected.

IKEv2 with 3DES

Why wrong: While IKEv2 is a modern and secure key exchange protocol, 3DES is the weak link: it has a 64-bit block size, is susceptible to meet-in-the-middle attacks, and provides at most 112 bits of effective security, which falls short of the AES standard. For the same IKEv2 tunnel, AES256 offers significantly stronger encryption and addresses the performance and cryptographic deficiencies that make 3DES obsolete. Therefore, this is an inferior choice.

IKEv1 with AES128

Why wrong: IKEv1 is a legacy key exchange protocol that suffers from known design weaknesses, including a lack of built-in anti-DoS protection and reliance on the weaker pre-shared key authentication in aggressive mode, which is vulnerable to offline dictionary attacks. AES128, while adequate, provides a smaller key space than AES256 and is not considered a strong enough configuration for modern Azure VPN Gateway security. This combination is therefore not the best practice selection.

0 (no additional rules needed because the default rules block all inbound traffic)

Why wrong: The default rules in an NSG include AllowVNetInBound (priority 65000), AllowAzureLoadBalancerInBound (65001), and DenyAllInBound (65500). Because DenyAllInBound blocks all traffic from the internet that doesn't match an earlier allow rule, no HTTPS traffic from the specific IP range would ever reach the web server. You must create an explicit inbound allow rule for TCP 443 with a source IP range and a priority lower than 65500 (e.g., 100).

2 (one allow rule for HTTPS and one deny rule for all other traffic)

Why wrong: Adding an explicit deny-all-inbound rule is redundant because the built-in DenyAllInBound rule already matches and blocks every packet that no higher-priority allow rule accepts. If you put that explicit deny at a lower numeric priority (e.g., 200), it is evaluated early and simply repeats the action of the default rule; if you put it above your HTTPS allow, it would incorrectly block the very traffic you want to permit. The only truly necessary addition is the HTTPS allow rule.

3 (one allow HTTPS, one allow for Azure Load Balancer health probes, and one deny all)

Why wrong: The default AllowAzureLoadBalancerInBound rule (priority 65001) already permits Azure Load Balancer health probe traffic to reach VMs in the subnet, so an extra allow rule for health probes is unnecessary. Adding it, plus an explicit deny-all rule, compounds the error: health-probe allow is redundant, and the explicit deny duplicates DenyAllInBound. The effective result would be identical to option 1 (just the HTTPS allow rule), but with three rules instead of one, adding management complexity and clutter.

Azure Firewall with a routing table

Why wrong: Azure Firewall with a routing table is not the optimal solution here because, while it can filter internet traffic, it doesn't inherently provide private connectivity for Azure SQL Database. The requirement to prevent *direct* internet access to the Backend subnet, especially for a PaaS service like Azure SQL Database, is best met by a Private Endpoint, which brings the service into the virtual network privately. Azure Firewall is tempting as a centralised network security solution for filtering general inbound/outbound traffic, including internet access for IaaS resources, and would be appropriate for enforcing granular network and application rules across multiple subnets or controlling egress to the internet.

Service Endpoints

Why wrong: Service endpoints extend the VNet's identity and private address space to an Azure PaaS service by providing a direct route to that service over the Azure backbone, and they allow you to restrict access to the PaaS resource from selected subnets using service tags. However, they do not inspect or filter general TCP/UDP traffic, do not apply to non-PaaS destinations, and cannot deny inbound internet traffic to a subnet. In this scenario, a service endpoint would only help secure the database connection, not block internet clients from reaching the backend subnet.

Virtual Network Peering

Why wrong: VNet peering is a non-transitive, low-latency connection between two virtual networks that routes traffic between their address spaces using private IP addresses; it does not introduce any stateful filtering, packet inspection, or allow/deny rules. At best it can be used to connect a hub VNet that hosts a centralized firewall, but peering itself does not block internet traffic from reaching a backend subnet nor restrict access to Azure SQL Database. Therefore, peering is solely a connectivity mechanism, not a security control.

Enable the 'Allow gateway transit' setting on the VNet peering.

Why wrong: The 'Allow gateway transit' setting on VNet peering is used in a hub-and-spoke topology to let a spoke VNet route traffic through the hub's VPN gateway. This setting does not create or alter any encryption on the peering link itself; traffic between peered VNets continues to traverse Azure's backbone without an IPsec/IKE tunnel. It merely grants routing permission, so it cannot satisfy a requirement that traffic be encrypted between the two VNets.

Enable 'Use remote gateways' on the VNet peering.

Why wrong: The 'Use remote gateways' setting on VNet peering allows a peered VNet to rely on the remote VNet's VPN gateway for connectivity to other networks, such as an on-premises site. This is actually the complementary setting to 'Allow gateway transit' and only applies when the remote VNet has already enabled that transit option. It does not establish any cryptographic tunnel between the peered VNets, so it has no effect on encrypting the traffic flowing across the peering connection.

Configure Azure Firewall to encrypt the traffic between the VNets.

Why wrong: Azure Firewall is a managed, stateful firewall service that performs traffic filtering, network/application rules, and NAT, but it is not an IPsec VPN gateway or encryption endpoint. It does not have the capability to terminate IPsec/IKE tunnels or encrypt traffic for a VNet-to-VNet connection. While Azure Firewall can inspect the traffic, it cannot convert plaintext peering traffic into an encrypted channel, so this option fails to meet the requirement.

DDoS Protection Basic (Free)

Why wrong: Basic is automatically enabled for all Azure services and provides always-on traffic monitoring and mitigation of common network-layer attacks, but it lacks adaptive tuning, attack analytics, alerting, and telemetry. Because it's a shared, static mitigation baseline, it cannot tailor protections to your application's specific traffic profile or provide the SLA-backed guarantees and cost protection that Standard offers. Therefore, while Basic is free, it is insufficient for critical applications.

DDoS Protection Premium

Why wrong: Azure DDoS Protection does not offer a tier named Premium; the only available tiers are Basic and Standard. In the Azure portal and ARM templates, the only valid SKU names are 'Basic' and 'Standard', so Premium cannot be selected. This is a common point of confusion with other Azure services that do have Premium tiers, but for DDoS Protection, Premium is not a real option.

DDoS Protection Advanced

Why wrong: There is no 'Advanced' SKU for Azure DDoS Protection; Standard is the highest tier available for securing virtual networks. Commands such as 'az network ddos-protection create' only accept Basic or Standard as the SKU, making Advanced an invalid choice. This distractor may arise from unrelated services like Microsoft Defender for Cloud's 'Advanced' protections, but it has no bearing on DDoS Protection tiers, so it is wrong for critical applications.