CCNA Secure Networking Questions — Page 2 of 3

MCQmedium

You have an Azure subscription with multiple virtual networks. You need to centrally manage and enforce security policies for all outbound traffic from virtual machines to the internet. The solution must be able to inspect traffic and log all connections. What should you deploy?

A.Azure Firewall in a hub virtual network.

B.Network security groups (NSGs) on all subnets.

C.Azure Application Gateway with WAF.

D.Azure VPN Gateway with forced tunneling.

AnswerA

Azure Firewall is a managed, cloud-native firewall service with built-in availability and autoscaling. Deployed as a hub in a hub-and-spoke topology, it can inspect outbound traffic from peered spoke VNets through user-defined routes, and provide stateful network and FQDN-based application rules. It also centralizes logging and integrates with Azure Monitor, satisfying the requirement for outbound inspection and centralized logging.

Why this answer

Azure Firewall is a managed, cloud-native network security service that provides centralized outbound traffic inspection and logging. It can be deployed in a hub virtual network to enforce security policies across all spoke VMs, inspecting all outbound connections using application (FQDN) and network (IP/port) rules, and logging all traffic to Azure Monitor or Storage. This meets the requirements for central management, traffic inspection, and full connection logging.

Exam trap

The trap here is that candidates often confuse Azure Firewall with NSGs, assuming NSGs can centrally manage outbound traffic across VNets, but NSGs are decentralized and cannot inspect or log traffic at the application layer or across peered networks.

How to eliminate wrong answers

Option B is wrong because Network Security Groups (NSGs) operate at the subnet or NIC level, provide only stateful packet filtering (no deep packet inspection), and do not log individual connections with full details like source/destination IPs and ports by default; they also cannot centrally enforce policies across multiple virtual networks. Option C is wrong because Azure Application Gateway with WAF is a Layer 7 load balancer designed for inbound HTTP/HTTPS traffic protection, not for outbound traffic inspection or logging of all connections. Option D is wrong because Azure VPN Gateway with forced tunneling only redirects outbound traffic to an on-premises network for inspection, but it does not inspect traffic itself, nor does it log connections natively; it requires additional on-premises firewall infrastructure.

Practice this question →

MCQeasy

A company has Azure virtual machines that need to download updates from specific external websites (e.g., *.microsoft.com and *.windowsupdate.com). The security team wants to centrally manage and allow outbound HTTPS traffic only to these FQDNs, while blocking all other outbound internet access. Which Azure networking service should they deploy to achieve this?

A.Azure Firewall

B.Azure Application Gateway

C.Azure Front Door

D.Azure VPN Gateway

AnswerA

Azure Firewall is the only option that can control outbound traffic based on FQDN. You deploy it in a dedicated AzureFirewallSubnet and configure application rules with FQDN targets such as *.windowsupdate.com to allow or deny VM-initiated downloads. Unlike NSGs, which filter by IP/port, Azure Firewall inspects Layer 7 DNS and HTTP/S headers to enforce FQDN-based outbound filtering, making it the correct service for this requirement.

Why this answer

Azure Firewall is a managed, cloud-native network security service that can centrally enforce outbound FQDN-based rules. It allows you to create application rules that permit HTTPS traffic to specific FQDNs (e.g., *.microsoft.com) while blocking all other outbound internet access, meeting the security team's requirement for granular, centralized control.

Exam trap

The trap here is that candidates often confuse Azure Firewall with Azure Application Gateway, mistakenly thinking the latter can filter outbound traffic, but Application Gateway is strictly an inbound reverse proxy and cannot enforce outbound FQDN rules.

How to eliminate wrong answers

Option B (Azure Application Gateway) is wrong because it is a Layer 7 load balancer designed for inbound HTTP/HTTPS traffic routing and Web Application Firewall (WAF) protection, not for centrally controlling outbound traffic to specific FQDNs. Option C (Azure Front Door) is wrong because it is a global load balancer and application delivery controller for inbound traffic, optimizing performance and providing WAF, but it does not manage outbound traffic from virtual networks. Option D (Azure VPN Gateway) is wrong because it establishes encrypted tunnels between on-premises networks and Azure, or between VNets, and does not provide FQDN-based filtering or internet traffic control.

Practice this question →

MCQhard

A company has a hub-spoke network topology in Azure. They need to inspect and filter all traffic flowing between spoke virtual networks for malicious content and require that the inspection is stateful. Which Azure-native service should they deploy in the hub virtual network to meet this requirement?

A.Azure Firewall

B.Network Security Groups (NSG) on the peering connections

C.Azure Application Gateway with WAF

D.Azure DDoS Protection Standard

AnswerA

Azure Firewall provides stateful inspection and can filter traffic between spoke VNets when configured as a hub. It supports network and application rules, including threat intelligence-based filtering.

Why this answer

Azure Firewall is the correct choice because it is a fully stateful, managed firewall service that can inspect and filter traffic at Layers 3–7. In a hub-spoke topology, deploying Azure Firewall in the hub virtual network allows it to centrally inspect all traffic flowing between spoke virtual networks via forced tunneling (user-defined routes) or through the hub's network virtual appliance, meeting the requirement for stateful inspection of inter-spoke traffic.

Exam trap

A common pitfall is assuming that NSGs applied to subnets within the hub or spokes can centrally inspect all inter-spoke traffic. While NSGs are stateful, they operate per subnet or NIC and cannot inspect traffic flowing through the hub without explicit routing. Azure Firewall provides the centralized stateful inspection required in a hub-spoke topology.

How to eliminate wrong answers

Option B is wrong because Network Security Groups (NSGs) are stateless (they do not track connection state) and cannot be applied directly to peering connections; they are applied to subnets or NICs and lack advanced inspection capabilities like intrusion detection. Option C is wrong because Azure Application Gateway with WAF is a Layer 7 load balancer focused on HTTP/HTTPS traffic and does not provide stateful inspection of all network traffic (e.g., non-web protocols) between spoke VNets. Option D is wrong because Azure DDoS Protection Standard is a mitigation service for volumetric DDoS attacks, not a stateful firewall for inspecting and filtering inter-spoke traffic.

Practice this question →

MCQmedium

You need to secure outbound traffic from an Azure virtual network to the internet. All outbound traffic must be inspected by a firewall and logged. You also need to ensure that traffic to known malicious IP addresses is blocked. Which solution should you implement?

A.Use Network Security Groups (NSGs) with default outbound deny rules.

B.Deploy Azure Front Door with WAF policy.

C.Enable Azure DDoS Protection on the virtual network.

D.Configure Azure Firewall with threat intelligence-based filtering and route all outbound traffic through it.

AnswerD

Azure Firewall is a managed, stateful cloud-native firewall that supports threat intelligence-based filtering to alert or deny traffic to/from known malicious IPs and domains, and it can be integrated with Azure Monitor for centralized logging. By forcing all outbound traffic from the virtual network through the firewall via a user-defined route (UDR) to the firewall's private IP address, you gain full egress inspection, FQDN/network rule control, and real-time threat-intel blocking. This is the only option that directly secures and logs outbound traffic with threat intelligence in a supported, centralized manner.

Why this answer

Azure Firewall with threat intelligence-based filtering can inspect and log all outbound traffic, and it uses Microsoft's threat intelligence feeds to block traffic to known malicious IP addresses and domains. By routing all outbound traffic through the firewall (e.g., via a forced tunneling route), you meet the requirements for inspection, logging, and malicious IP blocking.

Exam trap

The trap here is that candidates often confuse Azure Firewall with NSGs or DDoS Protection, thinking that NSGs can block malicious IPs (they cannot without custom rules and lack threat intelligence) or that DDoS Protection provides outbound traffic inspection (it only protects inbound traffic against volumetric attacks).

How to eliminate wrong answers

Option A is wrong because Network Security Groups (NSGs) do not provide logging of traffic flows (they only log rules that are applied) and cannot block traffic based on threat intelligence feeds; they also lack centralized inspection capabilities. Option B is wrong because Azure Front Door is a global load balancer and application delivery controller for inbound HTTP/S traffic, not designed to inspect or control outbound traffic from a virtual network. Option C is wrong because Azure DDoS Protection only mitigates volumetric DDoS attacks against public IP addresses; it does not inspect outbound traffic, log it, or block traffic to known malicious IP addresses.

Practice this question →

MCQmedium

You are an Azure security engineer. Your team has assigned the Azure Policy shown in the exhibit. A developer creates a new virtual network with a subnet that does not have a Network Security Group (NSG) associated. What will happen when the policy is evaluated?

A.A default NSG is automatically associated with the subnet.

B.The virtual network creation fails because a subnet lacks an NSG.

C.The virtual network is created, but the subnet is denied.

D.The virtual network is created, and a non-compliant alert is generated.

AnswerB

A policy with the 'deny' effect prevents the entire virtual network resource from being deployed when any of its subnets lacks a network security group. During deployment, Azure Resource Manager evaluates the policy against the full resource definition; because the subnet does not reference an NSG, the whole virtual network creation fails atomically. This is the correct outcome because the deny effect stops non-compliant resources from ever being provisioned.

Why this answer

The Azure Policy in the exhibit is configured with a 'Deny' effect for virtual networks that have subnets without an associated Network Security Group (NSG). When the developer attempts to create a virtual network with a subnet lacking an NSG, the policy evaluation triggers a denial of the entire virtual network creation operation. This is because the policy's condition checks each subnet for the presence of an NSG, and if any subnet is non-compliant, the 'Deny' effect prevents the resource from being created.

Exam trap

The trap here is that candidates often confuse the 'Deny' effect with 'Audit' or 'Append' effects, mistakenly thinking the virtual network will be created with a warning or that Azure will automatically remediate the missing NSG.

How to eliminate wrong answers

Option A is wrong because Azure does not automatically associate a default NSG with a subnet; NSGs must be explicitly created and associated by the user or through automation like policies. Option C is wrong because the 'Deny' effect in Azure Policy blocks the entire deployment of the virtual network, not just the subnet; partial creation is not allowed. Option D is wrong because a 'Deny' effect prevents resource creation entirely, whereas a non-compliant alert would only occur with an 'Audit' or 'Disabled' effect, not with 'Deny'.

Practice this question →

MCQmedium

Refer to the exhibit. You are reviewing an NSG rule configuration for a subnet. The source subnet is 10.0.0.0/24 and the destination subnet is 10.0.1.0/24. What is the effect of this rule?

A.Allows outbound SSH traffic from 10.0.1.0/24 to 10.0.0.0/24.

B.Blocks inbound SSH traffic from 10.0.0.0/24 to 10.0.1.0/24.

C.Allows all inbound traffic from 10.0.0.0/24 to 10.0.1.0/24.

D.Allows inbound SSH traffic from 10.0.0.0/24 to 10.0.1.0/24.

AnswerD

This rule is configured with Direction=Inbound, Source=10.0.0.0/24, Destination=10.0.1.0/24, Protocol=TCP, Destination Port=22, and Action=Allow. Those attributes match an inbound SSH connection from a host in the source subnet to any host in the destination subnet on port 22. Because the rule's priority places it ahead of the default deny rules and the traffic matches every condition, the rule allows that SSH traffic.

Why this answer

The rule shown in the exhibit is an inbound security rule with source 10.0.0.0/24, destination 10.0.1.0/24, protocol TCP, destination port 22 (SSH), and action Allow. This explicitly permits inbound SSH traffic from the source subnet to the destination subnet. Therefore, option D is correct.

Exam trap

The trap here is that candidates often confuse the direction of the rule (inbound vs. outbound) or misinterpret the source and destination, leading them to think the rule blocks traffic or applies to the opposite direction.

How to eliminate wrong answers

Option A is wrong because the rule is inbound (traffic entering the subnet), not outbound, and SSH traffic from 10.0.1.0/24 to 10.0.0.0/24 would be outbound from the perspective of the destination subnet. Option B is wrong because the rule allows SSH traffic, not blocks it; a deny rule would have action Deny. Option C is wrong because the rule only allows SSH (port 22), not all traffic; allowing all inbound traffic would require a rule with destination port ranges * or any protocol.

Practice this question →

MCQmedium

Your company has an Azure subscription with several VNets. You deploy Azure Firewall in a hub VNet. You need to ensure that all traffic from spoke VNets to the internet goes through the firewall. What should you configure?

A.Configure forced tunneling on the spoke VNet gateways.

B.Enable VNet peering to the hub VNet.

C.Apply an Azure Firewall policy that denies internet access for spoke VNets.

D.Create a route table with a default route (0.0.0.0/0) to the Azure Firewall private IP and associate it with the spoke subnets.

AnswerD

This is the correct approach: create a route table containing a default route 0.0.0.0/0 with the next hop type set to VirtualAppliance and the next hop address set to the Azure Firewall's private IP. Associate that route table with all spoke subnets, which overrides Azure's system route for 0.0.0.0/0 and forces every outbound packet to be forwarded to the firewall first. The firewall then inspects the traffic using network and application rules, providing the intended centralized filtering for internet-bound and cross-premises traffic.

Why this answer

To force all internet-bound traffic from spoke VNets through Azure Firewall, you must create a user-defined route (UDR) with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP address as the next hop. This route table must be associated with the subnets in the spoke VNets, ensuring that any traffic destined for the internet is redirected to the firewall for inspection and policy enforcement.

Exam trap

The trap here is that candidates often confuse Azure Firewall policy (which controls allowed traffic) with routing (which directs traffic to the firewall), leading them to select Option C, but without a UDR, traffic never reaches the firewall for policy to be applied.

How to eliminate wrong answers

Option A is wrong because forced tunneling on a VPN gateway redirects traffic from the gateway itself to an on-premises network, not from spoke VNet subnets to Azure Firewall; it does not apply to VNet peering scenarios. Option B is wrong because VNet peering alone only enables connectivity between VNets; it does not automatically route internet traffic through the firewall—explicit UDRs are required. Option C is wrong because an Azure Firewall policy denies or allows traffic at the firewall level, but it does not force traffic to reach the firewall; without a UDR, spoke VNet traffic will use Azure's default internet path and bypass the firewall entirely.

Practice this question →

MCQmedium

You are designing a network security solution for a multi-tier application in Azure. The web tier must be accessible from the internet, the application tier only from the web tier, and the database tier only from the application tier. All tiers are in different subnets of the same VNet. What is the minimum configuration?

A.Use service endpoints for each tier.

B.Create separate VNets for each tier and use VNet peering.

C.Deploy Azure Firewall in the VNet and route all traffic through it.

D.Configure NSGs on each subnet with appropriate allow rules.

AnswerD

Network Security Groups are the native Azure mechanism for filtering traffic between subnets, as they contain stateful rules that allow or deny traffic based on source and destination IP, port, and protocol. By assigning a distinct NSG to the web, app, and data subnets, you can explicitly permit only the necessary flows—for instance, web tier to app tier on port 443, and app tier to data tier on port 1433—while blocking all other traffic by default. NSGs are applied directly to subnets or NICs, incur no additional cost, and require no custom routing, making them the most efficient and cost-effective solution for east-west traffic isolation within a VNet. This aligns with Azure's defense-in-depth guidance of securing every subnet with an NSG.

Why this answer

Network Security Groups (NSGs) applied to each subnet can enforce least-privilege network access: allow inbound from Internet to the web tier subnet, allow inbound only from the web tier subnet to the application tier subnet, and allow inbound only from the application tier subnet to the database tier subnet. This is the minimum configuration as it uses built-in, no-cost Azure constructs without additional services or complex routing.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing Azure Firewall or separate VNets, forgetting that NSGs on subnets within a single VNet provide the simplest and most cost-effective way to enforce tier-to-tier access control.

How to eliminate wrong answers

Option A is wrong because service endpoints secure traffic to Azure PaaS services (e.g., Azure SQL, Storage) by restricting access to a specific subnet, but they do not filter traffic between subnets within the same VNet—they are not a substitute for subnet-level access control. Option B is wrong because creating separate VNets for each tier and using VNet peering is unnecessarily complex and costly; peering adds latency and management overhead, and it is not the minimum configuration when a single VNet with NSGs can achieve the same isolation. Option C is wrong because deploying Azure Firewall is an over-engineered solution for this scenario; while it can provide centralized inspection, it incurs additional cost and complexity, and NSGs alone are sufficient to enforce the required east-west traffic rules between subnets.

Practice this question →

MCQhard

A company uses Azure Front Door (AFD) with WAF policy in front of a web application. The security team notices that some requests from a specific IP range are being blocked incorrectly. The WAF policy uses custom rules. The team wants to allow a specific IP range while still having the WAF inspect other traffic. What is the most efficient way to configure this?

A.Add a custom rule with priority 100, action 'Block', and match condition for the IP range.

B.Create a custom rule with priority 1, action 'Allow', and match condition for the source IP range.

C.Add a rate limit rule that allows traffic from the IP range.

D.Disable the managed rule sets for the specific IP range using a geo-match condition.

AnswerB

This works because WAF custom rules are processed in ascending priority order, where priority 1 is the highest precedence. An Allow action stops further evaluation of the policy, so any request that matches the source IP range will be permitted to reach the backend without being checked against managed rule sets. This is the standard whitelisting technique for trusted IPs that trigger false positives.

Why this answer

The correct option is B: create a custom rule with priority 1, action 'Allow', and a match condition for the source IP range. In Azure Front Door WAF, custom rules are evaluated in priority order (lower numbers first), and an Allow rule matched early short-circuits the remaining WAF evaluation, so the trusted IP range bypasses blocking while all other traffic continues to be inspected by the managed and custom rules. Option A is wrong because a Block rule for that IP range would continue blocking the traffic the team wants to permit.

Option C is wrong because a rate-limit rule controls request volume, not allow-listing, and would not reliably exempt the range from other WAF blocks. Option D is wrong because managed rule sets cannot be selectively disabled per IP range via a geo-match condition; exclusions apply to specific rule/request attributes, not source IP ranges in that manner.

Practice this question →

MCQmedium

A company deploys Azure Firewall in a hub VNet to inspect all outbound traffic from a spoke VNet. They enable VNet peering between the hub and spoke. They create a route table with a default route (0.0.0.0/0) pointing to the firewall's private IP as the next hop, and associate it with the spoke subnets. However, outbound traffic from the spoke subnets is still going directly to the internet, bypassing the firewall. What is the most likely cause?

A.The route table's next hop type is not set to 'Virtual appliance'

B.The route table is not associated with the subnet

C.The hub-spoke peering is not configured correctly

D.Azure Firewall is in a different resource group

AnswerA

For an Azure Firewall to inspect traffic via a user-defined route, the route's next hop type must be set to 'Virtual appliance' and the next hop address must be the firewall's private IP. If the next hop type is instead set to 'Internet', Azure treats the destination as directly reachable through the default route, so traffic egresses without ever hitting the firewall, even if the IP address field still contains the firewall's IP. This configuration error produces exactly the symptom described: traffic continues to flow, but none of it is actually inspected by the firewall.

Why this answer

The most likely cause is that the route table's next hop type is not set to 'Virtual appliance'. When creating a custom route in Azure, the next hop type must be explicitly set to 'Virtual appliance' and the next hop address must be the firewall's private IP. If the next hop type is left as 'Internet' or another value, Azure will ignore the custom route and use the default system route for 0.0.0.0/0, which sends traffic directly to the internet without inspection.

Exam trap

The trap here is that candidates assume any custom route with a firewall IP will work, but Azure requires the next hop type to be explicitly set to 'Virtual appliance' to override the default system route for 0.0.0.0/0.

How to eliminate wrong answers

Option B is wrong because if the route table were not associated with the subnet, the custom route would not apply at all, and traffic would use the default system route—but the question states the route table is associated with the spoke subnets, so this is not the issue. Option C is wrong because VNet peering is correctly enabled between hub and spoke; peering configuration does not affect the next hop type of a route table, and traffic can still flow through the firewall if the route is correct. Option D is wrong because Azure Firewall can be in a different resource group without impacting routing; resource group placement has no effect on network traffic flow or route table functionality.

Practice this question →

Multi-Selectmedium

You are designing a secure network for an e-commerce application in Azure. The application consists of web servers, application servers, and database servers. You need to ensure that inbound traffic is filtered at multiple layers. Which THREE Azure services should you use to implement defense in depth for network security?

Select 3 answers

A.Azure Application Gateway with WAF policy

B.Azure Front Door with WAF policy

C.Network Security Groups (NSGs)

D.Azure Bastion

E.Azure DNS

AnswersA, B, C

Azure Application Gateway with WAF policy operates at Layer 7, terminating TLS and inspecting incoming HTTP/HTTPS traffic before it reaches web servers. Its managed OWASP Core Rule Set blocks common attacks such as SQL injection, XSS, and command injection, and it can also enforce URL-path-based routing and listen-level rules. Unlike network-layer controls, it decodes application payloads and can make allow/deny decisions based on request content, making it the most direct web-application protection service within a regional VNet.

Why this answer

Azure Application Gateway with WAF policy (A) is correct because it provides layer 7 (HTTP/HTTPS) filtering at the regional level, inspecting inbound web traffic for OWASP Top 10 threats such as SQL injection and cross-site scripting before it reaches the web servers. Azure Front Door with WAF policy (B) is correct because it adds a global layer 7 entry point with anycast routing, TLS termination, and WAF inspection at the network edge, filtering malicious inbound traffic before it enters the Azure region. Network Security Groups (C) are correct because they enforce layer 3/layer 4 stateful packet filtering on subnets and NICs, allowing you to segment web, application, and database tiers with rules based on source/destination IP, port, and protocol.

Azure Bastion (D) is not correct here because it provides secure RDP/SSH access to VMs over TLS from the Azure portal and does not filter inbound application traffic. Azure DNS (E) is not correct because it is a name resolution service for hosting and resolving DNS zones, not a traffic-filtering or security control.

Exam trap

The trap here is that candidates often confuse Azure Bastion as a network security filtering service because it secures management access, but it does not filter inbound application traffic and is not part of a defense in depth strategy for application-layer protection.

Practice this question →

MCQmedium

Your organization uses Azure Virtual WAN. You need to secure traffic between a spoke VNet and an on-premises site that connects via a Virtual WAN VPN gateway. What is the best way to inspect traffic?

A.Deploy Azure Firewall in the spoke VNet.

B.Deploy a third-party NVA in the spoke VNet.

C.Apply NSG rules on the spoke subnet.

D.Use Azure Firewall Manager to deploy a secured virtual hub.

AnswerD

Azure Firewall Manager integrates natively with Virtual WAN to deploy a secured virtual hub, meaning Azure Firewall is placed directly in the hub's transit path where all inter-spoke, branch-to-spoke, and branch-to-branch traffic converges. The firewall's routing is automatically managed by the hub's route tables, and Firewall Manager provides a single control plane to apply and audit security policies across all hubs and regions. This is the correct way to secure Virtual WAN because it centralizes inspection without requiring per-spoke configuration or custom user-defined routes.

Why this answer

Azure Firewall Manager enables you to deploy a secured virtual hub, which centrally manages and routes traffic between Virtual WAN spokes and on-premises sites through Azure Firewall for inspection. This is the best approach because it provides a scalable, hub-and-spoke architecture with forced tunneling and routing policies that ensure all traffic between the spoke VNet and the on-premises site is inspected without requiring additional NVAs or complex user-defined routes.

Exam trap

The trap here is that candidates often assume deploying a firewall directly in the spoke VNet (Option A) is sufficient, but they overlook that Virtual WAN's automatic routing bypasses spoke-based firewalls unless complex and unsupported UDRs are configured, making the secured virtual hub the only native and supported solution.

How to eliminate wrong answers

Option A is wrong because deploying Azure Firewall in the spoke VNet does not automatically route traffic from the Virtual WAN VPN gateway through it; you would need complex user-defined routes and it breaks the Virtual WAN routing model. Option B is wrong because a third-party NVA in the spoke VNet also requires manual routing configuration and does not integrate natively with Virtual WAN's automatic routing, leading to asymmetric routing or traffic bypass. Option C is wrong because NSGs are stateful packet filters that operate at the subnet level and cannot perform deep packet inspection or application-level filtering; they are also not designed to inspect traffic that is routed through a Virtual WAN hub.

Practice this question →

MCQhard

A company has an Azure SQL Database with a private endpoint connection. The database is accessed from on-premises via ExpressRoute and from other Azure virtual networks (VNets) via VNet peering. The security team wants to ensure that all queries from both on-premises and peered VNets go through the private endpoint and NEVER use the public endpoint, even as a fallback. Which additional configuration is required to enforce this?

A.Configure a Network Security Group (NSG) on the subnet hosting the private endpoint to deny outbound traffic to the public endpoint's IP addresses.

B.Enable Azure SQL Auditing and configure a log analytics workspace to monitor for public endpoint calls, then manually block them.

C.Disable public network access on the Azure SQL server.

D.Configure a service endpoint for Azure SQL on the VNet and associate a firewall rule allowing only the VNet traffic.

AnswerC

Correct. Disabling public network access on the SQL server blocks all traffic from the public internet, leaving only the private endpoint as the entry point. This ensures all traffic from on-premises and peered VNets must use the private endpoint.

Why this answer

Disabling public network access on the Azure SQL server explicitly blocks all traffic that does not originate from a private endpoint. This setting ensures that even if a client attempts to connect using the public endpoint (e.g., via a misconfigured connection string or DNS resolution fallback), the server will reject the connection. This is the only configuration that enforces the requirement that all queries—from on-premises via ExpressRoute or from peered VNets—must go through the private endpoint and never use the public endpoint.

Exam trap

The trap here is that candidates often confuse 'private endpoint' with 'service endpoint' or think that NSGs or monitoring can enforce private-only access, when in fact the only way to guarantee that no traffic uses the public endpoint is to disable public network access at the server level.

How to eliminate wrong answers

Option A is wrong because NSGs are not supported on subnets hosting private endpoints; Azure blocks NSG association on private endpoint subnets, and even if applied, an NSG cannot block outbound traffic from the private endpoint to the public endpoint because the private endpoint itself does not route traffic to the public IP—the issue is client-side DNS resolution. Option B is wrong because auditing and monitoring only detect public endpoint usage after the fact; they do not prevent the connection from using the public endpoint as a fallback, which violates the 'never use' requirement. Option D is wrong because service endpoints allow traffic from the VNet to the Azure SQL public endpoint, which is exactly what the security team wants to avoid; service endpoints do not enforce private endpoint usage and would permit public endpoint access from peered VNets.

Practice this question →

MCQeasy

A company has established a site-to-site VPN connection between its on-premises network and an Azure virtual network using an Azure VPN gateway. The security team wants to confirm that all traffic crossing the VPN tunnel is encrypted. Which protocol does the Azure VPN gateway use to encrypt the data?

A.IPSec (Internet Protocol Security)

B.SSL (Secure Sockets Layer) / TLS (Transport Layer Security)

C.SSH (Secure Shell)

D.PGP (Pretty Good Privacy)

AnswerA

Azure site-to-site VPN tunnels rely on IPSec in tunnel mode to encrypt and authenticate every packet crossing the connection. IPSec uses the Internet Key Exchange (IKE) protocol to negotiate security associations, then applies Encapsulating Security Payload (ESP) for confidentiality and integrity. Because IPSec operates at the network layer (Layer 3), it transparently protects all IP payloads between the on-premises gateway and the Azure VPN gateway. This makes IPSec the mandatory protocol for Azure VPN site-to-site configurations, not SSL/TLS or other application-layer protocols.

Why this answer

Azure VPN gateways use IPsec (Internet Protocol Security) in tunnel mode to encrypt all data traversing the site-to-site VPN tunnel. IPsec provides confidentiality, integrity, and authentication at the IP layer, ensuring that all traffic between the on-premises network and Azure virtual network is encrypted and secure.

Exam trap

The trap here is that candidates may confuse SSL/TLS-based VPNs (like OpenVPN) with IPsec-based site-to-site VPNs, but Azure VPN gateways exclusively use IPsec for site-to-site connections, not SSL/TLS.

How to eliminate wrong answers

Option B is wrong because SSL/TLS operates at the transport layer (Layer 4) and is used for securing web traffic (HTTPS), not for site-to-site VPN tunnels which require IP-layer encryption. Option C is wrong because SSH is a protocol for secure remote administration and file transfer, not for encrypting bulk network traffic across a VPN tunnel. Option D is wrong because PGP is an encryption program used for securing emails and files, not for network-layer VPN encryption.

Practice this question →

MCQhard

You have an Azure Kubernetes Service (AKS) cluster that needs to restrict egress traffic to specific Azure services (e.g., Azure Container Registry, Azure Monitor). You want a managed solution that allows you to define FQDN-based rules. Which Azure service should you use?

A.Azure Application Gateway

B.Azure Front Door

C.Network Security Groups (NSGs)

D.Azure Firewall

AnswerD

Azure Firewall is a managed, cloud-native firewall service that provides application rules specifically designed for outbound FQDN filtering. It can inspect and allow/deny traffic based on fully qualified domain names, including wildcard FQDNs and FQDN tags, by examining the HTTP Host header or TLS SNI. For an AKS cluster, you can route all egress traffic through the firewall using user-defined routes or a secured virtual hub, enabling centralized, DNS-aware policy enforcement.

Why this answer

Azure Firewall is the correct choice because it is a managed, cloud-native network security service that provides FQDN-based rules to control outbound (egress) traffic. It allows you to define application rules using fully qualified domain names (FQDNs) to restrict egress traffic to specific Azure services like Azure Container Registry and Azure Monitor, without needing to manage underlying infrastructure.

Exam trap

The trap here is that candidates often confuse Network Security Groups (NSGs) as a solution for FQDN-based filtering, but NSGs only support IP-based rules and cannot resolve domain names, making Azure Firewall the only managed service that provides FQDN-based egress control.

How to eliminate wrong answers

Option A is wrong because Azure Application Gateway is a Layer 7 load balancer and web application firewall (WAF) that handles inbound HTTP/HTTPS traffic, not egress traffic filtering with FQDN rules. Option B is wrong because Azure Front Door is a global, scalable entry point for web applications that provides load balancing and WAF for inbound traffic, not egress traffic control. Option C is wrong because Network Security Groups (NSGs) filter traffic based on IP addresses, ports, and protocols at Layers 3 and 4, and do not support FQDN-based rules for egress traffic; they cannot resolve domain names to IP addresses dynamically.

Practice this question →

Multi-Selecthard

You need to monitor network traffic to detect anomalies and potential security threats. Which THREE Azure services can you use to achieve this? (Choose three.)

Select 3 answers

A.Microsoft Sentinel

B.Azure Monitor Metrics

C.Azure Firewall logs

D.Azure Policy

E.Azure Network Watcher

AnswersA, C, E

Microsoft Sentinel is the correct answer because it is a cloud-native SIEM/SOAR service that ingests network telemetry from sources such as Azure Firewall logs, NSG flow logs, and Microsoft 365 Defender. It applies built-in analytics, machine learning, and UEBA to correlate that traffic data and surface anomalies, while also enabling automated response via playbooks. Sentinel is the monitoring and analysis layer where raw network logs become actionable threat intelligence.

Why this answer

Microsoft Sentinel (A) is correct because it is a cloud-native SIEM/SOAR platform that ingests network telemetry and logs, applies analytics rules and machine learning to detect anomalies and security threats, and supports investigation and automated response. Azure Firewall logs (C) are correct because the firewall's network, application, and threat-intelligence logs capture allowed/denied traffic and malicious activity that can be analyzed for anomalies and threats. Azure Network Watcher (E) is correct because it provides network monitoring and diagnostic tools such as NSG flow logs, Traffic Analytics, packet capture, and connection monitor that reveal traffic patterns and anomalies.

Azure Monitor Metrics (B) is not correct here because it stores numeric time-series metrics rather than detailed traffic/log data needed for threat detection. Azure Policy (D) is not correct because it is a governance service that enforces and audits resource configurations, not a network traffic monitoring or threat detection tool.

Exam trap

The trap here is that candidates often confuse Azure Monitor Metrics (a performance monitoring tool) with Azure Monitor Logs (which can ingest security logs), leading them to incorrectly select Metrics as a security monitoring service, while Azure Policy is mistakenly thought to monitor traffic when it only enforces configuration rules.

Practice this question →

Multi-Selecteasy

You are configuring Azure DDoS Network Protection for your VNet. Which TWO benefits does enabling DDoS Protection Standard provide?

Select 2 answers

A.Integration with Azure Firewall for packet inspection.

B.Adaptive tuning to baseline traffic patterns.

C.Application-layer (Layer 7) protection via integrated WAF.

D.Vulnerability scanning for web applications.

E.Cost protection for scaled resources during an attack.

AnswersB, E

Adaptive tuning is a core feature of Azure DDoS Protection Standard. It uses machine learning algorithms to analyze each protected resource's typical traffic patterns over time, then automatically adjusts detection thresholds to match that baseline. This reduces false positives and ensures that legitimate traffic is not blocked during normal spikes, while still flagging anomalies that indicate a DDoS attack. It requires no manual configuration, as the thresholds self-tune continuously.

Why this answer

Option B is correct because Azure DDoS Protection Standard continuously monitors traffic and uses adaptive tuning to learn your application's normal traffic patterns, then automatically adjusts mitigation thresholds to match that baseline, enabling accurate detection of anomalies. Option E is correct because DDoS Protection Standard includes cost protection, which provides service credits for resource costs (such as scaled-out VM instances) incurred as a result of a documented DDoS attack. Option A is incorrect because DDoS Protection Standard does not perform packet inspection through Azure Firewall integration; it operates at Layers 3/4 within the Azure network fabric.

Option C is incorrect because Layer 7 application protection is provided by Azure Web Application Firewall (WAF) on Application Gateway or Front Door, not by DDoS Protection Standard itself. Option D is incorrect because vulnerability scanning is not a DDoS Protection Standard feature; it is offered through separate services such as Microsoft Defender for Cloud.

Exam trap

The trap here is that candidates often confuse Azure DDoS Protection Standard with a full web application firewall (WAF) or assume it provides Layer 7 protection, when in fact it is strictly a network-layer (L3/L4) defense with adaptive tuning and cost protection as its key differentiators.

Practice this question →

MCQhard

You are a security engineer at Fabrikam. The company has an Azure virtual network that contains a subnet named WebSubnet with a network security group (NSG) named NSG1. You need to ensure that inbound HTTP traffic from the internet is allowed to the web servers in WebSubnet, but only when the traffic originates from a specific set of public IP addresses used by a partner company. The partner's IP addresses are 203.0.113.0/24 and 198.51.100.10. What should you configure in NSG1?

A.Create an outbound security rule with source set to the two partner IP addresses, destination port 80, and action Allow, and apply it to WebSubnet.

B.Create an inbound security rule with source set to the two partner IP addresses, destination port 80, protocol TCP, and action Deny, and then create a lower-priority Allow rule for all other traffic.

C.Create an inbound security rule with source set to the two partner IP addresses, destination port 80, protocol TCP, and action Allow. Set a lower priority number than any deny rule.

D.Configure a service tag named Internet as the source and use an application security group (ASG) as the destination, with an Allow rule for port 80.

AnswerC

NSG rules are processed in priority order, lowest number first. To allow specific partner IPs, you create an inbound rule with those source addresses, destination port 80, and action Allow, and ensure its priority is lower than any broader deny rule. This permits only the partner traffic while other traffic can be denied by a subsequent rule.

Why this answer

Network security groups evaluate rules by priority, with lower numbers processed first. To allow inbound HTTP only from specific partner IP addresses, you create an Allow rule with those source addresses and a priority lower than any Deny rule that might block other traffic. This ensures the partner traffic is permitted while other internet traffic can be denied by a later, higher-numbered rule.

Exam trap

The trap here is confusing inbound and outbound rules or reversing the allow/deny action, when the requirement is specifically to permit inbound HTTP from a defined set of external IP addresses.

Practice this question →

MCQeasy

You need to block outbound internet access from all VMs in a VNet except for specific allowed destinations (e.g., Microsoft updates). You cannot use a third-party NVA. Which Azure service should you use to meet this requirement?

A.Azure Bastion

B.Azure Firewall

C.Network Security Groups (NSGs)

D.Azure Virtual Network NAT

AnswerB

Azure Firewall is a managed, stateful firewall service that acts as a central egress filter in a hub VNet. By creating a route table with a default route (0.0.0.0/0) to the firewall's private IP, all outbound VM traffic can be forced through it. Azure Firewall supports application rules with fully qualified domain names (FQDNs) and network rules with IP/port/protocol, allowing you to deny all outbound internet traffic while selectively permitting only specific FQDNs. This makes it the appropriate solution for the requirement to block outbound internet access except for approved destinations.

Why this answer

Azure Firewall is a managed, cloud-native network security service that can filter outbound traffic from VMs in a VNet based on fully qualified domain names (FQDNs), IP addresses, and port/protocol rules. It supports application rules (e.g., allow *.update.microsoft.com) and network rules, enabling you to block all outbound internet access except for specific allowed destinations like Microsoft Updates. Unlike NSGs, Azure Firewall provides stateful inspection and centralized logging, making it the correct choice for this requirement without a third-party NVA.

Exam trap

The trap here is that candidates often confuse NSGs with a firewall, thinking NSGs can filter outbound traffic by FQDN or application identity, but NSGs only support IP-based rules and cannot inspect application-layer protocols like HTTPS to allow specific destinations such as Microsoft Updates.

How to eliminate wrong answers

Option A is wrong because Azure Bastion is a PaaS service that provides secure RDP/SSH connectivity to VMs inside a VNet without exposing public IPs; it does not filter outbound internet traffic. Option C is wrong because Network Security Groups (NSGs) can filter traffic only at Layer 3 (IP) and Layer 4 (port/protocol), not at the application layer (FQDN), and they cannot selectively allow outbound traffic to specific destinations like Microsoft Updates while blocking all other internet access. Option D is wrong because Azure Virtual Network NAT (VNet NAT) provides outbound connectivity with source network address translation but does not include any filtering or firewall capabilities to block or allow specific destinations.

Practice this question →

MCQeasy

You have an Azure virtual machine that hosts a web application on port 443 and a management interface on port 8443. You need to allow inbound HTTPS traffic from the internet to port 443, and allow inbound traffic on port 8443 only from the company's office public IP range (203.0.113.0/24). You want to use a managed service that provides basic DDoS protection at no additional cost. What should you use?

A.Azure Application Gateway with WAF

B.Azure Front Door

C.Azure Firewall

D.Network Security Group (NSG)

AnswerD

An NSG can be associated with the VM's subnet or network interface. You can create rules to allow inbound HTTPS on port 443 from any source, and allow inbound on port 8443 only from the office IP range. NSGs are free and the default DDoS Protection Basic is included at no additional cost.

Why this answer

A Network Security Group (NSG) is the correct choice because it is a free, managed Azure service that provides basic DDoS protection at no additional cost. NSGs allow you to define inbound security rules to permit HTTPS traffic (port 443) from any source and restrict management traffic (port 8443) to a specific public IP range (203.113.0.0/24). This meets all requirements without incurring extra charges for advanced services.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing a paid, advanced service (like Application Gateway or Azure Firewall) when a simple, free NSG with basic DDoS protection fully satisfies the requirements, especially since the question explicitly states 'at no additional cost'.

How to eliminate wrong answers

Option A is wrong because Azure Application Gateway with WAF is a layer-7 load balancer that incurs additional cost and does not provide basic DDoS protection at no extra cost; its WAF SKU is billed separately. Option B is wrong because Azure Front Door is a global layer-7 CDN and load balancer that also has additional cost and is not a free managed service for basic DDoS protection. Option C is wrong because Azure Firewall is a paid, stateful firewall service that provides advanced filtering but is not free and does not include basic DDoS protection as a built-in feature at no cost.

Practice this question →

MCQmedium

You have an Azure subscription with a virtual network (VNet1) that hosts a SQL Managed Instance. You need to connect from an on-premises application to the SQL Managed Instance using a private IP address, with minimal latency and without traversing the public internet. The on-premises network has a high-speed ExpressRoute connection to Microsoft. What should you configure?

A.Connect the on-premises network to Azure via ExpressRoute private peering and ensure the SQL Managed Instance subnet is reachable.

B.Configure a public endpoint on the SQL Managed Instance and allow the on-premises public IP.

C.Use Azure Private Link Service and connect via a VPN.

D.Create a site-to-site VPN connection and enable forced tunneling.

AnswerA

ExpressRoute private peering establishes a dedicated, private Layer 3 connection between your on-premises network and Azure, bypassing the public internet entirely. SQL Managed Instance is deployed into a dedicated subnet within your Azure VNet, so once that subnet is reachable via ExpressRoute (through BGP route exchange or appropriate routing), on-premises clients can directly connect to the instance's private IP address. This yields low latency, high throughput, and enterprise-grade reliability, and it does not require exposing a public endpoint or relying on a VPN tunnel.

Why this answer

ExpressRoute private peering establishes a Layer 3 connection between on-premises and Azure, ensuring traffic to the SQL Managed Instance subnet traverses the Microsoft backbone network without touching the public internet. This provides the lowest latency and highest security for private IP connectivity, as the managed instance's private IP is directly routable over the ExpressRoute circuit.

Exam trap

The trap here is that candidates often confuse ExpressRoute private peering with Microsoft peering or assume that a VPN with forced tunneling is sufficient, but forced tunneling only ensures outbound traffic goes through the VPN, not that inbound traffic avoids the internet, and it still uses the public internet path.

How to eliminate wrong answers

Option B is wrong because configuring a public endpoint on the SQL Managed Instance would expose it to the internet, violating the requirement to avoid traversing the public internet and potentially increasing latency. Option C is wrong because Azure Private Link Service is used for accessing Azure PaaS services over a private endpoint, but SQL Managed Instance already resides in a VNet subnet; using a VPN would introduce additional latency and complexity compared to ExpressRoute private peering. Option D is wrong because a site-to-site VPN connection traverses the public internet (even with forced tunneling), which does not meet the 'without traversing the public internet' requirement and would have higher latency than ExpressRoute private peering.

Practice this question →

Multi-Selecteasy

You are designing a hub-and-spoke network topology with Azure Firewall in the hub VNet. Which TWO components are essential for routing traffic from spoke VNets through the firewall? (Choose two.)

Select 2 answers

A.Azure Private DNS zones

B.Azure Bastion host in the hub VNet

C.VPN gateway in each spoke VNet

D.VNet peering between spoke and hub VNets

E.Route tables with default route to Azure Firewall private IP

AnswersD, E

VNet peering is the foundational connectivity mechanism in a hub-spoke topology; each spoke's virtual network is peered to the hub's virtual network to create a low-latency, high-bandwidth link over the Microsoft backbone. Peering is non-transitive, so spokes cannot communicate directly with each other unless they are both peered to the hub and the hub's route tables forward traffic between them. When combined with user-defined routes and a network virtual appliance like Azure Firewall, peering enables controlled east-west and hub-originated traffic without a VPN gateway.

Why this answer

Option D is correct because VNet peering between each spoke and the hub VNet is the foundational connectivity that allows traffic to flow from spokes to the hub where Azure Firewall resides; without peering (or another connectivity method), spoke traffic cannot reach the firewall at all. Option E is correct because even with peering, Azure's default system routes would send internet-bound traffic directly out of the spoke, so user-defined routes (UDRs) in a route table must set 0.0.0.0/0 (and typically spoke-to-spoke prefixes) with a next hop of the Azure Firewall's private IP to force traffic through the firewall for inspection. Option A is incorrect because Azure Private DNS zones provide name resolution for private endpoints and are unrelated to traffic routing through a firewall.

Option B is incorrect because Azure Bastion provides secure RDP/SSH access to VMs and does not influence packet routing between VNets. Option C is incorrect because a VPN gateway in each spoke is not required for hub-and-spoke firewall routing; VNet peering is the standard mechanism, and gateways are only needed for hybrid/on-premises connectivity, typically deployed in the hub.

Exam trap

The trap here is that candidates often assume a VPN gateway or other gateway is required for routing traffic through a firewall in a hub-and-spoke topology, but Azure Firewall works with VNet peering and UDRs alone, without any gateway in the spoke.

Practice this question →

MCQhard

You are troubleshooting connectivity issues from an Azure VM to an on-premises server. The VM is in a VNet that uses a custom DNS server. The on-premises network is connected via ExpressRoute. You can ping the on-premises server by IP address but not by name. What is the most likely cause?

A.The ExpressRoute circuit is not configured for DNS forwarding.

B.The custom DNS server does not have a conditional forwarder to the on-premises DNS.

C.The Azure Private DNS zone does not include the on-premises hostname.

D.An NSG rule is blocking DNS traffic.

AnswerB

When you set a custom DNS server on an Azure virtual network, all VMs in that network send their DNS queries to that server. Because your VM can ping the on-premises host by IP but cannot resolve its name, the custom DNS server is receiving the query but does not know where to send it. A conditional forwarder specifically forwards queries for a given on-premises domain suffix (e.g., corp.contoso.com) to the on-premises DNS server. Without this forwarder, the custom DNS server either tries to resolve the name against the internet root hints or responds with an error, failing to resolve the on-premises hostname.

Why this answer

The custom DNS server in the Azure VNet is authoritative for the VNet's DNS resolution. When the VM tries to resolve the on-premises server's name, the custom DNS server does not know how to forward the query to the on-premises DNS infrastructure. A conditional forwarder must be configured on the custom DNS server to send queries for the on-premises domain to the on-premises DNS server, which is reachable via ExpressRoute.

Without this forwarder, name resolution fails even though IP connectivity (ping) works.

Exam trap

The trap here is that candidates often assume ExpressRoute automatically handles DNS resolution or that Azure Private DNS zones extend to on-premises, but the real issue is the lack of a conditional forwarder on the custom DNS server to bridge the two DNS namespaces.

How to eliminate wrong answers

Option A is wrong because ExpressRoute circuits do not have a 'DNS forwarding' feature; they provide Layer 3 connectivity between on-premises and Azure, but DNS forwarding is a function of DNS servers, not the circuit itself. Option C is wrong because Azure Private DNS zones are used for resolving names within Azure VNets and do not automatically include on-premises hostnames; they require manual configuration and are not the mechanism for resolving on-premises names from Azure. Option D is wrong because if an NSG rule were blocking DNS traffic (UDP/TCP port 53), the ping by IP would still succeed, but DNS queries would fail; however, the question states that ping by IP works, and the issue is specifically name resolution, which points to a DNS forwarding problem, not a firewall rule.

Practice this question →

MCQeasy

A company has an Azure virtual network with two subnets: Frontend and Backend. They deploy a network virtual appliance (NVA) in a subnet named NVA_Subnet. They want to route all traffic from the Frontend subnet to the Backend subnet through the NVA for inspection. What is the minimum number of route tables required to achieve this traffic steering?

A.1

B.2

C.3

D.4

AnswerA

A single route table associated with the Frontend subnet is all that is required. You define one user-defined route (UDR) with the Backend subnet's address space as the destination and the NVA's private IP as the next hop. Because the traffic flow originates only from Frontend to Backend, outbound traffic on Frontend is steered through the NVA, while return traffic automatically uses the default system routes without requiring a separate route table on the Backend subnet.

Why this answer

A single route table can be associated with the Frontend subnet and configured with a user-defined route (UDR) that has the NVA's private IP as the next hop for traffic destined to the Backend subnet. This ensures all traffic from Frontend to Backend is forwarded to the NVA for inspection. No additional route tables are needed because the NVA itself handles the routing decision after inspection, and the Backend subnet does not require a specific route to return traffic unless asymmetric routing is a concern.

Exam trap

The trap here is that candidates often assume each subnet requires its own route table, or that the NVA subnet itself needs a custom route, but Azure's default routing handles the return path unless asymmetric routing is explicitly required.

How to eliminate wrong answers

Option B is wrong because two route tables would be unnecessary; the requirement is only to steer traffic from Frontend to Backend through the NVA, which can be achieved with a single route table associated with the Frontend subnet. Option C is wrong because three route tables imply a misconception that each subnet or the NVA subnet requires its own route table, but the NVA subnet does not need a custom route for this scenario. Option D is wrong because four route tables would be excessive and suggests a misunderstanding of how Azure routing works; the default system routes handle intra-VNet traffic unless overridden, and only the source subnet (Frontend) needs a custom route.

Practice this question →

100

MCQmedium

A company has a hub-spoke network topology in Azure. The hub virtual network contains an Azure Firewall. Spoke virtual networks are peered to the hub. The security team wants to inspect all traffic between virtual machines in different spoke virtual networks. What is the minimum configuration required?

A.Enable VNet peering gateway transit and allow forwarded traffic.

B.Deploy a VPN gateway in each spoke and configure site-to-site VPNs to the hub.

C.Define user-defined routes (UDRs) in each spoke that direct inter-spoke traffic to the Azure Firewall in the hub.

D.Configure network security groups (NSGs) on each spoke subnet.

AnswerC

Defining user-defined routes (UDRs) on each spoke subnet whose address prefix covers the other spoke's address space and whose next hop is the Azure Firewall's private IP address ensures that any inter-spoke traffic is forced to traverse the hub firewall for inspection and policy enforcement. This is the canonical pattern for a hub-spoke architecture with forced tunneling, as the route table overrides the default system routes that would otherwise use the direct peering path. The firewall's network and application rules then filter, log, and optionally forward the traffic to the destination spoke.

Why this answer

User-defined routes (UDRs) in each spoke subnet are required to force inter-spoke traffic through the Azure Firewall in the hub. Without UDRs, traffic between peered spokes would flow directly over the VNet peering connections, bypassing the firewall. The UDRs must have the Azure Firewall's private IP as the next hop to ensure all inter-spoke traffic is inspected.

Exam trap

The trap here is that candidates often assume VNet peering automatically routes inter-spoke traffic through the hub, but without UDRs, Azure's default system routes allow direct communication between peered spokes, bypassing any inspection appliance.

How to eliminate wrong answers

Option A is wrong because enabling VNet peering gateway transit and allowing forwarded traffic only permits traffic to flow through a VPN gateway or ExpressRoute gateway in the hub, not through an Azure Firewall; it does not force inter-spoke traffic to be inspected. Option B is wrong because deploying VPN gateways in each spoke and configuring site-to-site VPNs to the hub is unnecessary, adds cost and complexity, and does not leverage the existing Azure Firewall for traffic inspection. Option D is wrong because network security groups (NSGs) are stateful, stateless packet filters that can allow or deny traffic but cannot redirect traffic to a firewall for inspection; they lack routing capabilities.

Practice this question →

101

MCQeasy

You are designing network security for a multi-tier application. The web tier must be accessible from the internet, but the database tier must only be accessible from the web tier. Both tiers are in the same virtual network. Which Azure service should you use to restrict traffic between the tiers?

A.Route table

B.Network Security Group (NSG)

C.Azure Firewall

D.Application Security Groups (ASGs)

AnswerB

Network Security Groups (NSGs) are the correct native solution because they filter traffic between subnets and NICs using priority-ordered security rules based on source/destination IP, port, and protocol. NSGs are stateful, meaning a permitted inbound flow's return traffic is automatically allowed, and they can be associated directly with the database subnet to only permit port 1433 from the app tier's subnet/IPs.

Why this answer

Network Security Groups (NSGs) are used to filter network traffic to and from Azure resources within a virtual network. They contain security rules that allow or deny inbound and outbound traffic based on source/destination IP, port, and protocol. By applying NSGs to the subnets or NICs of the web and database tiers, you can restrict database access to only the web tier.

Exam trap

AZ-500 often tests the difference between NSGs and ASGs; candidates might pick ASGs thinking they restrict traffic, but ASGs are just grouping mechanisms that must be used with NSGs to define rules. The key is that NSGs are the actual enforcement point.

How to eliminate wrong answers

Option A is wrong because a route table controls traffic routing, not security filtering; it cannot restrict access based on source or destination. Option C is wrong because Azure Firewall is a managed, cloud-based network security service that provides centralized protection, but it is overkill for simple inter-tier restrictions within a VNet and is more complex and costly. Option D is wrong because Application Security Groups (ASGs) are used to group VMs by workload and simplify NSG rule creation, but they are not a standalone service; they must be used with NSGs.

The question asks for the service to restrict traffic, which is NSG.

Practice this question →

102

MCQmedium

A company uses Azure Firewall to inspect traffic between a spoke VNet hosting a web application and a hub VNet hosting a SQL database. The web application fails to connect to the database after a recent network topology change. You verify that the Azure Firewall rules allow the traffic. Which Azure Network Watcher feature should you use to identify the root cause?

A.Connection troubleshoot

B.Next hop

C.Network Performance Monitor

D.IP flow verify

AnswerA

Connection troubleshoot in Azure Network Watcher performs an end-to-end connectivity test between a source and destination, checking reachability over the network path. However, it returns a pass/fail status and may only indicate the hop where connectivity fails, not the specific security rule (such as an Azure Firewall rule or NSG rule) that dropped the packet. This makes it less precise than IP flow verify for identifying exactly which deny rule caused the blocking.

Why this answer

Connection troubleshoot (Option A) is the correct choice because it performs an end-to-end connectivity test from the source VM to the destination, evaluating the actual path, including Azure Firewall rules, NSGs, and route tables. Since the firewall rules are confirmed to allow the traffic, Connection troubleshoot can identify if a UDR misrouting or an NSG on the source or destination subnet is blocking the connection. IP flow verify only checks NSG rules at a single network interface and does not evaluate route tables or the entire path.

Exam trap

The trap is that IP flow verify is mistakenly thought to evaluate Azure Firewall and route tables, but it only evaluates effective NSGs on a single interface. Connection troubleshoot is the appropriate tool for diagnosing end-to-end connectivity issues.

How to eliminate wrong answers

Option A (Connection troubleshoot) is wrong because it performs end-to-end connectivity checks using ICMP/TCP probes and provides latency and hop-by-hop diagnostics, but it does not evaluate firewall or NSG rule logic; it assumes the network path is already reachable. Option B (Next hop) is wrong because it only returns the next hop type and IP address for a given destination, which helps identify routing issues (e.g., a missing route to the firewall) but does not inspect security rules or determine if traffic is permitted. Option C (Network Performance Monitor) is wrong because it is a deprecated monitoring solution for network latency and packet loss across hybrid connections; it does not perform rule-level traffic validation or diagnose firewall/NSG denials.

Practice this question →

103

MCQhard

A company plans to use Azure Private Endpoint to securely connect to an Azure SQL Database from an on-premises network via ExpressRoute. The private endpoint is deployed in a hub virtual network. The on-premises network is connected to the hub via ExpressRoute. What additional configuration is needed to ensure on-premises clients can resolve the private endpoint's DNS name?

A.Configure a DNS forwarder on-premises to forward the private link domain to Azure DNS.

B.Configure a network security group to allow inbound traffic from on-premises to the private endpoint.

C.Deploy a VPN gateway in the hub VNet for additional encryption.

D.Add a public DNS record for the SQL Database pointing to the private endpoint IP.

AnswerA

On-premises clients must resolve the resource's FQDN to the private IP that Azure Private Link assigns. The public Azure DNS endpoint normally returns a public IP, so the on-prem DNS suffix should include the 'privatelink' zone and forward those queries to Azure DNS (e.g., via Azure Private DNS Resolver or the DNS IP 168.63.129.16) after the ExpressRoute connection is established. This conditional forwarder enables seamless name resolution without exposing the private IP publicly.

Why this answer

Azure Private Endpoint requires DNS resolution to map the private endpoint's private IP address to the fully qualified domain name (FQDN) of the Azure SQL Database. On-premises clients connected via ExpressRoute cannot resolve the private link domain (e.g., `*.database.windows.net`) to the private IP unless a DNS forwarder is configured on-premises to forward queries for the `privatelink.database.windows.net` zone to Azure DNS (168.63.129.16). This ensures that DNS queries from on-premises resolve to the private endpoint IP instead of the public IP of the SQL Database.

Exam trap

The trap here is that candidates often assume that ExpressRoute alone provides full connectivity and DNS resolution, but they overlook the critical requirement of DNS configuration to ensure on-premises clients resolve the private endpoint's private IP instead of the public IP.

How to eliminate wrong answers

Option B is wrong because network security groups (NSGs) control network traffic at the subnet or NIC level, but they do not affect DNS resolution; the issue is about name resolution, not traffic filtering. Option C is wrong because a VPN gateway is not needed for additional encryption when ExpressRoute already provides a private, dedicated connection; the problem is DNS resolution, not encryption or connectivity. Option D is wrong because adding a public DNS record pointing to the private endpoint IP would expose the private IP publicly and defeat the purpose of using a private endpoint; moreover, public DNS records are not used for on-premises resolution of private endpoints.

Practice this question →

104

MCQmedium

A company has a hub-spoke network topology in Azure. The spoke virtual networks contain Azure virtual machines that need to access the internet. The security team requires that all outbound internet traffic from the spoke VMs passes through the Azure Firewall deployed in the hub virtual network for inspection and logging. Which configuration should be implemented to ensure this traffic is routed through the firewall?

A.Configure an Azure Load Balancer in the hub to distribute traffic from spokes to the firewall.

B.Create a user-defined route (UDR) in the spoke subnet with 0.0.0.0/0 pointing to the private IP of the Azure Firewall.

C.Use Azure Firewall Manager to automatically enforce a global default route on all spokes. This is the only configuration needed.

D.Enable IP forwarding on the NICs of the spoke VMs so they forward traffic to the firewall.

AnswerB

A user-defined route with the 0.0.0.0/0 prefix in the spoke subnet overrides Azure's default system route, forcing all outbound internet-bound traffic to the Azure Firewall's private IP in the hub. This satisfies the requirement that spoke VM traffic be inspected and logged by the firewall.

Why this answer

A user-defined route (UDR) with the 0.0.0.0/0 prefix and the next hop set to the private IP address of the Azure Firewall forces all outbound internet traffic from the spoke subnet to be routed through the firewall in the hub. This ensures the traffic passes through the firewall for inspection and logging, as required by the security team.

Exam trap

The trap here is that candidates often confuse Azure Firewall Manager's ability to propagate routes in a virtual WAN with the need for explicit UDRs in a traditional hub-spoke topology using a hub virtual network, leading them to incorrectly select option C as a one-click solution.

How to eliminate wrong answers

Option A is wrong because an Azure Load Balancer distributes inbound traffic and does not route outbound traffic; it cannot force spoke VMs to send internet-bound traffic through the firewall. Option C is wrong because Azure Firewall Manager can enforce a default route via a virtual WAN secured hub, but in a hub-spoke topology using a hub virtual network (not a virtual WAN), a UDR must be explicitly configured on the spoke subnets; Firewall Manager alone does not automatically apply the route to all spokes in this topology. Option D is wrong because IP forwarding on the NICs of the spoke VMs is used to allow a VM to act as a router for traffic passing through it, not to direct outbound traffic from the same VM to a firewall; the spoke VMs are the source of the traffic, not intermediate routers.

Practice this question →

105

Multi-Selectmedium

You are securing an Azure Kubernetes Service (AKS) cluster. You need to restrict network traffic between pods and to external services using Azure network policies. Which three of the following options are valid considerations or steps? (Choose three.)

Select 3 answers

.Enable the Azure Network Policy Manager (Azure NPM) when creating the AKS cluster.

.Define Kubernetes NetworkPolicy objects that use selectors to allow or deny traffic between pods.

.Use Azure Firewall to enforce egress traffic rules for the AKS cluster.

.Configure an NSG directly on the AKS node subnet to filter pod-to-pod traffic.

.Set the AKS cluster to use Calico network policies instead of Azure NPM for better performance.

.Assign public IP addresses to each pod for direct internet access without a load balancer.

Why this answer

Azure Network Policy Manager (Azure NPM) is a required add-on for enforcing Kubernetes NetworkPolicy objects in an AKS cluster. It translates Kubernetes network policies into Azure-specific configurations to filter pod-to-pod traffic. Without enabling Azure NPM (or an alternative like Calico), standard Kubernetes NetworkPolicy objects will not be enforced by Azure.

Exam trap

The trap here is that candidates often confuse NSGs with Kubernetes network policies, thinking NSGs can filter pod-to-pod traffic, but NSGs operate at the subnet level and cannot see pod IPs, making them ineffective for pod-level segmentation.

Practice this question →

106

MCQhard

You have an Azure application that uses a private endpoint for Azure SQL Database. Users report intermittent connectivity failures. You need to diagnose whether the private endpoint DNS resolution is working correctly. Which tool should you use?

A.tracert

B.netstat

C.ping

D.nslookup

AnswerD

nslookup is a dedicated DNS client utility that queries a specified DNS server (or the system default) and prints the resource records in the response, such as A, CNAME, and PTR. For an Azure private endpoint, you can run nslookup <private-endpoint-FQDN> to confirm it returns the private IP address from the attached Private DNS Zone, optionally targeting Azure's internal DNS (168.63.129.16) or your own forwarder to isolate resolution failures. This direct visibility into DNS answers makes nslookup the correct tool for verifying private endpoint name resolution.

Why this answer

When using a private endpoint for Azure SQL Database, connectivity relies on DNS resolution returning the private IP address of the endpoint rather than the public IP. `nslookup` queries the DNS server directly and shows the resolved IP address, allowing you to verify that the private endpoint's private IP is being returned. If it returns the public IP or fails, DNS configuration is incorrect.

Exam trap

The trap here is that candidates often choose `ping` or `tracert` because they think connectivity tests diagnose DNS, but DNS resolution must be verified separately with a DNS-specific tool like `nslookup` or `dig`.

How to eliminate wrong answers

Option A is wrong because `tracert` traces the network path (hops) to a destination, but does not verify DNS resolution; it works after DNS is already resolved. Option B is wrong because `netstat` displays active network connections and listening ports, not DNS resolution results. Option C is wrong because `ping` tests reachability via ICMP, but it relies on the system's cached DNS resolution and does not explicitly query the DNS server; it can also be blocked by firewalls or NSGs, giving false negatives.

Practice this question →

107

MCQeasy

A company has an Azure virtual network with a subnet that hosts a web application. The security team wants to allow inbound HTTPS traffic (port 443) from the internet to the web servers, but block all other inbound traffic. They have a network security group (NSG) associated with the subnet. What is the minimal set of inbound rules required?

A.A rule allowing HTTPS from Internet, and a default deny all rule.

B.A rule allowing HTTPS from Internet, and no other rules (default deny all inbound).

C.A rule allowing HTTPS from Internet, and a rule explicitly denying all other inbound traffic.

D.A rule allowing HTTPS from any source, and a rule denying all other traffic with lower priority.

AnswerB

The default DenyAllInbound rule in every NSG already blocks all inbound traffic from the Internet, so adding only an inbound rule that allows HTTPS (TCP 443) from the Internet source service tag is sufficient. Because NSG rules are evaluated in priority order, HTTPS traffic matches the allow rule before reaching the default deny rule, while all other inbound traffic is implicitly denied. This is the minimal viable configuration because no additional deny rules are needed.

Why this answer

Network security groups (NSGs) in Azure have a default deny-all inbound rule (rule 65500) that is automatically applied to all inbound traffic. Therefore, you only need to add an explicit allow rule for HTTPS (port 443) from the Internet. No additional deny rule is required because the default rule already blocks all other inbound traffic.

Exam trap

The trap here is that candidates often think they must add an explicit deny rule to block all other traffic, not realizing that Azure NSGs already include a default deny-all inbound rule that is automatically applied at the lowest priority.

How to eliminate wrong answers

Option A is wrong because it suggests adding a default deny all rule, but Azure NSGs already include a built-in default deny all inbound rule (rule 65500) that cannot be removed or overridden by a lower-priority rule, making an explicit deny unnecessary. Option C is wrong because it proposes an explicit deny all inbound rule, which is redundant and not minimal; the default deny rule already handles this. Option D is wrong because it suggests a rule allowing HTTPS from 'any source' (which is functionally the same as from Internet) and a lower-priority deny rule, but the default deny rule already exists at the lowest priority, so an explicit deny rule is not needed and would be redundant.

Practice this question →

108

MCQmedium

You need to design a network security solution for a hub-spoke topology. The hub contains Azure Firewall and Azure Bastion. Spoke VNets contain application workloads. You need to ensure that all traffic from the spokes to the internet is routed through the Azure Firewall. What should you configure?

A.Add a user-defined route (UDR) on the spoke subnets with 0.0.0.0/0 next hop to the Azure Firewall private IP.

B.Use service endpoints for internet-bound traffic.

C.Enable BGP on the spoke VNets and advertise a default route from the hub.

D.Configure the Azure Firewall to have a default route to the internet.

AnswerA

A user-defined route (UDR) overrides Azure's system default route for 0.0.0.0/0, which normally sends all outbound traffic directly to the internet. By associating a route table with the spoke subnets and setting the next hop to the Azure Firewall's private IP, every packet destined outside the VNet is explicitly forwarded to the firewall for stateful inspection, logging, and policy enforcement. This also prevents asymmetric routing because the firewall's return traffic is handled separately, and the route can be propagated via BGP if needed, but a static UDR is the direct mechanism in a VNet-peered hub-and-spoke design.

Why this answer

A user-defined route (UDR) with 0.0.0.0/0 and next hop set to the Azure Firewall's private IP forces all internet-bound traffic from spoke subnets to be routed through the firewall. This ensures traffic inspection and control by the firewall, which is a key requirement in a hub-spoke topology for centralized security.

Exam trap

The trap here is that candidates often confuse the need for a default route on the firewall itself (Option D) with the requirement to route traffic from spokes, forgetting that UDRs on spoke subnets are necessary to direct traffic to the firewall's private IP.

How to eliminate wrong answers

Option B is wrong because service endpoints provide direct, private connectivity to Azure PaaS services (e.g., Azure Storage, SQL Database) and do not route general internet traffic; they bypass the firewall for those specific services, which contradicts the requirement. Option C is wrong because BGP is used for dynamic routing in VPN or ExpressRoute scenarios, not for forcing default route propagation within Azure VNets; Azure does not support BGP on spoke VNets for default route advertisement to subnets. Option D is wrong because configuring a default route on the Azure Firewall itself (e.g., via route table on the firewall subnet) only defines the firewall's own outbound path, not the routing of traffic from spoke subnets; the spokes need explicit UDRs to direct traffic to the firewall.

Practice this question →

109

MCQeasy

A company has an Azure virtual network with a single subnet that hosts web servers. The security team needs to allow inbound HTTPS traffic from the internet to the web servers, but block all other inbound traffic. They want to use a single Azure resource to accomplish this at the subnet level. Which resource should they configure?

A.Azure Firewall

B.Azure Front Door

C.Network Security Group (NSG)

D.Application Security Group (ASG)

AnswerC

An NSG contains inbound and outbound security rules that can be associated with a subnet or a network interface. By creating an allow rule for HTTPS (TCP 443) from Internet and a default deny-all rule, the requirement is met efficiently.

Why this answer

A Network Security Group (NSG) is the correct resource because it can be associated with a subnet to filter inbound traffic at Layer 3/4. By creating a rule that allows TCP port 443 (HTTPS) from the Internet service tag and a default deny-all rule, the NSG blocks all other inbound traffic while permitting HTTPS. This meets the requirement of a single Azure resource operating at the subnet level.

Exam trap

The trap here is that candidates often confuse Azure Firewall (a centralized, stateful service) with a simple subnet-level ACL, or they mistakenly think an Application Security Group can independently filter traffic, when in fact it only works as a source or destination in an NSG rule.

How to eliminate wrong answers

Option A is wrong because Azure Firewall is a managed, stateful firewall service that operates at the network and application layers (Layer 3-7) and is typically used for centralized traffic inspection, logging, and advanced filtering across multiple subnets or virtual networks; it is overkill and not the simplest single resource for a basic subnet-level ACL. Option B is wrong because Azure Front Door is a global, Layer 7 load balancer and application delivery controller that routes HTTP/HTTPS traffic based on the closest point of presence; it does not filter traffic at the subnet level and cannot block all other inbound traffic to the subnet. Option D is wrong because an Application Security Group (ASG) is a logical grouping of virtual machines by application workload, used in conjunction with NSG rules to simplify rule management; it is not a standalone filtering resource and cannot be directly associated with a subnet to enforce inbound traffic rules.

Practice this question →

110

MCQhard

A company has a hub-spoke network topology with Azure Firewall deployed in the hub virtual network. Spoke virtual networks are peered to the hub. The security team needs to ensure that all outbound internet traffic from virtual machines in a spoke subnet goes through the Azure Firewall. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall private IP address. However, traffic from spoke VMs is still bypassing the firewall and going directly to the internet. What is the most likely reason?

A.The route table is not associated with the spoke subnet.

B.Azure Firewall is not configured with DNAT rules for outbound traffic.

C.The spoke VNet peering does not allow gateway transit.

D.The route table has a higher priority than system routes.

AnswerA

A route table only takes effect when it is explicitly associated with a subnet. In this hub-spoke topology, the spoke subnet still has the default system routes, so traffic destined for the internet follows the default route and bypasses Azure Firewall. You must associate the custom route table—with a UDR that uses the firewall's private IP as the next hop and next hop type 'VirtualAppliance'—to the spoke subnet for forced tunneling to work.

Why this answer

The most likely reason is that the route table containing the default route (0.0.0.0/0) pointing to the Azure Firewall private IP has not been associated with the spoke subnet. Without this association, the subnet continues to use system routes, which include a default route to the internet via the Azure default gateway, allowing traffic to bypass the firewall. Associating the route table with the subnet is a required step to override the system default route.

Exam trap

The trap here is that candidates often assume creating a route table with the correct route is sufficient, forgetting that the route table must be explicitly associated with the subnet to take effect.

How to eliminate wrong answers

Option B is wrong because DNAT rules are used for inbound traffic (destination network address translation), not for controlling outbound traffic routing; outbound traffic through Azure Firewall is handled by forced tunneling via the route table, not DNAT. Option C is wrong because gateway transit is a setting for VPN/ExpressRoute gateway sharing in VNet peering, not for directing outbound internet traffic through a firewall in a hub; the spoke VNet does not need gateway transit to use a user-defined route pointing to the firewall's private IP. Option D is wrong because user-defined routes (UDRs) always have a higher priority than system routes by default; the issue is not priority but the lack of association of the route table to the subnet.

Practice this question →

111

MCQmedium

A company has an Azure virtual network with multiple subnets. They want to centrally inspect and log all outbound traffic to the internet. They also need to allow or deny traffic based on domain names (FQDNs). Which Azure resource should they deploy?

A.Azure Firewall

B.Network Virtual Appliance (NVA) from Azure Marketplace

C.Azure Application Gateway with Web Application Firewall (WAF)

D.Azure Network Security Groups (NSGs)

AnswerA

Azure Firewall is a fully managed, cloud-native firewall that can filter outbound internet traffic using application rules based on destination FQDNs, allowing or denying requests by hostname rather than only IP. It captures comprehensive diagnostic logs via diagnostic settings to Azure Monitor, where you can query the AzureDiagnostics table for denied/allowed flows. This combination of FQDN-level control and centralized, queryable logging directly meets the stated requirement.

Why this answer

Azure Firewall is a managed, cloud-native network security service that provides centralized outbound traffic inspection and logging. It supports application rules based on fully qualified domain names (FQDNs), enabling allow or deny decisions for outbound traffic to the internet using Layer 7 (application layer) filtering, which meets both requirements directly.

Exam trap

The trap here is that candidates often confuse Azure Firewall with Network Security Groups, mistakenly thinking NSGs can filter by domain names because they associate 'network security' with all traffic control, but NSGs lack Layer 7 capabilities and cannot inspect or filter based on FQDNs.

How to eliminate wrong answers

Option B (NVA from Azure Marketplace) is wrong because, while an NVA can inspect and log traffic and filter by FQDNs, it is not a native Azure managed service; it requires manual deployment, maintenance, and scaling, and does not provide the same level of integrated logging and central management as Azure Firewall for this specific use case. Option C (Azure Application Gateway with WAF) is wrong because it is designed for inbound HTTP/HTTPS traffic load balancing and web application protection, not for outbound traffic inspection or domain-based filtering of all outbound internet traffic. Option D (Azure Network Security Groups) is wrong because NSGs operate at Layer 3/4 (network and transport layers) and cannot filter traffic based on domain names (FQDNs); they only support source/destination IP addresses, ports, and protocols.

Practice this question →

112

Multi-Selectmedium

You are designing a network security solution for a multi-tier application. The web tier must be accessible from the internet, but the application and database tiers must be isolated. Which TWO configurations should you implement?

Select 2 answers

A.Use network security groups (NSGs) on each subnet

B.Deploy each tier in a separate VNet

C.Deploy each tier in a separate subnet

D.Use VNet peering to connect the tiers

E.Place all VMs in the same subnet

AnswersA, C

Network security groups apply stateful allow and deny rules at the subnet and NIC level, so the web tier accepts internet traffic while application and database subnets reject unsolicited inbound flows. This enforces the required tier isolation directly.

Why this answer

Option C is correct because placing each tier in its own subnet provides the network segmentation needed to isolate the application and database tiers from the internet-facing web tier, allowing you to apply distinct security rules per tier. Option A is correct because network security groups (NSGs) applied to each subnet let you enforce inbound and outbound rules that permit internet traffic only to the web tier while restricting the app and database tiers to internal traffic. Together, separate subnets plus per-subnet NSGs deliver the required multi-tier isolation.

Option B is not needed because separate VNets add complexity and require peering for tier-to-tier communication, which is unnecessary for isolation. Option D is incorrect because VNet peering connects VNets rather than isolating tiers within a single VNet. Option E is incorrect because placing all VMs in one subnet removes the segmentation boundary needed to isolate the app and database tiers.

Exam trap

The trap here is that candidates often assume separate VNets are required for isolation, but Azure's subnet-level NSGs provide the same isolation with lower complexity and cost, making separate subnets the correct approach.

Practice this question →

113

MCQhard

You have an Azure subscription with multiple VNets connected via VNet peering. You need to audit all network traffic between two specific VNets for compliance. The solution must capture traffic metadata (source/destination IP, ports, protocol) without affecting performance. What should you use?

A.Route all traffic through Azure Firewall and enable logs.

B.Enable NSG flow logs and use Network Watcher traffic analytics.

C.Use Network Watcher packet capture on the VMs.

D.Enable Azure Monitor metrics on the VNet peering.

AnswerB

NSG flow logs capture IP-level traffic metadata (source and destination IP, port, protocol, and flow decisions like allowed/denied) for all flows passing through a network security group, with minimal performance overhead because they operate asynchronously in the Azure backbone. Network Watcher traffic analytics then ingests these logs into a Log Analytics workspace, applying machine learning and graph algorithms to surface inter-VNet communication patterns, top talkers, anomalous traffic, and cross-subnet dependencies. Together they deliver continuous, near-real-time flow visibility across multiple peered VNets without forcing traffic through a central appliance or requiring agent installation on each VM.

Why this answer

NSG flow logs capture metadata (source/destination IP, port, protocol) for traffic traversing a Network Security Group, and Network Watcher traffic analytics provides aggregated visibility into inter-VNet flows without inline inspection. This meets the compliance requirement for auditing metadata without performance impact, as flow logs are collected asynchronously and do not alter the data path.

Exam trap

The trap here is that candidates often confuse NSG flow logs (metadata-only, no performance impact) with packet capture (full payload, high overhead) or assume that Azure Firewall is required for any traffic auditing, when in fact flow logs provide the required metadata without inline inspection.

How to eliminate wrong answers

Option A is wrong because routing all traffic through Azure Firewall introduces a forced-tunneling inline inspection point that adds latency and cost, and it is not designed solely for metadata auditing without performance impact. Option C is wrong because Network Watcher packet capture on VMs captures full packet payloads, which is resource-intensive, affects VM performance, and is not suitable for continuous compliance auditing of metadata only. Option D is wrong because Azure Monitor metrics on VNet peering provide only aggregate statistics (e.g., bytes in/out) and do not capture per-flow metadata such as source/destination IP, port, or protocol.

Practice this question →

114

MCQhard

Your company has an Azure subscription with a hub-spoke network topology. The hub contains an Azure Firewall and a VPN gateway for on-premises connectivity. The spoke virtual network hosts a critical application. You need to ensure that all outbound traffic from the spoke to the internet and on-premises networks flows through the Azure Firewall. You configure a user-defined route (UDR) on the spoke subnet with the default route (0.0.0.0/0) pointing to the Azure Firewall private IP. However, traffic to on-premises still bypasses the firewall. What is the most likely cause?

A.The on-premises traffic uses a more specific route learned via BGP from the VPN gateway, which overrides the UDR

B.The UDR must be applied to the subnet that hosts the Azure Firewall

C.The spoke subnet does not have 'GatewaySubnet' route propagation enabled

D.The Azure Firewall is not configured with a route to the on-premises network

AnswerA

BGP-learned routes for on-premises networks are more specific than 0.0.0.0/0. They will be used even if a UDR for 0.0.0.0/0 exists. To force through firewall, you must either disable BGP route propagation or create specific UDRs for on-premises ranges.

Why this answer

The most likely cause is that the on-premises traffic uses a more specific route learned via BGP from the VPN gateway, which overrides the user-defined route (UDR). In Azure, when a UDR and a BGP-propagated route both match traffic, the route with the most specific prefix (longest prefix match) wins. Since on-premises networks are typically advertised with specific IP prefixes (e.g., 10.0.0.0/16) rather than 0.0.0.0/0, the BGP-learned routes take precedence, causing traffic to bypass the Azure Firewall.

Exam trap

The trap here is that candidates assume a default route (0.0.0.0/0) UDR will always override all other routes, but Azure's route selection uses longest prefix match, so more specific BGP-learned routes for on-premises networks will take precedence over the default UDR.

How to eliminate wrong answers

Option B is wrong because the UDR must be applied to the subnet where the workload (spoke) resides, not to the Azure Firewall subnet; the firewall subnet itself uses system routes or BGP for its own traffic. Option C is wrong because 'GatewaySubnet' route propagation is not a property of the spoke subnet; it is a setting on the virtual network gateway subnet, and disabling it would not affect UDR precedence over BGP routes. Option D is wrong because the Azure Firewall does not need a specific route to the on-premises network; it only needs to be the next hop for traffic, and the issue is that traffic is not reaching the firewall due to BGP route override, not a missing route on the firewall.

Practice this question →

115

MCQeasy

You are configuring Azure Private Link for a SQL Database. You want to ensure that all traffic from your virtual network to the SQL Database stays within the Microsoft Azure backbone network. What is the primary benefit of using Azure Private Link over a service endpoint?

A.Private Link provides higher throughput than service endpoints.

B.Private Link assigns a private IP address to the SQL Database within your virtual network, preventing exposure to the public internet.

C.Private Link enables access to the SQL Database from on-premises via VPN/ExpressRoute without traversing the internet.

D.Private Link allows you to use NSGs to filter traffic to the SQL Database.

AnswerB

Private Link creates a private endpoint, which is a network interface with a private IP address assigned from your virtual network's subnet. When you connect to the SQL Database's FQDN, traffic is resolved and sent to this private IP, bypassing the public endpoint entirely. Combined with the 'Deny public network access' setting, the database is not reachable from the internet.

Why this answer

Azure Private Link exposes the SQL Database as a private endpoint within your virtual network, assigning it a private IP address from your VNet's address space. This ensures that all traffic to the database stays on the Microsoft backbone network and never traverses the public internet, which is the primary benefit over a service endpoint. Service endpoints still route traffic to the public endpoint of the SQL Database, even though the source traffic originates from the VNet.

Exam trap

The trap here is that candidates often confuse service endpoints with Private Link, thinking both provide the same level of isolation, but service endpoints still route to the public endpoint of the Azure service, whereas Private Link assigns a private IP and completely removes public internet exposure.

How to eliminate wrong answers

Option A is wrong because Private Link does not inherently provide higher throughput than service endpoints; throughput is determined by the database tier and network path, not the connectivity method. Option C is wrong because both Private Link and service endpoints can be used with VPN/ExpressRoute to access SQL Database from on-premises without traversing the internet, so this is not a unique benefit of Private Link. Option D is wrong because NSGs can filter traffic to the SQL Database when using service endpoints as well, via service tags, so this is not a distinguishing benefit of Private Link.

Practice this question →

116

MCQeasy

You need to restrict access to a web app hosted on Azure App Service so that only traffic from a specific virtual network (VNet) is allowed. Which Azure service should you configure?

A.Azure Application Gateway

B.Azure Front Door

C.App Service access restrictions

D.Azure Firewall

AnswerC

App Service access restrictions are the built-in, platform-level feature that lets you control inbound traffic to your web app by allowing or denying accesses from specific IP addresses, IP CIDR ranges, or virtual network service endpoints. These rules are evaluated at the front-end of the App Service, blocking unauthorized requests before they reach your code. By combining a default 'deny' rule with explicit 'allow' rules, you can precisely limit access to selected sources, making this the correct feature for the requirement.

Why this answer

App Service access restrictions allow you to define an allow/deny list of IP addresses or virtual network (VNet) sources directly at the App Service level. By configuring a VNet integration and a service endpoint or private endpoint, you can restrict inbound traffic to only originate from a specific VNet, without needing an additional network appliance.

Exam trap

The trap here is that candidates often confuse Azure Firewall or Application Gateway as the required service for VNet-only access, but the native App Service access restrictions feature is the simplest and most direct way to achieve this without additional cost or complexity.

How to eliminate wrong answers

Option A is wrong because Azure Application Gateway is a Layer 7 load balancer and web application firewall (WAF) that can route traffic to App Service, but it does not natively restrict traffic to a specific VNet; it would require additional network rules and does not replace the VNet-level access control. Option B is wrong because Azure Front Door is a global content delivery network (CDN) and application accelerator that operates at the edge; it cannot restrict traffic to a specific VNet as it routes over the public internet and does not integrate with VNet service endpoints. Option D is wrong because Azure Firewall is a managed, cloud-based network security service that filters traffic at the network and application layers, but it is not directly configurable to restrict access to an App Service from a specific VNet without complex routing and is not the native App Service access control mechanism.

Practice this question →

117

MCQeasy

A company has a virtual network in Azure with a subnet that hosts a web application. They want to allow inbound HTTPS traffic only from a specific source IP range (198.51.100.0/24). They are using Network Security Groups (NSGs) associated with the subnet. What is the minimal set of inbound security rules required?

A.One inbound rule: Allow TCP port 443 from source '198.51.100.0/24'

B.Two inbound rules: one to allow HTTPS, and one to deny all other traffic

C.Three inbound rules: allow HTTPS, allow RDP for management, and deny all

D.One inbound rule: Allow TCP port 443 from source 'Any' and a separate rule to deny from '198.51.100.0/24'

AnswerB

Correct. The minimal set is two rules: an allow rule for HTTPS from 198.51.100.0/24 with high priority, and a deny-all inbound rule with sufficiently high priority to override the default allow rules, ensuring only traffic from the specified IP range is allowed.

Why this answer

Network Security Groups (NSGs) contain default inbound security rules: AllowVNetInBound (priority 65000) and AllowAzureLoadBalancerInBound (priority 65001). These default rules would permit HTTPS traffic from sources within the virtual network or from Azure Load Balancer, violating the requirement to allow HTTPS only from the specific IP range 198.51.100.0/24. Therefore, an explicit deny-all rule must be added with a higher priority (lower numerical value) than the default allow rules to block all other traffic, including that from VNet and Azure Load Balancer.

The minimal set is: one rule to allow HTTPS from 198.51.100.0/24 (high priority), and one rule to deny all inbound traffic from any source (at a slightly lower priority but still above the default rules). Option A is insufficient because it relies on the default deny rule (priority 65500), which is processed after the default allow rules, so VNet and Load Balancer traffic would still be permitted.

Exam trap

The trap is that candidates assume the default deny rule implicitly blocks all unwanted traffic, but they forget that NSGs also have default allow rules for virtual network and Azure Load Balancer traffic. These default allow rules have higher priority than the default deny rule, so traffic from those sources would be allowed unless explicitly denied. Therefore, to restrict traffic to a specific external IP range, an explicit deny rule is needed to override those default allows.

How to eliminate wrong answers

Option B is wrong because it includes an explicit 'deny all' rule, which is redundant and unnecessary — NSGs already have an implicit deny rule at the end of the rule list, so adding another deny rule does not change behavior and violates the 'minimal set' requirement. Option C is wrong because it adds an RDP rule (TCP 3389) that is not required by the scenario and would allow management traffic beyond the specified HTTPS-only restriction, plus the explicit deny is again redundant. Option D is wrong because it allows HTTPS from 'Any' (which violates the requirement to restrict to 198.51.100.0/24) and then attempts to deny that same source range, which would be ineffective since the allow rule has higher priority (lower number) than the deny rule, and the deny rule would block the very traffic you want to allow.

Practice this question →

118

MCQmedium

You have an Azure Application Gateway v2 with WAF policy in prevention mode to protect a web app. Users report that legitimate requests are being blocked. You review the WAF logs and see many false positives. You need to resolve this while maintaining security. What should you do?

A.Add a custom rule to block all requests that do not match a known pattern.

B.Use managed rule sets with custom rules to allow the legitimate traffic that is being falsely blocked.

C.Disable the WAF and rely on NSGs.

D.Switch the WAF policy to detection mode.

AnswerB

Managed rule sets (for example, OWASP 3.2) can produce false positives when a benign request carries content that looks like SQL injection or cross-site scripting. Because custom rules are evaluated before managed rules in Application Gateway v2, a custom rule with action Allow can explicitly whitelist the legitimate traffic by matching on specific attributes such as URI path, headers, source IP, or query string values; the Allow action stops further evaluation, so the managed rule's Block action is not applied to that request. This lets you keep managed protection active while surgically correcting false positives.

Why this answer

Azure Application Gateway WAF allows you to use managed rule sets (e.g., OWASP 3.2) and then add custom rules to explicitly allow traffic that is being falsely blocked. This approach maintains the WAF in prevention mode, ensuring that true threats are still blocked, while overriding false positives for specific request patterns (e.g., based on URI, headers, or source IP). Custom rules are evaluated before managed rules, so you can create an 'allow' rule with a higher priority to bypass the false positive detection.

Exam trap

The trap here is that candidates often think switching to detection mode (Option D) is a safe compromise, but the question explicitly requires maintaining security, and detection mode does not block any threats, making it an incorrect choice.

How to eliminate wrong answers

Option A is wrong because blocking all requests that do not match a known pattern would likely block even more legitimate traffic and is overly restrictive, not resolving the false positive issue. Option C is wrong because disabling the WAF entirely removes all web application firewall protection, leaving the app vulnerable to attacks that NSGs (which operate at the network layer) cannot mitigate, such as SQL injection or XSS. Option D is wrong because switching to detection mode only logs alerts without blocking traffic, which fails to maintain security as the question requires resolving false positives while keeping protection active.

Practice this question →

119

MCQhard

A company has virtual networks in East US and West US connected via global VNet peering. The security policy requires that all traffic between the peered VNets be encrypted using IPsec. Which action should the company take to meet this requirement?

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

B.Deploy an Azure VPN Gateway in each VNet and create a site-to-site VPN connection between them.

C.Enable 'Use remote gateways' on the VNet peering.

D.Configure Azure Firewall to encrypt the traffic between the VNets.

AnswerB

Deploying an Azure VPN Gateway in each VNet and creating a site-to-site VPN connection (also supported via the VNet-to-VNet connection type) establishes IPsec/IKE tunnels that encrypt the traffic in transit between the two virtual networks. The VPN gateways negotiate security associations and encapsulate packets, ensuring confidentiality and integrity of traffic crossing between the regions. This is the only option that actively provides the IPsec encryption the scenario requires.

Why this answer

VNet peering does not encrypt traffic between peered virtual networks by default; it relies on the Microsoft backbone network. To enforce IPsec encryption for all traffic between the peered VNets, you must deploy an Azure VPN Gateway in each VNet and configure a site-to-site VPN connection between them. This creates an encrypted tunnel using IPsec/IKE protocols, satisfying the security policy requirement.

Exam trap

The trap here is that candidates assume VNet peering inherently encrypts traffic or that Azure Firewall can enforce encryption, but neither is true; only a VPN gateway provides IPsec encryption between VNets.

How to eliminate wrong answers

Option A is wrong because enabling 'Allow gateway transit' on VNet peering allows one VNet to use the other VNet's VPN gateway for connectivity to on-premises networks, but it does not encrypt traffic between the peered VNets themselves. Option C is wrong because 'Use remote gateways' is used when a spoke VNet wants to use the hub VNet's gateway for transit, not to encrypt traffic between the peered VNets. Option D is wrong because Azure Firewall is a stateful firewall that filters traffic but does not provide IPsec encryption; it cannot encrypt traffic between VNets.

Practice this question →

120

MCQmedium

Refer to the exhibit. You run the PowerShell command above and get the output: Access: Allow, SourceAddressPrefix: *, DestinationAddressPrefix: VirtualNetwork, DestinationPortRange: 22, Protocol: TCP, Priority: 100. A security audit requires that SSH access be restricted to only the management subnet (10.0.1.0/24). What should you do?

A.Change the SourceAddressPrefix to '10.0.1.0/24'.

B.Change the DestinationAddressPrefix to '10.0.1.0/24'.

C.Change the Access to Deny and create a new rule to allow SSH from management subnet.

D.Change the SourceAddressPrefix to 'VirtualNetwork'.

AnswerA

Changing SourceAddressPrefix to '10.0.1.0/24' correctly scopes the inbound SSH rule so that only clients from the management subnet can initiate connections to port 22. In an NSG rule, the source address prefix explicitly controls the allowable origin of traffic, and this change restricts the rule to the intended administrative range. This is the minimal and proper modification to enforce the stated network security requirement.

Why this answer

The existing rule allows SSH (TCP port 22) from any source (*) to the virtual network. To restrict SSH access to only the management subnet (10.0.1.0/24), you must change the SourceAddressPrefix from '*' to '10.0.1.0/24'. This ensures only traffic originating from the management subnet is permitted, meeting the security audit requirement.

Exam trap

The trap here is that candidates often confuse SourceAddressPrefix and DestinationAddressPrefix, mistakenly thinking that changing the destination restricts the source, or they overcomplicate the solution by adding a deny rule instead of simply modifying the existing rule's source.

How to eliminate wrong answers

Option B is wrong because changing the DestinationAddressPrefix to '10.0.1.0/24' would restrict the destination of SSH traffic to the management subnet itself, not the source, which does not limit which clients can initiate SSH connections. Option C is wrong because changing the Access to Deny would block all SSH traffic, and creating a new allow rule for the management subnet would be redundant and could cause confusion; instead, you should modify the existing rule's source. Option D is wrong because changing the SourceAddressPrefix to 'VirtualNetwork' would allow SSH from any virtual network in the same region, which is broader than the required management subnet and does not enforce the specific /24 restriction.

Practice this question →

121

MCQmedium

A company uses a hub-spoke network topology in Azure. They need to inspect and filter all traffic flowing between spoke virtual networks for security compliance. Which Azure-native service should be deployed in the hub virtual network to achieve this?

A.Azure Firewall

B.Network Virtual Appliance (NVA)

C.Azure VPN Gateway

D.Azure Load Balancer

AnswerA

Azure Firewall is a fully managed, cloud-native firewall service that provides stateful, L3-L7 inspection. In a hub-spoke topology, it is deployed in the hub VNet and user-defined routes (UDRs) in each spoke direct inter-spoke traffic to the firewall's private IP for centralized filtering. It supports application FQDN rules, network rules, and threat intelligence, making it the correct choice for an Azure-native traffic inspection service.

Why this answer

Azure Firewall is a fully managed, stateful firewall-as-a-service that can inspect and filter traffic between spoke virtual networks when deployed in the hub VNet. It supports application (FQDN) and network (IP/port/protocol) rules, and can enforce security compliance by logging and blocking non-compliant traffic. Unlike a Network Virtual Appliance (NVA), Azure Firewall is a native PaaS service with built-in high availability and auto-scaling, making it the recommended choice for hub-spoke traffic inspection.

Exam trap

The trap here is that candidates often confuse Azure Firewall with a Network Virtual Appliance (NVA), assuming both are equally 'native' or that an NVA is required for deep packet inspection, but Azure Firewall is the native PaaS solution with built-in high availability and no licensing overhead.

How to eliminate wrong answers

Option B is wrong because a Network Virtual Appliance (NVA) is a third-party VM-based firewall (e.g., Palo Alto, Fortinet) that requires manual configuration, licensing, and high-availability setup; while it can inspect traffic, it is not an Azure-native service and introduces operational overhead. Option C is wrong because Azure VPN Gateway is designed for encrypted site-to-site or point-to-site connectivity, not for stateful traffic inspection or filtering between spoke VNets. Option D is wrong because Azure Load Balancer operates at Layer 4 (TCP/UDP) and distributes traffic based on health probes and load-balancing rules; it does not inspect or filter traffic for security compliance.

Practice this question →

122

MCQeasy

You need to distribute incoming internet traffic across multiple Azure virtual machines in the same region. The solution must provide layer 7 load balancing and SSL offloading. Which Azure service should you use?

A.Azure Application Gateway

B.Azure Traffic Manager

C.Azure Load Balancer

D.Azure Front Door

AnswerA

Azure Application Gateway is the correct choice because it is a regional Layer 7 load balancer that operates at the HTTP/HTTPS application layer. It can distribute incoming internet traffic across VMs in the same region, perform SSL offloading, and route based on URL paths or host headers. This combination of regional scope and application-level inspection makes it uniquely suited to this requirement.

Why this answer

Azure Application Gateway is a layer 7 load balancer that can distribute incoming traffic across multiple Azure virtual machines in the same region. It supports SSL termination (offloading), which offloads the decryption work from the backend VMs, and provides advanced routing based on URL path, host headers, or other HTTP attributes.

Exam trap

The trap here is confusing Azure Front Door (global, multi-region) with Azure Application Gateway (regional, single-region), as both offer layer 7 features and SSL offloading, but the question explicitly specifies 'same region'.

How to eliminate wrong answers

Option B (Azure Traffic Manager) is wrong because it operates at the DNS layer (layer 3/4) and performs global traffic routing based on DNS resolution, not layer 7 load balancing or SSL offloading within a single region. Option C (Azure Load Balancer) is wrong because it operates at layer 4 (TCP/UDP) and cannot inspect HTTP/HTTPS traffic, perform SSL offloading, or route based on URL paths. Option D (Azure Front Door) is wrong because it is a global, multi-region application delivery network that provides layer 7 load balancing and SSL offloading, but it is designed for cross-region traffic distribution, not for distributing traffic across VMs within the same region.

Practice this question →

123

MCQhard

You are a security engineer for Litware. The company has an Azure virtual network named VNet1 that contains an Azure Bastion host and several VMs. The VMs have public IP addresses, but the security team wants to eliminate all public IP exposure while still allowing administrators to connect via RDP and SSH from the internet. You need to recommend a solution that meets these requirements with the least administrative effort. What should you do?

A.Remove the public IP addresses from the VMs and create a site-to-site VPN connection from each administrator's workstation to VNet1.

B.Keep the public IP addresses but restrict inbound RDP and SSH to the administrators' source IP addresses using a network security group on the VM subnet.

C.Remove the public IP addresses from the VMs and configure Azure Bastion in VNet1. Administrators connect to the VMs through the Azure portal using the Bastion host.

D.Remove the public IP addresses from the VMs and deploy an Azure Firewall with DNAT rules to forward RDP and SSH traffic to the VMs.

AnswerC

Azure Bastion provides RDP and SSH connectivity over TLS directly from the Azure portal without exposing VM public IPs. Removing the public IPs eliminates internet exposure. Bastion is deployed to a dedicated subnet named AzureBastionSubnet in the same VNet, and no additional client software is required, making it the least-effort solution.

Why this answer

Azure Bastion offers secure RDP and SSH access from the Azure portal without public IPs on VMs. Deploying Bastion in VNet1 and removing VM public IPs meets the security requirement with minimal administrative effort, as administrators use the portal directly and no VPN or firewall configuration is needed.

Exam trap

The trap here is thinking that a network security group restricting RDP/SSH to specific source IPs is sufficient, when the requirement explicitly demands eliminating public IP exposure entirely.

Practice this question →

124

MCQeasy

You need to provide secure remote administration access to Azure virtual machines in a production environment. You want to eliminate public RDP/SSH endpoints and provide just-in-time access. Which Azure service should you use?

A.Network Security Groups (NSGs)

B.Azure Firewall

C.Just-in-time VM access in Microsoft Defender for Cloud

D.Azure Bastion

AnswerC

Just-in-time (JIT) VM access in Microsoft Defender for Cloud is a workload-protection feature that deliberately denies inbound RDP/SSH traffic to Azure VMs using automatically configured NSG rules. When an authenticated user with the appropriate Azure AD identity requests access, Defender for Cloud applies targeted NSG rules for a limited, configurable time window and then reverts them automatically after expiration. It supports approval workflows, can enforce MFA, and produces audit logs, making it the only option here that directly delivers time-bound administrative access.

Why this answer

Just-in-time (JIT) VM access in Microsoft Defender for Cloud is the correct choice because it specifically provides time-bound, policy-controlled access to Azure VMs via RDP/SSH while eliminating permanent public endpoints. JIT dynamically opens NSG rules for a specified duration only when an authorized user requests access, then automatically closes them, enforcing the principle of least privilege for remote administration.

Exam trap

The trap here is that candidates often confuse Azure Bastion's 'no public IP' secure access with just-in-time access, but Bastion provides persistent, always-on connectivity, whereas JIT VM access enforces time-limited, approval-based access with automatic port closure.

How to eliminate wrong answers

Option A is wrong because Network Security Groups (NSGs) alone provide static, persistent rules that do not offer just-in-time access or automatic rule expiration; they require manual management to open/close ports, which is not a JIT solution. Option B is wrong because Azure Firewall is a managed, stateful firewall service for network-level traffic filtering across virtual networks, but it does not provide per-VM, time-bound JIT access for RDP/SSH; it lacks the granular, user-request-based access control of JIT. Option D is wrong because Azure Bastion provides secure, browser-based RDP/SSH connectivity to VMs without public IPs, but it offers persistent, always-on access rather than just-in-time, time-limited access; Bastion does not enforce time-bound approval workflows or automatic port closure.

Practice this question →

125

MCQeasy

Your organization has multiple Azure subscriptions and wants to centrally manage Azure Firewall policies across all subscriptions. What should you use?

A.Azure Policy to enforce firewall rules

B.Azure Firewall Manager

C.Azure Resource Manager templates

D.Azure Network Watcher

AnswerB

Azure Firewall Manager is the central management service that lets you create, organize, and apply firewall policies to multiple Azure Firewalls across different subscriptions in a single tenant. It provides hierarchical policy inheritance (global, regional), and can also deploy and manage firewalls in both secured virtual hubs (Virtual WAN) and hub virtual networks, while integrating with security partners. This directly addresses the need for consistent, centrally managed firewall rules across subscriptions.

Why this answer

Azure Firewall Manager is the correct choice because it provides a centralized platform to create, manage, and enforce firewall policies across multiple Azure subscriptions and regions. It allows you to define a parent policy that child firewall instances inherit, ensuring consistent security rules without manual per-firewall configuration. This aligns directly with the requirement for central management of Azure Firewall policies.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces resource compliance) with Azure Firewall Manager (which manages firewall policies), leading them to incorrectly select Azure Policy for centralized firewall rule management.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used to enforce compliance rules on Azure resources (e.g., requiring a specific SKU or tagging), but it cannot directly manage or deploy Azure Firewall policy rules (like network or application rules) across firewalls. Option C is wrong because Azure Resource Manager templates are infrastructure-as-code artifacts for deploying resources, but they do not provide ongoing centralized management or policy inheritance across multiple subscriptions; each deployment would require manual template updates. Option D is wrong because Azure Network Watcher provides network monitoring and diagnostic tools (e.g., packet capture, topology, NSG flow logs), but it has no capability to manage or enforce firewall policies.

Practice this question →

126

MCQmedium

A company deploys a web application on Azure VMs behind an Azure Load Balancer (Standard SKU). They want to protect the application from common web attacks like SQL injection and cross-site scripting. Which Azure service should they enable?

A.Azure Application Gateway with Web Application Firewall (WAF) policy.

B.Azure Firewall.

C.Network Security Groups on the VM subnet.

D.Azure DDoS Protection.

AnswerA

Azure Application Gateway is a Layer 7 load balancer that can terminate TLS, route HTTP traffic, and enforce a Web Application Firewall policy using the Open Web Application Security Project (OWASP) Core Rule Set. The WAF inspects headers, body, cookies, and URL parameters to detect and block common attacks such as SQL injection, cross-site scripting, and remote file inclusion. This is the appropriate service because it operates at the application layer and can be integrated directly into the application delivery path for the VMs.

Why this answer

Azure Application Gateway with a Web Application Firewall (WAF) policy is the correct choice because it operates at Layer 7 (HTTP/HTTPS) and provides centralized, inbound protection against common web attacks such as SQL injection and cross-site scripting (XSS). The WAF policy uses OWASP Core Rule Sets (CRS) to inspect HTTP request payloads and headers, blocking malicious traffic before it reaches the backend VMs behind the Load Balancer.

Exam trap

The trap here is that candidates confuse Azure Firewall (a Layer 3-4 network firewall) with a web application firewall, mistakenly believing it can inspect HTTP payloads, when in fact only a Layer 7 WAF (like Application Gateway WAF or Azure Front Door WAF) can protect against SQL injection and XSS.

How to eliminate wrong answers

Option B (Azure Firewall) is wrong because it is a stateful, Layer 3-4 network firewall that filters traffic based on IP addresses, ports, and protocols, but it does not inspect HTTP application-layer payloads for SQL injection or XSS patterns. Option C (Network Security Groups on the VM subnet) is wrong because NSGs provide stateless or stateful Layer 3-4 filtering (IP/port rules) and cannot perform deep packet inspection at the application layer to detect web attack signatures. Option D (Azure DDoS Protection) is wrong because it only mitigates volumetric DDoS attacks at the network layer (Layer 3-4) and does not inspect or block application-layer threats like SQL injection or XSS.

Practice this question →

127

MCQhard

Your company has multiple Azure subscriptions managed through Azure Firewall Manager. You need to deploy Azure Firewall policies that apply to all subscriptions in a region. What is the most efficient way to manage this?

A.Create a separate firewall policy for each subscription

B.Use Azure Firewall Manager to create a parent policy and assign it to all firewalls

C.Use Azure Policy to enforce firewall rules across subscriptions

D.Deploy a single network security group (NSG) to all VNets

AnswerB

Azure Firewall Manager solves this by letting you create one parent firewall policy that can be associated with Azure Firewalls in any subscription and region, centralizing network rules, application rules, NAT rules, and threat intelligence settings. Each firewall receives the same policy assignment while still supporting child policies for per-firewall customization, making this the correct way to enforce consistent rules across subscriptions without duplicating configuration.

Why this answer

Azure Firewall Manager provides a centralized management plane for firewall policies across multiple subscriptions and regions. By creating a parent policy and assigning it to all firewalls, you ensure consistent rule enforcement without duplicating effort. This approach is the most efficient because it leverages inheritance, where child policies can override specific rules while inheriting the parent's base configuration.

Exam trap

The trap here is that candidates confuse Azure Policy (which enforces resource compliance) with Azure Firewall Manager (which manages firewall policies and rules), leading them to choose option C even though Azure Policy cannot directly apply firewall rule collections.

How to eliminate wrong answers

Option A is wrong because creating separate policies per subscription defeats the purpose of centralized management, leading to administrative overhead and inconsistency. Option C is wrong because Azure Policy can enforce compliance (e.g., requiring a firewall to exist) but cannot directly define or assign firewall rule collections or policies. Option D is wrong because NSGs are stateful, layer-4 access control lists applied to subnets or NICs, not a substitute for the application-layer inspection and centralized policy management that Azure Firewall provides.

Practice this question →

128

Multi-Selecteasy

Which TWO actions can be taken using Azure Network Watcher?

Select 2 answers

A.Diagnose whether a security rule is blocking traffic to a VM.

B.Create and manage private endpoints.

C.Configure WAF policies on Application Gateway.

D.Determine the next hop for traffic from a VM.

E.Configure Azure Firewall rules.

AnswersA, D

Network Watcher's IP flow verify checks whether a packet is allowed or denied by a network security group (NSG) based on the selected VM, network interface, and security rules. You provide source and destination IPs, port, protocol, and direction, and it returns the specific NSG rule that permitted or blocked the traffic. This directly answers whether a security rule is blocking traffic to a VM, making it a core diagnostic feature.

Why this answer

Azure Network Watcher includes the IP flow verify capability, which checks whether a packet is allowed or denied to or from a VM and identifies the specific security rule (NSG rule) responsible, so option A is correct. It also includes the Next hop capability, which determines the next hop type and IP address for traffic originating from a VM, validating routing behavior, so option D is correct. Options B, C, and E are incorrect because private endpoints, Application Gateway WAF policies, and Azure Firewall rules are configured through their respective services (Private Link, Application Gateway, and Azure Firewall), not through Network Watcher.

Exam trap

The trap here is that candidates confuse Network Watcher's diagnostic tools (IP flow verify, next hop) with configuration services (Private Link, WAF, Azure Firewall), which are separate Azure resources.

Practice this question →

129

MCQmedium

You are designing network security for a multi-tier application deployed in Azure. The application consists of a front-end web tier, a middle-tier API, and a back-end database. All tiers must be isolated from the internet except the front-end, which must accept HTTPS traffic from the internet. You need to ensure that no traffic can bypass the network security controls. What should you implement?

A.Place all tiers in the same virtual network and use Azure Front Door with WAF for the web tier, and rely on NSGs for internal traffic.

B.Deploy Network Security Groups (NSGs) on each subnet and allow only necessary traffic between tiers.

C.Deploy Azure Firewall in a hub virtual network and route all traffic between tiers through the firewall for inspection.

D.Use Azure Application Gateway with Web Application Firewall (WAF) in front of the web tier, and use NSGs for the other tiers.

AnswerC

This is the correct approach because Azure Firewall is a managed, stateful firewall service designed for centralized inspection and control of all traffic, including east-west traffic between tiers. By placing Azure Firewall in a hub virtual network and configuring user-defined routes to force all inter-tier traffic through it, you create a security choke point that enforces consistent policies, provides FQDN filtering, and generates comprehensive logs for auditing. This gives you a single, centrally managed security boundary across the entire application.

Why this answer

Deploying Azure Firewall in a hub virtual network and routing all traffic between tiers through the firewall for inspection ensures that no traffic can bypass network security controls. This design enforces a forced tunneling architecture where all inter-tier traffic (e.g., from front-end to API to database) must traverse the firewall, allowing centralized inspection, logging, and filtering. This meets the requirement for complete isolation and control, as NSGs alone cannot prevent traffic from bypassing inspection if routes are not explicitly forced.

Exam trap

The trap here is that candidates often assume NSGs alone are sufficient for full traffic control, but they fail to recognize that NSGs cannot enforce mandatory inspection or prevent traffic from bypassing controls when routes are not explicitly forced through a central firewall.

How to eliminate wrong answers

Option A is wrong because placing all tiers in the same virtual network and relying solely on NSGs for internal traffic does not prevent traffic from bypassing network security controls; NSGs are stateless or stateful at the subnet/NIC level but do not provide centralized inspection or logging, and Azure Front Door with WAF only protects the web tier from internet traffic, not internal traffic between tiers. Option B is wrong because deploying NSGs on each subnet and allowing only necessary traffic between tiers is insufficient to ensure no traffic bypasses controls; NSGs cannot inspect or log traffic at the application layer, and they do not prevent a compromised tier from sending unauthorized traffic directly to another tier without inspection. Option D is wrong because using Azure Application Gateway with WAF in front of the web tier and NSGs for the other tiers does not enforce mandatory inspection of traffic between the middle-tier API and back-end database; NSGs alone cannot provide the centralized, forced routing required to ensure all inter-tier traffic is inspected, and the Application Gateway only handles inbound internet traffic to the web tier.

Practice this question →

130

MCQeasy

You need to provide secure remote access to Azure virtual machines without assigning them public IP addresses. Which Azure service should you use?

A.Azure VPN Gateway

B.Azure Firewall

C.Azure Bastion

D.Azure Front Door

AnswerC

Azure Bastion is a fully managed PaaS jump host deployed into a VNet that provides secure RDP and SSH connectivity to Azure VMs over TLS on port 443, directly within the Azure portal. It eliminates the need for each VM to have a public IP address or any inbound NSG rules for RDP/SSH, and it uses Microsoft Entra ID credentials, allowing integration with conditional access and multi-factor authentication. The broker service manages the session, making Azure Bastion the correct service for providing secure remote access to Azure virtual machines.

Why this answer

Azure Bastion provides secure, seamless RDP/SSH connectivity to Azure virtual machines directly in the Azure portal over TLS, without exposing public IP addresses. It uses a hardened, fully managed platform as a service (PaaS) that sits inside your virtual network, eliminating the need for a jump box or public-facing endpoints.

Exam trap

The trap here is that candidates often confuse Azure Bastion with Azure VPN Gateway, assuming a VPN is required for secure remote access, but Bastion is the correct choice when the goal is to avoid any public IP assignment and provide direct portal-based RDP/SSH.

How to eliminate wrong answers

Option A is wrong because Azure VPN Gateway extends your on-premises network to Azure over IPsec/IKE tunnels, but it does not provide browser-based RDP/SSH access to VMs without public IPs; it requires a VPN client and still relies on private IP connectivity. Option B is wrong because Azure Firewall is a stateful network firewall as a service that filters traffic at layers 3-7, but it does not offer RDP/SSH proxy or portal-based VM connectivity. Option D is wrong because Azure Front Door is a global load balancer and application delivery controller for HTTP/HTTPS traffic, not a remote access solution for VM management.

Practice this question →

131

MCQmedium

A company has an Azure virtual network with multiple subnets hosting different application tiers. They need to inspect and filter all outbound traffic from VMs to the internet, and they must be able to allow or deny traffic based on fully qualified domain names (FQDNs). Which Azure networking service should they deploy?

A.Azure Firewall.

B.Network Security Groups (NSGs).

C.Azure Application Gateway.

D.Azure VPN Gateway.

AnswerA

Azure Firewall is a managed, cloud-native network security service that enforces application-layer rules based on FQDN. Its application rule collection can allow or deny outbound traffic to specific domain names (e.g., *.windowsupdate.com) independently of IP address, which is critical because many cloud services resolve to changing IPs. Azure Firewall also supports network rules, threat intelligence, and is centrally deployed to inspect all egress traffic, making it the correct choice for application-level outbound filtering.

Why this answer

Azure Firewall is a managed, cloud-based network security service that can inspect and filter outbound traffic from Azure virtual networks to the internet. It supports application rules based on fully qualified domain names (FQDNs), allowing or denying traffic by FQDN, which directly meets the requirement. Unlike simpler filtering options, Azure Firewall provides stateful inspection and integrates with Azure Monitor for logging.

Exam trap

The trap here is that candidates often confuse Network Security Groups (NSGs) with Azure Firewall, assuming NSGs can filter by FQDN because they support service tags, but service tags are IP-based and do not allow granular FQDN-level control.

How to eliminate wrong answers

Option B is wrong because Network Security Groups (NSGs) filter traffic based on source/destination IP addresses, ports, and protocols, but they cannot filter by FQDN; they lack application-layer inspection for domain names. Option C is wrong because Azure Application Gateway is a Layer 7 load balancer that routes HTTP/HTTPS traffic based on URL paths or host headers, but it is not designed for general outbound internet traffic inspection or FQDN-based filtering for all protocols. Option D is wrong because Azure VPN Gateway is used to create encrypted tunnels between on-premises networks and Azure, not for inspecting or filtering outbound internet traffic.

Practice this question →

132

MCQmedium

A company runs a global web application on Azure App Service instances deployed in multiple Azure regions. They want to protect the application from common web attacks such as SQL injection and cross-site scripting (XSS) using a centralized set of managed rules that can be automatically updated. They also need to improve performance by terminating traffic at the nearest point of presence (POP) to end users. Which Azure service should they deploy in front of the App Service?

A.Azure Application Gateway with Web Application Firewall (WAF)

B.Azure Front Door with Web Application Firewall (WAF)

C.Azure Traffic Manager

D.Azure CDN (Content Delivery Network)

AnswerB

Azure Front Door with WAF is a global layer-7 service that uses the Microsoft global edge network with anycast, ensuring connections are terminated at the nearest point of presence (POP) rather than the origin region. It applies Web Application Firewall rules, including OWASP managed rule sets, at that edge, which blocks malicious requests before they traverse the backbone to your web app. This combination of global load balancing, TLS termination, and built-in WAF protection directly addresses both performance and security requirements for a worldwide audience.

Why this answer

Azure Front Door with WAF is correct because it provides global, centralized protection against common web attacks (SQL injection, XSS) using managed rule sets that are automatically updated, and it terminates traffic at the nearest point of presence (POP) to end users, improving performance through global load balancing and TLS termination. This meets both the security and performance requirements for a multi-region App Service deployment.

Exam trap

The trap here is that candidates often confuse Azure Application Gateway (regional, Layer 7 load balancer with WAF) with Azure Front Door (global, multi-region, with WAF), failing to recognize that only Front Door provides both global POP termination and centralized WAF for multi-region deployments.

How to eliminate wrong answers

Option A is wrong because Azure Application Gateway with WAF is a regional service, not a global one; it cannot terminate traffic at the nearest POP across multiple Azure regions and does not provide the global performance optimization needed. Option C is wrong because Azure Traffic Manager is a DNS-based traffic routing service that does not include a Web Application Firewall or any application-layer attack protection, and it does not terminate traffic at POPs. Option D is wrong because Azure CDN is primarily a content caching and delivery service; while it can improve performance via POPs, it does not include a built-in WAF with managed rules for SQL injection and XSS protection, and its security capabilities are limited to DDoS protection and access restrictions.

Practice this question →

133

MCQmedium

You are designing a network security strategy for a multi-tier application. The web tier must be accessible from the internet, but the application and database tiers must only be accessible from the web tier. Which Azure solution should you use to isolate the tiers?

A.Azure DDoS Protection

B.Azure Firewall with application rules

C.Network security groups (NSGs) on each subnet

D.Azure Private Link

AnswerC

Network security groups (NSGs) are stateful, L3/L4 filtering entities that can be associated to either a subnet or a NIC, making them an ideal tool to isolate tiers within a VNet. For example, you can create a rule on the database subnet that only allows inbound TCP 1433 from the application subnet's address prefix, while denying all other inbound traffic. NSGs provide the required network-level segmentation with no need for a separate gateway or virtual appliance, and they combine easily with service tags and application security groups for maintainability.

Why this answer

Network security groups (NSGs) on each subnet are the correct solution because they provide stateful, layer-3/layer-4 traffic filtering at the subnet level. By placing the web tier in a subnet with an NSG that allows inbound HTTP/HTTPS from the internet, and placing the application and database tiers in separate subnets with NSGs that only allow inbound traffic from the web tier subnet (using source IP ranges or service tags), you effectively isolate the tiers while permitting the required east-west traffic.

Exam trap

The trap here is that candidates often confuse centralized firewall solutions (like Azure Firewall) with subnet-level access control, forgetting that NSGs are the native, lightweight, and correct tool for per-subnet traffic filtering in a multi-tier architecture.

How to eliminate wrong answers

Option A is wrong because Azure DDoS Protection is a defense against volumetric distributed denial-of-service attacks, not a mechanism for network segmentation or tier isolation. Option B is wrong because Azure Firewall with application rules operates at the application layer (FQDN filtering) and is typically deployed as a centralized security boundary, not for per-subnet isolation; it would add unnecessary complexity and cost for simple tier-to-tier access control. Option D is wrong because Azure Private Link exposes a managed service over a private endpoint within a virtual network, but it does not provide the subnet-level traffic filtering needed to restrict access between tiers; it is designed for private connectivity to PaaS services, not for segmenting application tiers.

Practice this question →

134

MCQmedium

An organization has deployed Azure Firewall and wants to inspect all outbound traffic from a virtual network (VNet) to the internet. The VNet already contains subnets with workloads. What is the required networking configuration to force traffic through Azure Firewall?

A.Configure a route table with a default route (0.0.0.0/0) pointing to the Azure Firewall private IP and associate it with the subnets.

B.Add a Network Security Group (NSG) rule that allows all outbound traffic and associate it with the subnets.

C.Deploy an Application Gateway with Web Application Firewall (WAF) in front of the subnets.

D.Enable Azure DDoS Protection Standard on the VNet.

AnswerA

A User Defined Route (UDR) with address prefix 0.0.0.0/0 and next hop type 'VirtualAppliance' set to the Azure Firewall's private IP must be associated with each subnet requiring outbound inspection. This custom route overrides Azure's default system route for internet-bound traffic, forcing every egress packet to be forwarded to the firewall for centralized filtering, logging, and NAT. Without this route, the VNet's implicit 0.0.0.0/0 route sends traffic directly to the internet via its default outbound public IP, bypassing the firewall.

Why this answer

Azure Firewall requires a route table with a default route (0.0.0.0/0) that has the Azure Firewall's private IP as the next hop, associated with each subnet whose traffic must be inspected. This forces all outbound traffic from those subnets to be routed through the firewall, enabling inspection and logging. Without this explicit route, traffic would use the default system route and bypass the firewall.

Exam trap

The trap here is that candidates often assume NSG rules or DDoS protection can redirect traffic, but only a user-defined route (UDR) with a next hop of the firewall's private IP can force traffic through Azure Firewall.

How to eliminate wrong answers

Option B is wrong because an NSG rule allowing all outbound traffic does not force traffic through Azure Firewall; NSGs filter traffic at the subnet or NIC level but do not change the routing path. Option C is wrong because Application Gateway with WAF is a layer-7 load balancer and web application firewall for inbound HTTP/S traffic, not designed to inspect or route all outbound internet traffic. Option D is wrong because Azure DDoS Protection Standard provides mitigation against volumetric DDoS attacks but does not alter routing or force traffic through a firewall.

Practice this question →

135

MCQmedium

You need to allow inbound HTTP traffic from the internet to a specific VM in a VNet. The VM is in a subnet with an NSG. What is the correct way to configure access?

A.Add a rule in Azure Firewall to allow HTTP traffic to the VM.

B.Enable Azure DDoS Protection on the VNet.

C.Configure Azure Traffic Manager to route traffic to the VM.

D.Add an inbound security rule in the NSG to allow HTTP traffic.

AnswerD

An NSG is a stateful, Layer-3/4 filter that can be associated with a VM's NIC or its subnet to control inbound and outbound traffic. Adding an inbound security rule with source 'Internet', destination port 80, protocol TCP, and action 'Allow' will permit HTTP traffic to reach the VM, provided the VM has a public IP or is behind a load balancer with proper port forwarding. This is the standard, least-privilege solution for allowing a single port to a VM from the internet.

Why this answer

Network Security Groups (NSGs) operate at the subnet or NIC level and act as a stateful firewall for traffic entering or leaving Azure resources. To allow inbound HTTP (TCP port 80) traffic from the internet to a specific VM, you must add an inbound security rule to the NSG associated with the VM's subnet or NIC, specifying the source as 'Internet', destination port 80, and protocol TCP. This is the direct and correct method for controlling traffic to a VM within a VNet.

Exam trap

The trap here is that candidates often confuse Azure Firewall (a centralized, cross-subnet service) with NSGs (a subnet/NIC-level firewall) and incorrectly assume a firewall is required for inbound internet traffic, when in fact NSGs are the correct and simpler solution for allowing HTTP to a specific VM.

How to eliminate wrong answers

Option A is wrong because Azure Firewall is a managed, centralized firewall service used for controlling outbound and inter-VNet traffic, not for allowing inbound internet traffic to a single VM; NSGs are the appropriate boundary for subnet/NIC-level inbound rules. Option B is wrong because Azure DDoS Protection provides mitigation against distributed denial-of-service attacks but does not allow or deny specific application traffic like HTTP; it is a security enhancement, not an access control mechanism. Option C is wrong because Azure Traffic Manager is a DNS-based traffic load balancer that routes users to endpoints based on routing methods, but it does not open ports or allow traffic through the NSG; the NSG must still permit the traffic.

Practice this question →

136

MCQmedium

A company has an Azure virtual network with a subnet that contains virtual machines. They have deployed Azure Firewall in a hub VNet and peered the spoke VNet to the hub. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP as the next hop. However, traffic from the VMs is still going directly to the internet. What is the most likely cause?

A.The route table is not associated with the subnet.

B.The Azure Firewall's private IP is not configured as the next hop; it should be the public IP.

C.The VNet peering is not configured correctly.

D.The Azure Firewall has a default route that bypasses itself.

AnswerA

Correct. A route table only influences traffic after it is associated with a subnet. Without that association, the subnet's effective routes remain the system defaults, so internet-bound traffic bypasses the Azure Firewall and egresses directly via the virtual NIC's default SNAT. The forced-tunneling UDR must be attached to the specific spoke subnet to redirect its default route to the firewall's private IP.

Why this answer

The most likely cause is that the route table containing the default route (0.0.0.0/0) with the Azure Firewall's private IP as the next hop has not been associated with the spoke subnet. Without this association, the subnet's VMs will use the system default route, which sends internet-bound traffic directly out via the Azure default gateway (0.0.0.0/0, next hop type Internet), bypassing the firewall entirely.

Exam trap

The trap here is that candidates often assume that simply creating a route table with a default route to the firewall is sufficient, but they overlook the critical step of associating that route table with the subnet, which is a separate action in the Azure portal or via PowerShell/CLI.

How to eliminate wrong answers

Option B is wrong because the next hop for forced tunneling through Azure Firewall must be the firewall's private IP address, not its public IP; using a public IP would cause asymmetric routing and break the firewall's stateful inspection. Option C is wrong because VNet peering is correctly configured (the spoke is peered to the hub), and peering alone does not redirect traffic to the firewall—a route table with the firewall as next hop is required. Option D is wrong because Azure Firewall does not have a default route that bypasses itself; it uses the effective routes from its subnet, and a default route on the firewall would point to the internet via its public IP, which is normal and does not cause traffic to bypass the firewall.

Practice this question →

137

MCQmedium

Your organization uses Azure Virtual Network Manager (AVNM) to manage network groups. You need to ensure that all virtual networks in a network group are automatically peered with a hub VNet. Which AVNM configuration should you use?

A.Create a connectivity configuration with Hub and Spoke topology

B.Create a network group and assign it to a connectivity configuration

C.Create a security admin configuration

D.Use Azure Policy to enforce peering

AnswerA

In Azure Virtual Network Manager, a connectivity configuration defines the actual network topology you want to establish. When you select Hub and Spoke, AVNM automatically creates VNet peering between the hub VNet and all spoke VNets assigned to that configuration, eliminating the need for manual peering. This configuration also manages transitive routing, so spokes can communicate through the hub without requiring individual peerings between every spoke. Thus, creating a connectivity configuration with hub-and-spoke topology is the correct and direct mechanism to automate peering in AVNM.

Why this answer

To automatically peer all virtual networks in a network group with a hub VNet, you need a connectivity configuration with Hub and Spoke topology. AVNM's connectivity configuration defines the network topology (e.g., hub-and-spoke or mesh) and automatically creates the necessary VNet peering connections between the hub and all spoke VNets in the assigned network group, without manual peering setup.

Exam trap

The trap here is that candidates confuse a network group (a logical container) with a connectivity configuration (which defines the actual topology and peering), leading them to select Option B without realizing the configuration type is required.

How to eliminate wrong answers

Option B is wrong because a network group alone is just a logical grouping of VNets; it does not define any connectivity or peering. Assigning it to a connectivity configuration is necessary, but the configuration itself must specify the topology (hub-and-spoke) to enable peering. Option C is wrong because a security admin configuration is used to enforce security rules (e.g., blocking traffic or applying firewall policies), not to create VNet peering.

Option D is wrong because Azure Policy can enforce compliance (e.g., requiring a specific tag or resource location) but cannot directly create or manage VNet peering; peering must be configured via AVNM connectivity configurations or manually.

Practice this question →

138

MCQmedium

A company uses Azure Front Door to accelerate and secure its public web application. The security team wants to limit the number of requests from a single client IP address to 100 per minute to prevent a single user from overwhelming the backend. Which configuration should they add to the Web Application Firewall (WAF) policy associated with the Front Door?

A.Add a custom rule with a rate limit condition.

B.Enable a managed rule set for the WAF policy.

C.Configure a bot protection rule set.

D.Set a geolocation filter to block all traffic except from allowed countries.

AnswerA

Azure Front Door's WAF supports custom rules with a rate limit condition, which tracks the number of requests from a client IP address within a defined time window (e.g., 60 seconds). Once the threshold is exceeded, you can specify an action such as Block to immediately drop subsequent requests until the window resets. This is the only option that directly implements per-IP request throttling to protect against aggressive scraping or brute-force attempts, making it the correct choice for the stated requirement.

Why this answer

Azure Front Door's WAF supports custom rate limit rules that can restrict the number of requests from a single client IP address within a specified time window. By creating a custom rule with a rate limit condition set to 100 requests per minute, the security team can prevent a single client from overwhelming the backend while allowing legitimate traffic. This is the only option that directly addresses the requirement to limit requests per client IP.

Exam trap

The trap here is that candidates often confuse rate limiting with bot protection or managed rule sets, assuming that enabling a managed rule set or bot protection will automatically handle request throttling, but neither provides per-IP rate limiting—they focus on attack signatures and bot detection, respectively.

How to eliminate wrong answers

Option B is wrong because enabling a managed rule set (e.g., OWASP or Microsoft default rule set) provides pre-configured signatures to block common web attacks like SQL injection or XSS, but it does not enforce per-IP request rate limits. Option C is wrong because bot protection rule sets are designed to identify and mitigate automated bot traffic (e.g., by categorizing known bots or detecting anomalies), not to cap the number of requests from a single client IP. Option D is wrong because a geolocation filter restricts traffic based on geographic origin (e.g., blocking all countries except allowed ones), which does not limit the request rate from any specific client IP.

Practice this question →

139

MCQhard

Your organization has a Microsoft Entra ID tenant and uses Azure Virtual Desktop (AVD). You need to ensure that AVD session hosts in a virtual network can access on-premises resources securely without exposing the session hosts to the internet. The on-premises network is connected to Azure via ExpressRoute. All AVD traffic should be routed through the ExpressRoute connection. You have already deployed a reverse connect transport for AVD. What else should you configure to meet the requirements?

A.Configure VNet peering between the AVD virtual network and the on-premises network.

B.Add a user-defined route (UDR) in the AVD subnet for the on-premises IP prefixes with next hop to the ExpressRoute gateway.

C.Disable reverse connect transport and allow inbound RDP traffic from the internet.

D.Create a private endpoint for the AVD control plane.

AnswerB

A user-defined route (UDR) associated with the AVD subnet can explicitly direct traffic destined for the on-premises IP prefixes to the ExpressRoute virtual network gateway by setting the next hop type to 'VirtualNetworkGateway'. This forces all matching traffic from session hosts to traverse the ExpressRoute connection instead of default internet routing, ensuring secure and predictable connectivity to on-premises resources. Without such a route, traffic might bypass the gateway or use an unintended path, depending on the existing route table.

Why this answer

Adding a user-defined route (UDR) in the AVD subnet for on-premises IP prefixes with the next hop set to the ExpressRoute gateway forces all traffic destined for on-premises resources to traverse the ExpressRoute connection. This ensures secure, private connectivity without exposing session hosts to the internet, while the reverse connect transport already handles AVD control plane traffic securely.

Exam trap

The trap here is that candidates often confuse VNet peering (which connects VNets within Azure) with hybrid connectivity to on-premises, or mistakenly think a private endpoint for the control plane alone satisfies all routing requirements for session host traffic.

How to eliminate wrong answers

Option A is wrong because VNet peering connects Azure virtual networks, not an Azure VNet to an on-premises network; on-premises connectivity requires ExpressRoute or VPN, not peering. Option C is wrong because disabling reverse connect transport and allowing inbound RDP from the internet would expose session hosts to the internet, violating the requirement to keep them secure and not internet-facing. Option D is wrong because a private endpoint for the AVD control plane secures the control plane connection but does not route session host traffic to on-premises resources; it does not replace the need for a UDR to direct traffic through ExpressRoute.

Practice this question →

140

MCQmedium

Your company has deployed Azure Kubernetes Service (AKS) in a virtual network. The AKS cluster needs to pull images from a private Azure Container Registry (ACR) that has a private endpoint configured. The virtual network where AKS is deployed is peered to the ACR's virtual network. You have configured the AKS cluster to use managed identity for authentication to ACR. However, the AKS cluster is unable to pull images from the ACR. You need to resolve the connectivity issue without exposing the ACR to the internet. What should you do?

A.Link the private DNS zone of the ACR private endpoint to the AKS virtual network.

B.Update the AKS cluster's DNS server to use a custom DNS that can resolve the private endpoint.

C.Delete the private endpoint and configure ACR firewall rules to allow the AKS subnet.

D.Recreate the AKS cluster with a different managed identity that has ACR pull permissions.

AnswerA

Linking the private DNS zone of the ACR's private endpoint to the AKS virtual network is the required fix. This DNS link enables Azure's DNS resolution to map the ACR's private endpoint FQDN to the private IP address inside the AKS VNet, allowing the kubelet to reach the registry over the private endpoint. Without this link, AKS nodes will attempt to resolve the ACR login server to its public IP, which is blocked when public access is disabled. This is the standard, supported method for private ACR connectivity to AKS.

Why this answer

The AKS cluster cannot pull images from the private ACR because the private endpoint's DNS resolution is not propagated to the AKS virtual network. By linking the private DNS zone of the ACR private endpoint to the AKS virtual network, the AKS nodes can resolve the ACR's private FQDN to the private IP address of the endpoint, enabling connectivity without exposing the ACR to the internet.

Exam trap

The trap here is that candidates often assume peering alone provides full connectivity, but they overlook that private endpoint DNS resolution requires explicit linking of the private DNS zone to the peered virtual network.

How to eliminate wrong answers

Option B is wrong because updating the AKS cluster's DNS server to a custom DNS that can resolve the private endpoint is unnecessary and may break other DNS resolutions; the correct approach is to link the private DNS zone to the AKS virtual network, which automatically handles resolution via Azure's DNS infrastructure. Option C is wrong because deleting the private endpoint and configuring ACR firewall rules would expose the ACR to the internet (even if restricted to the AKS subnet), violating the requirement to keep the ACR private. Option D is wrong because the managed identity already has ACR pull permissions (as stated), and recreating the cluster with a different identity does not address the DNS resolution or network connectivity issue.

Practice this question →

141

MCQeasy

A security team needs to analyze network traffic to and from Azure virtual machines to investigate a potential security incident. They want to capture information such as source IP, destination IP, port, and protocol. Which Azure service should they enable on the network security groups (NSGs) associated with the virtual machine subnets?

A.Network Watcher NSG flow logs

B.Azure Monitor logs

C.Traffic Analytics

D.Azure Firewall logs

AnswerA

NSG flow logs are the definitive source for IP-level traffic to/from VMs because they record the five-tuple (source IP, destination IP, source port, destination port, protocol) and the allow/deny action for every flow tested against the NSG. Unlike broad resource logs, these logs are specifically designed to answer 'who talked to whom' at the network layer, making them indispensable for security investigations. They capture both direction and state, so the team can trace the exact packets that were permitted or refused.

Why this answer

Network Watcher NSG flow logs capture IP traffic flowing through Network Security Groups, recording source IP, destination IP, port, and protocol for each flow. This directly meets the requirement to analyze network traffic to and from Azure VMs for security incident investigation.

Exam trap

The trap here is that candidates confuse Traffic Analytics (a visualization/analysis layer) with the underlying data capture mechanism (NSG flow logs), or mistakenly think Azure Monitor logs or Azure Firewall logs provide the same subnet-level flow data without additional configuration.

How to eliminate wrong answers

Option B is wrong because Azure Monitor logs is a general log analytics service that ingests data from various sources, but it does not natively capture per-flow network traffic details like source/destination IP and port from NSGs without NSG flow logs being enabled first. Option C is wrong because Traffic Analytics is a solution that processes NSG flow logs to provide visualizations and insights; it is not the underlying data capture mechanism and requires NSG flow logs to be enabled. Option D is wrong because Azure Firewall logs capture traffic that passes through Azure Firewall, not traffic filtered by NSGs on subnets; NSG flow logs are the correct service for subnet-level traffic analysis.

Practice this question →

142

MCQmedium

You are a security engineer at Contoso. The company has an Azure virtual network named VNet1 with a subnet named WebSubnet that hosts internet-facing Linux VMs. You need to restrict inbound traffic to WebSubnet so that only HTTP (TCP 80) and HTTPS (TCP 443) from the internet are allowed, and all other inbound traffic is denied. The VMs must remain reachable over SSH from a jump host in another subnet for management. What should you configure?

A.Create a network security group (NSG) and associate it with WebSubnet. Add inbound rules allowing TCP 80 and 443 from source Internet, allowing TCP 22 from the jump host subnet, and a final rule denying all other inbound traffic with a higher priority number.

B.Create a user-defined route (UDR) on WebSubnet that sends all traffic to a virtual network gateway, and configure the gateway to allow only TCP 80 and 443.

C.Configure a service endpoint for Microsoft.Storage on WebSubnet and create a storage account firewall rule that allows only HTTP and HTTPS.

D.Create an Azure Firewall in a GatewaySubnet and configure DNAT rules to forward TCP 80 and 443 to the web VMs, and network rules to deny all other inbound traffic.

AnswerA

This is correct because an NSG applied to WebSubnet filters traffic at the subnet level. Rules are processed by priority, lowest number first. Allowing 80/443 from Internet, allowing 22 from the jump host subnet, and adding a low-priority deny-all rule enforces the required restriction while preserving management access from the jump host.

Why this answer

A network security group attached to WebSubnet enforces inbound rules at the subnet boundary. Allowing TCP 80 and 443 from Internet, allowing TCP 22 from the jump host subnet, and placing a deny-all rule at a higher priority number blocks all other inbound traffic. This satisfies both the internet restriction and the management requirement without extra routing changes.

Exam trap

The trap here is assuming that a user-defined route or Azure Firewall DNAT can replace an NSG for restricting inbound ports to a subnet, when only an NSG provides stateful, subnet-level inbound filtering.

Practice this question →

143

MCQmedium

You are a security engineer for a company that uses Azure Virtual Networks and Azure Private Endpoints. You have a storage account with a private endpoint in VNet1. You need to ensure that all DNS queries for the storage account's private endpoint resolve to the private IP address from any virtual machine in VNet1. The virtual machines use the default Azure-provided DNS servers. What should you do?

A.Create a private DNS zone named privatelink.blob.core.windows.net and link it to VNet1.

B.Enable Azure DNS Private Resolver in VNet1 and configure a forwarding rule to the storage account's private IP.

C.Add a DNS record for the storage account's public FQDN pointing to the private IP address in the VNet's DNS settings.

D.Configure a conditional forwarder on the Azure-provided DNS servers to forward queries for the storage account to an on-premises DNS server.

AnswerA

Azure Private Endpoints require a private DNS zone to resolve the private IP. The zone name must match the service's privatelink domain, such as privatelink.blob.core.windows.net for Blob storage. Linking the zone to VNet1 ensures that VMs using Azure-provided DNS can resolve the private endpoint FQDN to the private IP, enabling secure, private connectivity.

Why this answer

Private Endpoints require DNS resolution to the private IP. Azure Private DNS zones with names like privatelink.blob.core.windows.net are the standard method. Linking the zone to the virtual network enables Azure-provided DNS to resolve the private endpoint FQDN correctly.

Other options either misuse features or do not provide the required DNS resolution.

Exam trap

The trap here is assuming that Azure-provided DNS can be customized with conditional forwarders or custom records, which it cannot.

Practice this question →

144

MCQmedium

Traffic from a spoke VNet must reach the internet through a firewall in the hub VNet. What routing configuration is required on the spoke subnets?

A.A route to Internet with next hop Internet

B.A default route to the Azure Firewall private IP or virtual appliance next hop

C.An NSG deny rule for 0.0.0.0/0

D.A service endpoint policy

AnswerB

A default route (0.0.0.0/0) with a next hop of the Azure Firewall private IP or the NVA interface is the standard way to implement forced tunneling from a spoke VNet to a hub. This user-defined route overrides Azure's default Internet route and steers all outbound traffic to the firewall, which can then apply rules, NAT, and logging before sending it to the internet. For an NVA, IP forwarding must be enabled on the NIC, and for Azure Firewall, the next hop is simply the firewall's private IP.

Why this answer

To force spoke traffic to the internet through a firewall in the hub VNet, you must create a user-defined route (UDR) on the spoke subnet with an address prefix of 0.0.0.0/0 and a next hop of the Azure Firewall's private IP or the virtual appliance's IP. This overrides the default system route that would otherwise send internet-bound traffic directly out via Azure's edge, ensuring all egress traffic is inspected and controlled by the firewall.

Exam trap

The trap here is that candidates often confuse NSG rules with routing, thinking a deny rule for 0.0.0.0/0 can force traffic through a firewall, when in fact only a UDR with a specific next hop can redirect traffic to a network virtual appliance.

How to eliminate wrong answers

Option A is wrong because a route to Internet with next hop Internet would send traffic directly to the internet via Azure's default path, bypassing the firewall entirely. Option C is wrong because an NSG deny rule for 0.0.0.0/0 would block all outbound traffic, including legitimate internet access, and does not route traffic through a firewall. Option D is wrong because a service endpoint policy restricts access to specific Azure services (e.g., Storage, SQL) from a subnet, not general internet routing or firewall enforcement.

Practice this question →

145

MCQmedium

You are a security engineer at Fabrikam Inc. The company has an Azure subscription with a single virtual network (VNet1) that contains a production workload. The network is connected to an on-premises data center via a site-to-site VPN. The security team requires that all Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to virtual machines in VNet1 must be brokered through Azure Bastion. Additionally, the team wants to ensure that no public IP addresses are assigned to any virtual machines in the production environment. Currently, there are several VMs with public IPs. You need to implement the requirements with minimal downtime. The solution must also ensure that administrators can access the VMs using Azure Bastion without any additional client software. What should you do?

A.Create a point-to-site VPN for administrators and remove public IPs from VMs.

B.Deploy Azure Bastion in the virtual network, then configure Just-In-Time (JIT) VM access for all VMs.

C.Disassociate public IPs from all VMs, then deploy Azure Bastion in the same virtual network.

D.Deploy Azure Bastion in the virtual network and then remove the public IP addresses from all VMs.

AnswerD

Deploying Azure Bastion in the same virtual network as the target VMs first establishes a secure, fully managed PaaS service that brokers RDP and SSH sessions over TLS using the HTML5 client, with no additional client software required. Once Bastion reports a healthy status, removing the VMs' public IPs keeps administrative access uninterrupted because Bastion connects to the VMs over their private IP addresses. This ordering ensures zero downtime for administrators and aligns exactly with the requirements to eliminate public exposure and avoid client configuration.

Why this answer

Option D is correct because Azure Bastion must be deployed in the same virtual network as the target VMs (or a peered VNet) before public IPs are removed, since Bastion provides RDP/SSH connectivity over TLS port 443 through the Azure portal without requiring any client software or public IPs on the VMs. Deploying Bastion first ensures administrators retain access while the public IPs are disassociated, minimizing downtime. Option A is wrong because a point-to-site VPN does not broker RDP/SSH through Bastion and does not satisfy the no-public-IP requirement by itself.

Option B is wrong because JIT VM access is a Microsoft Defender for Cloud feature that reduces exposure but does not replace Bastion or eliminate the need for public IPs. Option C is wrong because removing public IPs before Bastion is deployed would cut off RDP/SSH access and cause downtime.

Practice this question →

146

MCQmedium

A company has several Azure virtual machines (VMs) in a VNet that host a legacy application. IT support staff need to perform remote administration using RDP. The security team wants to avoid exposing the VMs to the public internet and also enforce Azure Multi-Factor Authentication (MFA) for all RDP sessions. Which Azure service should they deploy to meet these requirements?

A.Just-in-Time (JIT) VM Access from Microsoft Defender for Cloud

B.Azure Bastion

C.Network Security Groups (NSGs) with allow rules for RDP only from a trusted IP

D.Azure Firewall with DNAT rules to forward RDP traffic

AnswerB

Azure Bastion is correct because it provides RDP/SSH access directly in the Azure portal over TLS, so the VM never gets a public IP address and is never directly exposed to the internet. Since Bastion authenticates the user through Azure AD before launching the session, it natively integrates with Conditional Access, allowing you to enforce MFA as a prerequisite for any remote connection. This fulfills both stated requirements: no public IP exposure and mandatory MFA.

Why this answer

Azure Bastion provides secure, seamless RDP/SSH connectivity to Azure VMs directly from the Azure portal over TLS, without exposing the VMs to a public IP address. It also integrates with Azure AD and Conditional Access to enforce Azure Multi-Factor Authentication (MFA) for all RDP sessions, meeting both the security and compliance requirements.

Exam trap

The trap here is that candidates often confuse Just-in-Time (JIT) VM Access with MFA enforcement, but JIT only controls network-level access timing and does not natively enforce Azure MFA for the RDP session itself.

How to eliminate wrong answers

Option A is wrong because Just-in-Time (JIT) VM Access from Microsoft Defender for Cloud reduces the attack surface by locking down inbound traffic to VMs and granting timed access, but it does not natively enforce Azure MFA for the RDP session itself; MFA would need to be separately configured on the VM or via a different service. Option C is wrong because Network Security Groups (NSGs) with allow rules for RDP only from a trusted IP can restrict source IPs but cannot enforce Azure MFA; they operate at the network layer (Layer 3/4) and have no mechanism to require multi-factor authentication. Option D is wrong because Azure Firewall with DNAT rules can forward RDP traffic to internal VMs while hiding their private IPs, but it does not provide built-in MFA enforcement; MFA would require additional components like an RD Gateway or Azure AD Application Proxy.

Practice this question →

147

MCQeasy

You are designing a hub-spoke network topology in Azure. You need to ensure that all traffic between spokes is inspected by a network virtual appliance (NVA) deployed in the hub. What should you configure?

A.Create user-defined routes (UDRs) in each spoke pointing to the NVA's IP address.

B.Deploy Azure Firewall in the hub.

C.Configure VNet peering between all spokes.

D.Use a VPN gateway to route traffic through the hub.

AnswerA

In a hub-spoke architecture with an NVA, you must explicitly insert the appliance into the data path. Create a route table on each spoke subnet that needs inspection, add routes for other spoke prefixes (or 0.0.0.0/0) with the NVA's private IP as the next hop, and associate that table to the subnet. Also enable IP forwarding on the NVA's NIC; otherwise the NVA will drop traffic not addressed to itself. Without these UDRs, VNet peering still allows direct spoke-to-spoke traffic and bypasses the NVA completely.

Why this answer

To force all inter-spoke traffic through a network virtual appliance (NVA) in the hub, you must create user-defined routes (UDRs) in each spoke's subnet that direct traffic destined for other spoke address spaces to the NVA's private IP address. This overrides the default system route that would otherwise allow direct communication over VNet peering, ensuring the NVA inspects every packet.

Exam trap

The trap here is that candidates often assume Azure Firewall is the only way to inspect traffic, but the question explicitly mentions an NVA, so the correct answer is configuring UDRs to force traffic through that NVA's IP address.

How to eliminate wrong answers

Option B is wrong because deploying Azure Firewall in the hub is a valid way to inspect traffic, but the question specifically asks what you should configure to ensure traffic is inspected by an NVA, not Azure Firewall. Option C is wrong because configuring VNet peering between all spokes creates direct connectivity, bypassing the hub NVA entirely. Option D is wrong because a VPN gateway is used for encrypted site-to-site or point-to-site connectivity, not for routing internal VNet traffic through an NVA; it would add unnecessary overhead and does not force traffic through the NVA.

Practice this question →

148

MCQmedium

Your company uses Azure Virtual WAN with a secured virtual hub (Azure Firewall). You have branch offices connected via ExpressRoute. You need to ensure that traffic from a branch to a VNet in the same region is inspected by the firewall. You configure the default route (0.0.0.0/0) advertisement from the hub to the branch, but the traffic is not being inspected. What is the most likely reason?

A.The 'Inter-hub' setting is disabled.

B.The branch does not have a route table associated with the connection.

C.Routing intent for private traffic is not enabled.

D.The VNet has a network virtual appliance (NVA) that overrides the firewall.

AnswerC

Routing intent is the control plane mechanism in Azure Virtual WAN that lets you designate an Azure Firewall or a network virtual appliance as the next hop for private traffic, including branch-to-VNet traffic. Without a routing intent policy for private traffic, the Virtual WAN hub uses its default routing behavior, which sends packets directly from the branch gateway to the VNet's connection, bypassing the secured hub firewall entirely. Therefore, enabling routing intent for private traffic is the required action to restore firewall inspection.

Why this answer

Routing intent for private traffic must be enabled on the Virtual WAN hub to ensure that inter-VNet and branch-to-VNet traffic (private IP ranges) is routed through the Azure Firewall. Without routing intent, only internet-bound traffic (0.0.0.0/0) is forced through the firewall by the default route, while private traffic between branches and VNets bypasses inspection. Enabling routing intent for private traffic overrides the default behavior and injects the firewall as the next hop for all private traffic.

Exam trap

The trap here is that candidates assume configuring the default route (0.0.0.0/0) is sufficient to inspect all traffic, but Azure Virtual WAN requires explicit routing intent for private traffic to force branch-to-VNet flows through the firewall.

How to eliminate wrong answers

Option A is wrong because the 'Inter-hub' setting controls routing between different hubs in a multi-hub topology, not traffic inspection for a single hub's branch-to-VNet flows. Option B is wrong because branch connections in Virtual WAN automatically use the hub's default route table; a separate route table association is not required for the default route to be propagated. Option D is wrong because an NVA in a VNet would only affect traffic if the VNet's route table explicitly points to it, and it does not override the hub's routing intent unless the VNet is configured with forced tunneling that bypasses the hub.

Practice this question →

149

MCQmedium

You are reviewing an NSG rule as shown in the exhibit. This rule is applied to a subnet containing web servers. What is the security implication of this rule?

A.It restricts inbound traffic to TCP only.

B.It allows all inbound traffic, creating a security risk.

C.It blocks all inbound traffic except HTTP.

D.It restricts inbound traffic to HTTP only.

AnswerB

This option is correct. The rule specifies 'Allow' as the action with source, destination, protocol, and port range all set to 'Any'. This combination creates a rule that permits all inbound traffic from any source to any port on any protocol. Such a rule overrides the default NSG deny rules and exposes the associated resources to the entire internet, which is a significant security risk.

Why this answer

The NSG rule shown in the exhibit has a source and destination of 'Any' and an action of 'Allow' for all ports and protocols. This effectively permits all inbound traffic from any source to the subnet, bypassing any intended security restrictions. Such a configuration exposes the web servers to unrestricted network access, including malicious traffic, creating a significant security risk.

Exam trap

The trap here is that candidates may focus on the rule's name or description (e.g., 'AllowHTTP') and assume it only permits HTTP traffic, overlooking the actual rule properties that set source, destination, and protocol to 'Any'.

How to eliminate wrong answers

Option A is wrong because the rule does not restrict inbound traffic to TCP only; it allows all protocols (TCP, UDP, ICMP, etc.) as indicated by the protocol field set to 'Any'. Option C is wrong because the rule does not block all inbound traffic except HTTP; it allows all inbound traffic, not just HTTP. Option D is wrong because the rule does not restrict inbound traffic to HTTP only; it permits all traffic, including non-HTTP protocols and ports.

Practice this question →

150

Multi-Selecthard

A public web application should be protected from OWASP-style attacks and network-layer DDoS attacks. Which two Azure services are most relevant?

Select 2 answers

A.Application Gateway WAF or Azure Front Door WAF

B.Azure Automation State Configuration

C.Azure DDoS Protection on the virtual network where applicable

D.Azure Files premium tier

AnswersA, C

Application Gateway WAF and Azure Front Door WAF are layer-7 web application firewall services that inspect inbound HTTP/HTTPS traffic and apply managed rule sets designed explicitly around the OWASP Top 10, including SQL injection and cross-site scripting. Both can operate in detection or prevention mode, support custom rules and rate limiting, and integrate with Azure Security Center, making them the direct, primary solution for OWASP protection on a public web app.

Why this answer

Both Azure Application Gateway WAF and Azure Front Door WAF provide managed rule sets (e.g., OWASP Core Rule Set 3.2) that protect against common web vulnerabilities such as SQL injection and cross-site scripting. Option C is correct because Azure DDoS Protection, when enabled on the virtual network hosting the application, mitigates network-layer DDoS attacks (e.g., SYN floods, UDP floods) by leveraging Azure's global infrastructure to absorb and scrub attack traffic.

Exam trap

The trap here is that candidates may confuse Azure Automation State Configuration (a DevOps tool) with a security service, or assume Azure Files premium tier offers built-in attack protection, when in fact only WAF and DDoS Protection directly address the specified OWASP and DDoS threats.

Practice this question →