Knowledge + Practice

CCNA Secure networking Questions

61 questions · Secure networking · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQhard

A company has two Azure virtual networks, VNet-A (hub) and VNet-B (spoke), connected via VNet peering. They deploy a network virtual appliance (NVA) in a subnet in VNet-A to inspect all traffic between the VNets. They configure a user-defined route (UDR) on the subnet in VNet-B with the destination address space of VNet-A (10.0.0.0/16) and the next hop set to the private IP of the NVA. However, traffic from VNet-B to VNet-A still bypasses the NVA and takes a direct path. What is the most likely cause?

A.The NVA's private IP address is not reachable from VNet-B

B.VNet peering system routes override user-defined routes

C.The UDR must be applied to the gateway subnet of VNet-B

D.The NVA network interface does not have IP forwarding enabled

AnswerD

IP forwarding must be enabled on the NVA's NIC for it to forward traffic destined to other IPs. Without it, the NVA will drop the traffic, and the peering path remains active.

Why this answer

A network virtual appliance (NVA) requires IP forwarding to be enabled on its network interface to forward traffic not destined for itself. Without this setting, the NVA drops packets that arrive with a destination IP other than its own, causing the traffic to bypass the NVA and follow the default VNet peering route. Enabling IP forwarding allows the NVA to act as a router and forward traffic between VNets as specified by the user-defined route.

Exam trap

The trap here is that candidates often assume a UDR alone is sufficient to force traffic through an NVA, overlooking the mandatory IP forwarding setting on the NVA's NIC, which is a common misconfiguration in Azure networking.

How to eliminate wrong answers

Option A is wrong because if the NVA's private IP were unreachable from VNet-B, the traffic would fail entirely, not bypass the NVA; the issue is that the NVA receives but drops the traffic. Option B is wrong because user-defined routes (UDRs) override VNet peering system routes for traffic within the same virtual network or between peered VNets when the next hop is explicitly set; system routes are only used when no UDR matches. Option C is wrong because the UDR must be applied to the subnet containing the source VMs in VNet-B, not the gateway subnet, which is used for VPN/ExpressRoute traffic, not for VNet peering traffic.

Practice this question →

2

MCQeasy

You manage a multi-tier application in Azure with a web tier, application tier, and database tier. 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 networking feature should you use to isolate the tiers?

A.Virtual network peering between tiers.

B.Azure Firewall with application rules.

C.Network security groups (NSGs) on each subnet.

D.Application security groups (ASGs) within the same subnet.

AnswerC

NSGs allow you to define rules to permit or deny traffic between subnets, effectively isolating tiers.

Why this answer

Network security groups (NSGs) allow you to define inbound and outbound security rules that filter traffic at the subnet or NIC level. By placing each tier in its own subnet and applying an NSG to the web tier subnet that allows inbound traffic from the internet, and NSGs to the application and database tier subnets that only allow inbound traffic from the web tier subnet (using the source IP address range or the virtual network tag), you can effectively isolate the tiers while permitting necessary east-west traffic.

Exam trap

The trap here is that candidates often confuse network segmentation (NSGs on subnets) with application-level grouping (ASGs) or perimeter security (Azure Firewall), and incorrectly assume that ASGs alone can provide isolation between tiers within the same subnet.

How to eliminate wrong answers

Option A is wrong because virtual network peering connects entire virtual networks, not subnets within the same VNet, and does not provide traffic filtering or isolation between tiers; it would actually allow all traffic between the peered VNets unless combined with NSGs. Option B is wrong because Azure Firewall is a managed, stateful firewall service typically deployed at the network perimeter for centralized inspection and logging, not for isolating subnets within a single VNet; using it for tier isolation would be overkill and introduce unnecessary latency and cost. Option D is wrong because application security groups (ASGs) allow you to group VMs and define NSG rules based on those groups, but they do not isolate traffic between tiers when all VMs are in the same subnet; ASGs are a logical grouping mechanism, not a network segmentation boundary.

Practice this question →

3

MCQmedium

A company has an Azure virtual network with two subnets: App and Data. The App subnet hosts web servers, and the Data subnet hosts SQL databases. Security policy requires that only HTTPS traffic from the App subnet is allowed to the Data subnet, and all other inbound traffic to the Data subnet must be blocked. The solution must use a single network security group (NSG) associated to the Data subnet. Which NSG inbound rule configuration meets the requirement?

A.Allow HTTPS from App subnet priority 100, then Deny All priority 200

B.Deny All priority 100, then Allow HTTPS from App subnet priority 200

C.Allow HTTPS from App subnet priority 100, and Deny All from any source priority 100 (duplicate priority)

D.Allow HTTPS from App subnet priority 100, no other rules

AnswerA

This configuration is correct because Azure NSGs process rules in ascending numeric order, and priority 100 is higher than 200. The HTTPS allow rule for the App subnet is evaluated first, matching the permitted traffic, and the later DenyAll rule with priority 200 blocks all other inbound traffic. This implements the recommended pattern: a specific allow for the desired source and port, followed by a catch-all deny.

Why this answer

NSG rules are evaluated in priority order, with lower numbers processed first. By placing the Allow HTTPS rule at priority 100, it matches and permits traffic from the App subnet to the Data subnet. The subsequent Deny All rule at priority 200 then blocks all other inbound traffic, satisfying the security policy with a single NSG on the Data subnet.

Exam trap

The trap here is that candidates may think a Deny All rule is unnecessary because NSGs have an implicit deny at the end, but the explicit Deny All at a lower priority ensures that any traffic not matching the Allow rule is explicitly blocked, which is required by the policy and avoids reliance on the implicit default.

How to eliminate wrong answers

Option B is wrong because the Deny All rule at priority 100 would block all inbound traffic, including HTTPS from the App subnet, before the Allow rule at priority 200 is ever evaluated, making the Allow rule ineffective. Option C is wrong because duplicate priority values (100) are not allowed in NSG rules; Azure requires unique priority numbers, and even if allowed, the order of evaluation would be ambiguous. Option D is wrong because without a Deny All rule, any traffic not matching the Allow HTTPS rule (e.g., other protocols or sources) would be permitted by the default implicit deny, but the requirement explicitly states all other inbound traffic must be blocked, and the implicit deny only applies after all explicit rules; however, the explicit Deny All ensures no unintended traffic is allowed, which is necessary for strict compliance.

Practice this question →

4

MCQmedium

A company runs a public-facing web application on Azure App Service in the West US region. They want to protect against network-layer (Layer 3/4) DDoS attacks and have a single web application. Which Azure DDoS Protection tier should they use?

A.DDoS Protection Basic (default)

B.DDoS Protection Standard

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

D.Azure Front Door with DDoS Protection Standard

AnswerA

DDoS Protection Basic is automatically enabled for all Azure resources, including a public-facing Azure App Service, at no additional cost and with no configuration required. It performs always-on traffic monitoring and real-time mitigation of common network-layer attacks such as SYN floods, UDP floods, and reflection attacks at Azure's global edge. For a single App Service, this default protection is sufficient because the platform itself shields the application from volumetric L3/L4 threats, and Basic is the correct baseline expectation.

Why this answer

DDoS Protection Basic is automatically enabled for all Azure resources at no additional cost, providing always-on traffic monitoring and real-time mitigation of common network-layer (Layer 3/4) attacks, such as SYN floods, UDP floods, and reflection attacks. Since the company has a single web application and only needs protection against Layer 3/4 DDoS attacks, the Basic tier is sufficient and requires no configuration or extra cost.

Exam trap

The trap here is that candidates often assume DDoS Protection Standard is always required for any DDoS protection, overlooking that Basic is automatically enabled and sufficient for Layer 3/4 attacks on a single resource, while Standard is an enhanced add-on for complex, multi-resource environments needing advanced features.

How to eliminate wrong answers

Option B is wrong because DDoS Protection Standard is a paid tier designed for larger, multi-resource deployments that require adaptive tuning, attack analytics, and SLA-backed mitigation; it is overkill and unnecessary for a single web application needing only basic Layer 3/4 protection. Option C is wrong because Azure Web Application Firewall (WAF) on Application Gateway operates at Layer 7 (application layer) to protect against HTTP-specific attacks like SQL injection and cross-site scripting, not Layer 3/4 DDoS attacks. Option D is wrong because Azure Front Door with DDoS Protection Standard combines global load balancing and WAF capabilities but still requires the Standard tier for enhanced DDoS protection, which is not needed for this single-app scenario and adds unnecessary complexity and cost.

Practice this question →

5

MCQmedium

You configure Azure Bastion to allow secure RDP access to VMs in a VNet. However, users report that they cannot connect to a specific VM, while other VMs in the same VNet are accessible. The VM is running and has a public IP. What is the most likely cause?

A.The user does not have 'Reader' role on the VM.

B.The NSG on the VM's subnet does not allow inbound RDP from the AzureBastionSubnet.

C.The VM is located in a different region than the Bastion host.

D.The VM has a public IP assigned, which interferes with Bastion connectivity.

AnswerB

Azure Bastion injects the Bastion host into the AzureBastionSubnet, and for RDP to reach a target VM, the NSG attached to the VM's subnet must include an inbound allow rule for TCP 3389 from the address prefix of the AzureBastionSubnet. Without that rule, packets from the Bastion host are silently dropped by the target subnet's network security group, so the connection fails even if the rest of the configuration is correct. This is a common misconfiguration because users often open RDP only from the internet or their local IP, not from the Bastion subnet's private address range.

Why this answer

Azure Bastion provides secure RDP/SSH connectivity to VMs in a peered VNet without exposing public IPs. For Bastion to reach a VM, the Network Security Group (NSG) on the VM's subnet must allow inbound TCP traffic on port 3389 from the AzureBastionSubnet (which uses the Azure Bastion service's private IP range). If the NSG blocks this traffic, Bastion cannot establish the RDP session even though the VM is running and has a public IP.

The correct answer is B because the NSG misconfiguration is the most likely cause when other VMs in the same VNet are accessible.

Exam trap

The trap here is that candidates assume a public IP on the VM is the problem, but Azure Bastion explicitly bypasses public IPs and uses private IPs, so the public IP is irrelevant; the real issue is the NSG rule blocking inbound traffic from the AzureBastionSubnet.

How to eliminate wrong answers

Option A is wrong because the 'Reader' role on the VM is not required for Bastion connectivity; the user needs at least 'Reader' role on the VM, the virtual network, and the Bastion resource, but the issue is specific to a single VM, not a role assignment problem. Option C is wrong because Azure Bastion can connect to VMs in any region within the same tenant; the Bastion host and the VM do not need to be in the same region. Option D is wrong because a public IP assigned to the VM does not interfere with Bastion connectivity; Bastion uses a private IP to connect to the VM, and the public IP is simply ignored or can be removed without affecting Bastion access.

Practice this question →

6

MCQeasy

You need to securely connect an on-premises network to Azure over the internet with encrypted traffic. The connection must be site-to-site and use IPsec. Which Azure service should you use?

A.Azure VPN Gateway

B.Azure ExpressRoute

C.Azure Virtual WAN

D.Azure Bastion

AnswerA

VPN Gateway provides IPsec site-to-site VPN over the internet.

Why this answer

Azure VPN Gateway supports site-to-site (S2S) VPN connections over the internet using IPsec/IKE (IKEv1 or IKEv2) to encrypt traffic between an on-premises VPN device and Azure. This matches the requirement for an encrypted, internet-based site-to-site connection. ExpressRoute bypasses the internet entirely, Virtual WAN is a higher-level orchestration service that still relies on VPN Gateway for S2S IPsec, and Bastion is for RDP/SSH access to VMs without public IPs.

Exam trap

The trap here is that candidates confuse Azure Virtual WAN as a direct replacement for VPN Gateway, but Virtual WAN still requires VPN Gateway instances for S2S IPsec termination and is an orchestration/management layer, not the underlying connectivity service.

How to eliminate wrong answers

Option B (Azure ExpressRoute) is wrong because it provides a private, dedicated connection that does not traverse the internet and does not use IPsec by default; it is designed for high-bandwidth, low-latency scenarios, not encrypted internet-based S2S. Option C (Azure Virtual WAN) is wrong because it is a managed networking service that can aggregate multiple VPN connections, but the actual S2S IPsec termination is still performed by a VPN Gateway instance within the Virtual WAN hub; the question asks for the specific service, not the orchestration layer. Option D (Azure Bastion) is wrong because it is a PaaS service for secure RDP/SSH access to Azure VMs via TLS, not for site-to-site IPsec VPN connectivity.

Practice this question →

7

MCQeasy

A company has a virtual network with a subnet hosting Azure VMs. They want to restrict all inbound traffic to only allow HTTPS (port 443) from the internet, but also allow SSH (port 22) only from a specific management IP address range (e.g., 203.0.113.0/24). Which Azure service should they use to achieve this filtering?

A.Azure Firewall

B.Network Security Group (NSG) rule

C.Azure DDoS Protection

D.Azure Bastion

AnswerB

An NSG rule provides stateful, Layer 4 packet filtering directly at the subnet or network interface level. You can create an inbound rule to allow HTTPS (443) from 'Any' source and a separate rule to allow SSH (22) only from your specific management IP range, blocking all other unsolicited inbound traffic. This is the simplest, most cost-effective solution for basic port-and-source filtering on a single subnet, as it requires no additional routing or virtual appliances. NSGs are enforced by the Azure network stack, and each rule is evaluated in priority order, giving you precise control over permitted traffic.

Why this answer

A Network Security Group (NSG) rule is the correct choice because NSGs provide stateful, granular inbound and outbound filtering at the subnet or NIC level. You can create a rule to allow HTTPS (TCP/443) from any source (Internet) and a separate rule to allow SSH (TCP/22) only from the specific management IP range 203.0.113.0/24, while implicitly denying all other inbound traffic. NSGs are the native Azure service for this type of traffic filtering and do not require additional cost or deployment.

Exam trap

The trap here is that candidates often choose Azure Firewall because they think it is required for any IP-based filtering, but NSGs are the correct and simpler service for subnet-level inbound port and source IP filtering without needing a centralized firewall appliance.

How to eliminate wrong answers

Option A is wrong because Azure Firewall is a managed, centralized network security service used for advanced filtering across multiple VNets, outbound traffic inspection, and application rules, but it is overkill and more expensive for simple inbound port filtering on a single subnet; NSGs are the appropriate and simpler solution. Option C is wrong because Azure DDoS Protection is designed to protect against volumetric distributed denial-of-service attacks at the network layer, not to filter specific ports or IP addresses for legitimate traffic. Option D is wrong because Azure Bastion provides secure, browser-based RDP/SSH connectivity to VMs without exposing public IPs, but it does not filter inbound traffic to VMs; it replaces the need for SSH/RDP exposure entirely.

Practice this question →

8

MCQmedium

A company has an Azure virtual network with a subnet hosting web servers. The security policy requires that all inbound HTTP traffic must be sourced from a specific IP address range (203.0.113.0/24). All other inbound traffic must be denied. The subnet is associated with a network security group (NSG). Which set of inbound rules should they configure?

A.Allow HTTP from 203.0.113.0/24 (priority 100), then Deny all inbound (priority 200)

B.Deny all inbound (priority 100), then Allow HTTP from 203.0.113.0/24 (priority 200)

C.Allow HTTP from any (priority 100), then Deny all inbound (priority 200)

D.Only Allow HTTP from 203.0.113.0/24 (priority 100) with no explicit deny

AnswerA

This rule set works because NSG rules are processed in ascending priority order, and a lower numeric priority (100) is evaluated before a higher one (200). The specific allow rule for HTTP from 203.0.113.0/24 is matched first, permitting only that source and port, after which the deny-all rule at priority 200 blocks any inbound traffic that did not match the earlier allow. Critically, Azure's default inbound rules (AllowVnetInBound and AllowAzureLoadBalancerInBound) remain in effect unless explicitly denied, so the explicit deny-all is necessary to close those implicit allowances and enforce a true allowlist. The ordering ensures the desired traffic is accepted before the catch-all deny blocks everything else.

Why this answer

NSG rules are evaluated in priority order (lowest number first). The Allow rule for HTTP from 203.0.113.0/24 at priority 100 permits the desired traffic, and the subsequent Deny all inbound rule at priority 200 blocks all other traffic, including HTTP from any other source. This satisfies the security policy of allowing only HTTP from the specified IP range and denying everything else.

Exam trap

The trap here is that candidates often think a single Allow rule with no explicit Deny is sufficient, forgetting that NSGs have default implicit allow rules (e.g., AllowVNetInBound) that would permit other traffic unless explicitly denied.

How to eliminate wrong answers

Option B is wrong because the Deny all inbound rule at priority 100 would block all traffic, including HTTP from 203.0.113.0/24, before the Allow rule at priority 200 is evaluated, resulting in no allowed traffic. Option C is wrong because allowing HTTP from any source at priority 100 permits inbound HTTP traffic from all IP addresses, violating the policy that restricts HTTP to only the 203.0.113.0/24 range. Option D is wrong because without an explicit Deny all inbound rule, any traffic not matching the Allow rule (e.g., HTTP from other IPs or other protocols) would be implicitly allowed by the default NSG rules, failing to deny all other inbound traffic as required.

Practice this question →

9

MCQmedium

A company has an Azure virtual network with a subnet hosting internal web applications. The security team needs to allow inbound HTTPS traffic only from the company's corporate network IP range (203.0.113.0/24). All other inbound traffic must be denied. They want to use a network security group (NSG) associated with the subnet. Which inbound security rule configuration meets this requirement?

A.One inbound rule: Allow HTTPS from 203.0.113.0/24 with priority 100. No other rules. Rely on the default deny-all rule.

B.Two inbound rules: Allow HTTPS from 203.0.113.0/24 with priority 100, and Deny All from Any with priority 110.

C.Two inbound rules: Deny All from Any with priority 100, and Allow HTTPS from 203.0.113.0/24 with priority 110.

D.One inbound rule: Deny All from Any with priority 100. No allow rules. Use application security groups.

AnswerB

The allow rule (priority 100) permits HTTPS from the corporate IP. The deny rule (priority 110) blocks all other inbound traffic. Since the deny rule has a lower priority number (higher priority) than any default rules, it effectively blocks everything except the allowed HTTPS traffic.

Why this answer

NSGs process rules in priority order, and the default implicit deny rule only applies if no explicit rule matches. By placing an explicit 'Deny All from Any' rule with a higher priority number (110) after the explicit 'Allow HTTPS' rule (priority 100), traffic from 203.0.113.0/24 on HTTPS is allowed, and all other inbound traffic is explicitly denied, ensuring no unintended implicit allow or bypass.

Exam trap

The trap here is that candidates often assume the default deny rule is sufficient, but Azure explicitly requires an explicit deny rule to override the default implicit allow for outbound traffic or to ensure logging and control for inbound traffic, and they may misorder rules by placing the deny before the allow.

How to eliminate wrong answers

Option A is wrong because relying solely on the default deny-all rule leaves a gap: if any other rule (e.g., a future higher-priority allow rule) is added, it could inadvertently allow traffic; also, the default deny is implicit and does not provide explicit logging or control for all denied traffic. Option C is wrong because placing 'Deny All from Any' at priority 100 would block all traffic, including HTTPS from 203.0.113.0/24, before the allow rule at priority 110 is evaluated, resulting in no allowed HTTPS traffic. Option D is wrong because a single 'Deny All from Any' rule with no allow rule would block all inbound traffic, including the desired HTTPS traffic, and application security groups do not override the need for explicit allow rules.

Practice this question →

10

MCQeasy

A company deploys multiple Azure virtual machines across several subnets in a virtual network. The VMs are grouped by application tiers: web, application, and database. The security team wants to apply network security group (NSG) rules that target all VMs in a specific tier, and they need a way to easily add or remove VMs from these groups without updating NSG rules. Which Azure feature should they use to define these logical VM groups?

A.Network security group (NSG) with multiple IP address ranges.

B.Application Security Group (ASG).

C.Azure Resource Manager tags.

D.Virtual Network peering.

AnswerB

ASGs enable you to define logical groups of VMs based on their function. You can reference an ASG in NSG rules, and as VMs are added or removed from the ASG, the rule applies to the current members automatically.

Why this answer

Application Security Groups (ASGs) allow you to group VMs logically by application tier (e.g., web, application, database) without relying on IP addresses or subnet boundaries. NSG rules can reference ASGs as source or destination, so adding or removing a VM from an ASG automatically updates the effective security policy without modifying the NSG rules themselves.

Exam trap

The trap here is that candidates often confuse Azure Resource Manager tags with ASGs, thinking tags can be used in NSG rules, but NSG rules only support IP addresses, service tags, and application security groups, not tags.

How to eliminate wrong answers

Option A is wrong because NSGs with multiple IP address ranges require manual updates to the IP list whenever VMs are added or removed, which does not provide the dynamic, logical grouping the scenario requires. Option C is wrong because Azure Resource Manager tags are metadata labels that cannot be directly referenced in NSG rules; they are used for resource organization, cost tracking, and policy enforcement, not for defining network security group membership. Option D is wrong because Virtual Network peering connects separate virtual networks at the network layer and does not create logical groups of VMs within a single VNet or across subnets.

Practice this question →

11

MCQhard

You are the security engineer for a financial services company that has multiple Azure subscriptions. The company uses Azure Virtual WAN with a secured hub containing Azure Firewall. Recently, the compliance team identified that traffic between two spoke virtual networks (SpokeA and SpokeB) is bypassing the firewall. Investigation shows that SpokeA and SpokeB are directly peered and have not been routed through the hub. The requirement is that all inter-spoke traffic must be inspected by Azure Firewall. You need to enforce this without disrupting existing applications. Also, the company uses Azure Firewall Manager for policy management and wants to use Azure Policy to prevent future direct peering. What should you do first?

A.Remove the VNet peering between SpokeA and SpokeB.

B.Disable 'Use remote virtual network gateways' on both spokes.

C.Create an Azure Policy to deny VNet peering between spokes.

D.Add a user-defined route in SpokeA and SpokeB pointing to the Azure Firewall for inter-spoke traffic.

AnswerA

Removing peering forces traffic through the Virtual WAN hub and firewall.

Why this answer

The immediate problem is the existing VNet peering between SpokeA and SpokeB that bypasses Azure Firewall. The first step must address this existing peering. Removing the peering removes the direct path, forcing inter-spoke traffic to route through the Virtual WAN hub where Azure Firewall inspects it.

Option C (Azure Policy) is a preventive measure for future peerings but does not resolve the current violation. Option D (UDR) is ineffective because VNet peering has higher precedence than user-defined routes. Option B is unrelated to the peering issue.

Therefore, the correct first action is to remove the VNet peering.

Practice this question →

12

MCQeasy

You have an Azure virtual machine that hosts a web application. You need to allow inbound HTTP (80) and HTTPS (443) traffic from the internet to this VM only. You also need to allow outbound traffic to the internet from the VM. You want to use a managed Azure service with minimal configuration. What should you use?

A.Azure Application Gateway

B.Azure Firewall

C.Network Security Group (NSG)

D.Azure Bastion

AnswerC

A Network Security Group (NSG) is the correct, lightweight choice because it acts as a stateful, distributed packet filter that you can attach directly to the VM's NIC or its subnet. You can define allow/deny rules for inbound HTTP/HTTPS (e.g., ports 80/443) while relying on the default outbound internet access that NSGs permit unless you explicitly block it. It is free, requires no additional infrastructure, and its simplicity aligns perfectly with the requirement to secure a single VM hosting a web application.

Why this answer

A Network Security Group (NSG) is the correct choice because it is a managed Azure service that provides a stateful, layer-3/4 firewall for filtering inbound and outbound traffic to a virtual machine. With minimal configuration, you can create inbound rules to allow HTTP (TCP/80) and HTTPS (TCP/443) from the internet (source 'Internet' or 'Any') and an outbound rule to allow all traffic to the internet (default outbound rule already allows this). NSGs are directly associated with a VM's subnet or network interface, making them the simplest managed solution for this scenario.

Exam trap

The trap here is that candidates often overthink and choose Azure Firewall or Application Gateway for simple traffic filtering, forgetting that an NSG is the most lightweight, cost-effective, and minimal-configuration managed service for basic inbound/outbound access control on a single VM.

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 requires additional configuration for routing rules, health probes, and SSL termination; it is overkill for simply allowing inbound HTTP/HTTPS and outbound internet traffic to a single VM. Option B is wrong because Azure Firewall is a fully managed, centralized network security service designed for hub-and-spoke topologies and enterprise-level traffic inspection, not for minimal configuration on a single VM; it introduces unnecessary complexity and cost. Option D is wrong because Azure Bastion is a managed service for secure RDP/SSH access to VMs via the Azure portal, not for allowing HTTP/HTTPS inbound traffic or general outbound internet traffic.

Practice this question →

13

MCQhard

Your organization has deployed Azure Front Door Premium with Web Application Firewall (WAF) policy in front of an Azure App Service. You need to ensure that only traffic from Azure Front Door is allowed to reach the App Service, and all other traffic is blocked. Which configuration should you implement?

A.Configure IP restrictions on the App Service to allow only the Azure Front Door service tag AzureFrontDoor.Backend.

B.Configure the App Service to require client certificates and configure Azure Front Door to present a certificate.

C.Set the App Service access restrictions to deny all and then add a rule to allow the Azure Front Door service tag AzureFrontDoor.Frontend.

D.Configure a WAF policy to block all requests that do not contain the X-Azure-FDID header.

AnswerA

The AzureFrontDoor.Backend service tag covers the IP ranges that Azure Front Door's origin-facing servers use when they forward requests to your App Service. By adding an access restriction that allows only this service tag, any request that does not originate from those backend IPs—including direct traffic to the App Service's public URL—is rejected. This is the standard, low-overhead method for locking down an App Service origin to only receive traffic from Front Door.

Why this answer

The Azure Front Door Premium service tag 'AzureFrontDoor.Backend' represents the backend IP address range used by Azure Front Door to forward traffic to the origin. By configuring IP restrictions on the App Service to allow only this service tag, you ensure that only traffic originating from Azure Front Door can reach the App Service, effectively blocking all other traffic.

Exam trap

The trap here is confusing the Azure Front Door service tags 'AzureFrontDoor.Backend' and 'AzureFrontDoor.Frontend', where candidates often select the frontend tag (Option C) thinking it represents the traffic source, but the backend tag is required to allow the actual forwarding traffic from Front Door to the origin.

How to eliminate wrong answers

Option B is wrong because requiring client certificates on the App Service and having Azure Front Door present a certificate authenticates the Front Door instance to the App Service, but it does not block traffic that bypasses Front Door entirely; a direct request to the App Service without a valid certificate would be rejected, but this does not prevent other traffic from reaching the App Service if the certificate requirement is misconfigured or bypassed. Option C is wrong because the service tag 'AzureFrontDoor.Frontend' represents the Front Door frontend IP addresses used for incoming client traffic, not the backend IPs that forward requests to the origin; using this tag would allow traffic from Front Door's edge but not the actual backend traffic, potentially blocking legitimate Front Door requests. Option D is wrong because configuring a WAF policy to block requests without the 'X-Azure-FDID' header is a valid additional security measure, but it does not prevent direct traffic to the App Service that bypasses Front Door entirely; the WAF policy is applied at the Front Door level, not at the App Service, so requests sent directly to the App Service would not be inspected by the WAF.

Practice this question →

14

MCQeasy

A security administrator is troubleshooting network connectivity to an Azure virtual machine. The VM is behind a network security group (NSG) that has a deny-all inbound rule as the default. The administrator wants to quickly verify whether a specific TCP packet on port 3389 from their client IP (203.0.113.50) would be allowed or blocked by the NSG. Which Azure Network Watcher tool should they use?

A.Network Performance Monitor.

B.IP flow verify.

C.Next hop.

D.NSG diagnostics (flow logs).

AnswerB

IP flow verify, part of Azure Network Watcher, takes a specified protocol, source IP/port, destination IP/port, and the target virtual machine’s network interface to simulate an actual packet. The tool then evaluates the effective security rules applied at both the subnet and network interface levels and returns an allow or deny decision along with the exact rule that allowed or blocked the traffic. This makes it the correct choice for validating NSG rules because it directly answers whether a specific packet is permitted in real time.

Why this answer

IP flow verify is the correct tool because it tests whether a specific packet (source IP, destination IP, protocol, port) is allowed or denied by an NSG or virtual network (VNet) route. In this scenario, the administrator needs to quickly validate inbound TCP traffic on port 3389 from client IP 203.0.113.50 to the VM, and IP flow verify provides a pass/fail result along with the exact rule that caused the outcome.

Exam trap

The trap here is that candidates often confuse NSG flow logs (which provide historical traffic data) with the real-time diagnostic capability of IP flow verify, leading them to select NSG diagnostics (flow logs) instead of the correct tool for on-demand packet testing.

How to eliminate wrong answers

Option A is wrong because Network Performance Monitor is a tool for monitoring network latency, packet loss, and performance between endpoints, not for testing NSG rule evaluation for a specific packet. Option C is wrong because Next hop shows the next hop type and IP address for traffic from a VM, but it does not evaluate NSG rules or indicate whether a packet is allowed or blocked. Option D is wrong because NSG diagnostics (flow logs) record information about IP traffic flowing through an NSG after the fact, but they are not designed for real-time, on-demand verification of a single packet's allow/deny status.

Practice this question →

15

MCQhard

A company has deployed Azure Firewall in a hub virtual network with forced tunneling enabled. Spoke virtual networks are peered to the hub. The security team reports that outbound traffic from the spoke VMs is bypassing the firewall. What is the most likely reason?

A.The Azure Firewall policy has an allow-all network rule.

B.Azure Firewall is deployed in the same virtual network as the spoke VMs.

C.The spoke virtual networks are not peered to the hub.

D.The spoke subnets do not have a route table with a default route (0.0.0.0/0) pointing to the Azure Firewall.

AnswerD

Without a UDR forcing traffic to the firewall, spoke VMs will use the default internet route, bypassing the firewall.

Why this answer

Forced tunneling on Azure Firewall requires that all outbound traffic from spoke VMs is routed to the firewall via a user-defined route (UDR) with a default route (0.0.0.0/0) pointing to the firewall's private IP as the next hop. Without this route, traffic from spoke subnets will use the default system route and bypass the firewall, even if the firewall itself is configured with forced tunneling.

Exam trap

The trap here is that candidates often assume forced tunneling on the firewall itself automatically redirects all spoke traffic, but in reality, forced tunneling only affects traffic from the firewall's own subnet; spoke subnets require explicit UDRs to route traffic to the firewall.

How to eliminate wrong answers

Option A is wrong because an allow-all network rule in the firewall policy would permit traffic that reaches the firewall, but it does not cause traffic to bypass the firewall; the issue is that traffic never reaches the firewall. Option B is wrong because Azure Firewall must be deployed in a dedicated subnet (AzureFirewallSubnet) in the hub, not in the same virtual network as the spoke VMs; if it were in the same VNet, it would still require UDRs to direct traffic to it. Option C is wrong because the question states that spoke virtual networks are peered to the hub, so this is not the cause; even if peering were missing, traffic would not flow at all, not bypass the firewall.

Practice this question →

16

MCQeasy

Your company uses Azure Firewall to protect a virtual network. The security team needs to allow outbound HTTPS traffic from a specific subnet to a set of FQDNs, such as '*.contoso.com', while blocking all other outbound traffic. Which type of Azure Firewall rule should they configure?

A.A network rule with destination port 443 and protocol TCP, and the destination IP address set to the resolved IPs of the FQDNs

B.An application rule with the 'Https' protocol and the target FQDNs set to '*.contoso.com'

C.A NAT rule that translates the source IP to a public IP and allows traffic to any destination on port 443

D.A DNAT rule that redirects outbound HTTPS traffic to an internal proxy server

AnswerB

Application rules are designed to allow or deny outbound traffic based on FQDNs. For HTTPS traffic, you can specify the target FQDNs and the protocol (Https). This is the correct configuration to allow traffic to specific domains while blocking others.

Why this answer

Azure Firewall application rules are specifically designed to allow outbound HTTP/HTTPS traffic based on fully qualified domain names (FQDNs). By configuring an application rule with protocol 'Https' and target FQDNs set to '*.contoso.com', the firewall inspects the TLS Server Name Indication (SNI) extension to match the requested domain, allowing traffic only to the specified FQDNs while blocking all other outbound traffic.

Exam trap

The trap here is that candidates often confuse network rules (which filter by IP/port) with application rules (which filter by FQDN), leading them to choose Option A because they think resolved IPs are sufficient, ignoring the dynamic nature of FQDNs and the need for domain-level control.

How to eliminate wrong answers

Option A is wrong because network rules filter traffic based on source/destination IP addresses and ports, not FQDNs; using resolved IPs would break if the FQDNs resolve to dynamic IPs or multiple IPs, and it cannot enforce domain-level filtering. Option C is wrong because a NAT rule translates source IP addresses for outbound traffic but does not filter destinations; it would allow HTTPS traffic to any destination, not just '*.contoso.com'. Option D is wrong because a DNAT rule is used for inbound traffic (destination network address translation) to redirect incoming connections to an internal resource, not for outbound traffic filtering.

Practice this question →

17

MCQmedium

A company has two Azure virtual networks in different Azure regions that need to communicate with each other. The security policy mandates that all inter-region traffic must be encrypted over the public internet. Which connectivity solution should the company implement to meet this requirement?

A.VNet peering

B.Azure VPN Gateway (site-to-site connection)

C.Azure ExpressRoute

D.Azure Firewall

AnswerB

An Azure VPN Gateway site-to-site connection is the correct choice because it creates an IPsec tunnel using IKE and IPsec protocols, encrypting all data in transit between the two VNets as it travels over the public internet. Each VNet has a gateway endpoint that terminates the secure tunnel, with authentication via pre-shared keys or certificates, and route-based gateways support VNet-to-VNet connections with dynamic routing. This ensures confidentiality and integrity of traffic, which VNet peering does not provide by default.

Why this answer

Azure VPN Gateway with a site-to-site (S2S) connection is the correct solution because it establishes an encrypted IPSec tunnel over the public internet between the two virtual networks. This meets the security mandate for encryption of inter-region traffic traversing the public internet, as IPSec provides confidentiality, integrity, and authentication at the network layer.

Exam trap

The trap here is that candidates often confuse VNet peering (which is private and free of charge within a region) as automatically encrypted, but it does not encrypt traffic over the public internet because it uses Azure's backbone; the question explicitly requires encryption over the public internet, which only a VPN gateway provides.

How to eliminate wrong answers

Option A is wrong because VNet peering uses the Microsoft backbone network, not the public internet, and traffic is not encrypted by default; it relies on Azure's private network infrastructure, which does not satisfy the 'encrypted over the public internet' requirement. Option C is wrong because Azure ExpressRoute uses a dedicated private connection that bypasses the public internet entirely, so it does not meet the 'over the public internet' condition, and encryption is optional (e.g., via MACsec or IPsec over ExpressRoute). Option D is wrong because Azure Firewall is a stateful network security service that filters and inspects traffic but does not provide site-to-site VPN connectivity or encryption between virtual networks; it can be used in conjunction with a VPN gateway but is not a connectivity solution itself.

Practice this question →

18

MCQmedium

You are deploying a web application in Azure that must be accessible only from your corporate network via HTTPS. You have an Azure Application Gateway with a Web Application Firewall (WAF) policy. Your corporate network uses public IP addresses from a specific range. Which configuration should you use to restrict access?

A.Configure a WAF policy with a custom rule to allow traffic only from the corporate IP range and deny all other traffic.

B.Create a network security group (NSG) on the subnet hosting the application gateway and allow only the corporate IP range.

C.Use Azure Front Door with a WAF policy and geo-filtering to allow only your country.

D.Set up a private endpoint for the application gateway and disable public access.

AnswerA

A WAF policy attached to the Application Gateway can use custom rules to match on the source IP address of incoming requests. You would create a rule that permits traffic only from your corporate IP CIDR range and a subsequent (or lower-priority) rule that denies all other traffic, effectively whitelisting the corporate network. Since WAF operates at Layer 7, this restriction works alongside HTTPS termination or pass-through and does not affect the transport-level encryption.

Why this answer

Azure Application Gateway's WAF policy supports custom rules that can inspect source IP addresses and allow or deny traffic based on them. By creating a custom rule with a condition matching the corporate public IP range and setting the action to 'Allow', then adding a default 'Deny' rule, you restrict access exclusively to that range over HTTPS. This approach works at the application layer (Layer 7) and is independent of network-level controls, making it the most direct and supported method for IP-based restriction on the gateway itself.

Exam trap

The trap here is that candidates often confuse network-layer controls (NSGs) with application-layer controls (WAF custom rules) and assume an NSG on the gateway subnet is the correct way to restrict access, but NSGs block traffic before the WAF can inspect it, breaking the intended security model.

How to eliminate wrong answers

Option B is wrong because an NSG applied to the Application Gateway subnet would block traffic before it reaches the gateway's WAF, preventing the WAF from inspecting legitimate traffic and potentially breaking health probes or backend communication; NSGs are for network-layer filtering, not for application-layer IP restriction on the gateway. Option C is wrong because Azure Front Door with geo-filtering restricts by country, not by specific corporate IP range, and introduces an additional service that is not required for this scenario; the question explicitly requires access only from a specific corporate IP range, not a geographic region. Option D is wrong because a private endpoint for the Application Gateway is not a supported configuration—private endpoints are used for PaaS services like Storage or SQL, not for Application Gateway; disabling public access would make the gateway unreachable from the corporate network if it relies on public IPs.

Practice this question →

19

Drag & Dropmedium

Drag and drop the steps to configure Azure AD Conditional Access policy to require MFA for all users into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Conditional Access policies require defining users and access controls before enabling.

Practice this question →

20

MCQmedium

A company runs a public-facing web application on Azure App Service in the West US region. They want to protect against network-layer (Layer 3/4) DDoS attacks. The application consists of a single App Service instance. Which Azure DDoS Protection tier should they enable to meet this requirement while minimizing cost?

A.Basic

B.Standard

C.Premium

D.No protection is needed because Azure App Service is inherently protected against DDoS attacks.

AnswerA

DDoS Protection Basic is free and automatically included for all Azure resources. It provides protection against common network-layer attacks, making it the simplest and most cost-effective choice for a single web application.

Why this answer

Azure DDoS Protection Basic is automatically enabled at no additional cost for all Azure services, including App Service. It provides always-on traffic monitoring and real-time mitigation of common network-layer (Layer 3/4) attacks, such as SYN floods, UDP floods, and reflection attacks, which meets the requirement to protect the public-facing web application. Since the company wants to minimize cost and only needs Layer 3/4 protection for a single App Service instance, the Basic tier is sufficient.

Exam trap

The trap here is that candidates often assume Azure App Service has no built-in DDoS protection and that they must purchase a paid tier, but Azure DDoS Protection Basic is automatically enabled and free, making it the correct choice for cost-effective Layer 3/4 protection.

How to eliminate wrong answers

Option B is wrong because Azure DDoS Protection Standard is a paid tier that provides enhanced mitigation capabilities, including adaptive tuning, attack analytics, and protection for virtual networks, but it is not required for a single App Service instance and would incur unnecessary cost. Option C is wrong because Azure DDoS Protection does not have a Premium tier; the only two tiers are Basic and Standard. Option D is wrong because while Azure App Service benefits from the always-on Basic DDoS protection, it is not inherently protected beyond that baseline; the statement that 'no protection is needed' is misleading because Basic protection is already active and meets the requirement, but the option implies no protection exists, which is incorrect.

Practice this question →

21

MCQeasy

A company has an Azure virtual network with subnets SubnetA and SubnetB. They deploy a network virtual appliance (NVA) in a subnet called NVA_Subnet. They want all traffic between SubnetA and SubnetB to be routed through the NVA for inspection. What is the minimum number of route tables and routes required?

A.One route table with a route for each subnet via the NVA

B.Two route tables, each with a route to the other subnet via the NVA

C.No route tables needed; enable IP forwarding on the NVA

D.One route table with a single default route (0.0.0.0/0) via the NVA

AnswerB

A route table associated with a subnet influences only traffic originating from that subnet. Because subnet A and subnet B have different destination prefixes for their inter-subnet traffic, the proper design is two custom route tables, one bound to each subnet, each containing a single route: for subnet A, destination subnet B's address prefix with next hop set to the NVA; for subnet B, destination subnet A's prefix with next hop to the NVA. This forces the NVA to inspect every packet crossing between the two subnets while leaving all other traffic to the system routes.

Why this answer

Azure route tables are associated with subnets, not the virtual network as a whole. To force traffic between SubnetA and SubnetB through the NVA, you need two separate route tables: one for SubnetA with a route to SubnetB's address space with the next hop set to the NVA's private IP, and one for SubnetB with a route to SubnetA's address space with the next hop set to the NVA's private IP. This ensures bidirectional traffic is inspected.

Exam trap

The trap here is that candidates assume a single route table can be applied to multiple subnets or that a default route (0.0.0.0/0) will force inter-subnet traffic through the NVA, when in fact Azure requires explicit routes for each subnet's destination address space and separate route table associations per subnet.

How to eliminate wrong answers

Option A is wrong because a single route table cannot be associated with both subnets simultaneously; each subnet can have only one route table, and a single route table with routes for both subnets would require associating it with both subnets, which is not possible in Azure. Option C is wrong because IP forwarding on the NVA is necessary but not sufficient; without custom routes, Azure's default system routes would allow direct communication between SubnetA and SubnetB, bypassing the NVA. Option D is wrong because a default route (0.0.0.0/0) via the NVA would send all internet-bound traffic through the NVA, not specifically traffic between the two subnets, and would not force inter-subnet traffic through the NVA unless the subnets' address spaces are also covered by the default route, which is not the intended design.

Practice this question →

22

MCQhard

Your organization has multiple Azure subscriptions connected via a hub-spoke topology using Azure Firewall in the hub. You need to ensure that traffic between spoke VNets is routed through the firewall for inspection. You configure user-defined routes (UDRs) on the spoke subnets. However, traffic between spokes is still bypassing the firewall. What is the most likely reason?

A.Azure Firewall does not support traffic between spoke VNets.

B.The UDR on the firewall subnet does not include the spoke address spaces.

C.The 'Allow gateway transit' setting is disabled on the spoke peering.

D.The 'Use remote gateway' setting is disabled on the spoke VNet peering.

AnswerD

Spoke VNets must use remote gateway to route traffic through the hub firewall.

Why this answer

In a hub-spoke topology with Azure Firewall, the 'Use remote gateway' setting on the spoke VNet peering must be disabled. This setting is only for using a VPN or ExpressRoute gateway in the hub; it does not enable routing through Azure Firewall. With this setting disabled, the configured UDRs on the spoke subnets can direct spoke-to-spoke traffic to the firewall for inspection.

Exam trap

The trap is that candidates may think 'Use remote gateway' must be enabled to force traffic through the hub firewall; in fact, it should remain disabled because it applies to VPN/ExpressRoute gateways, not Azure Firewall. UDRs are the correct mechanism for routing spoke-to-spoke traffic through the firewall.

How to eliminate wrong answers

Option A is wrong because Azure Firewall fully supports traffic inspection between spoke VNets when properly configured with UDRs and peering settings. Option B is wrong because the UDR on the firewall subnet is not required for spoke-to-spoke routing; the firewall subnet itself does not need UDRs to forward traffic—it uses its own routing table. Option C is wrong because 'Allow gateway transit' is a setting on the hub VNet peering (not the spoke) and is used to allow the hub to advertise routes to the spoke; it does not directly control spoke-to-spoke traffic routing through the firewall.

Practice this question →

23

MCQhard

You are designing a network security strategy for an Azure Kubernetes Service (AKS) cluster. You need to restrict egress traffic from the cluster to only allow connections to specific Azure services (e.g., Microsoft Container Registry, Azure Key Vault). The solution must minimize administrative overhead. What should you use?

A.Configure Azure Policy to deny egress to non-approved destinations.

B.Deploy Azure Firewall and use FQDN tags to allow traffic to Azure services.

C.Use Kubernetes network policies for egress.

D.Define NSG rules to allow outbound traffic to the service IP ranges.

AnswerB

FQDN tags simplify allowing traffic to popular Azure services without managing IPs.

Why this answer

Azure Firewall with FQDN tags allows you to define outbound network rules based on fully qualified domain names (FQDNs) for Azure services like Microsoft Container Registry and Azure Key Vault. This approach minimizes administrative overhead because FQDN tags are automatically updated as Azure service IP ranges change, eliminating the need for manual IP maintenance. It provides a centralized, managed firewall solution that integrates natively with AKS for egress filtering.

Exam trap

The trap here is that candidates often assume Kubernetes network policies can control egress to external services, but they only apply to traffic between pods within the cluster, not to outbound traffic leaving the AKS node's virtual network.

How to eliminate wrong answers

Option A is wrong because Azure Policy is a governance tool for enforcing compliance rules on resource configurations, not a network security mechanism to filter or block egress traffic at the packet level. Option C is wrong because Kubernetes network policies operate at the pod level within the cluster and cannot control egress traffic to external Azure services outside the cluster's virtual network. Option D is wrong because NSG rules require specifying static IP ranges for Azure services, which change frequently and would require constant manual updates, increasing administrative overhead and risking connectivity failures.

Practice this question →

24

Drag & Dropmedium

Drag and drop the steps to create an Azure Key Vault firewall rule to allow access from a specific virtual network into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The firewall configuration is under networking, and you must add the virtual network to allow traffic.

Practice this question →

25

MCQmedium

You have an Azure Web Application Firewall (WAF) policy associated with an Azure Front Door instance. You want to block requests from a specific country (e.g., Country X) unless the request includes a valid API key. How should you configure this?

A.Use a geo-match custom rule to allow all countries except Country X, and use a rate limit rule to block Country X.

B.Configure IP restriction on the origin to block Country X IPs.

C.Configure the WAF policy to use 'Prevention' mode and add a managed rule set that includes the country block.

D.Use a geo-match custom rule to block Country X, and create a separate custom rule with higher priority to allow traffic from Country X if the request contains the API key header.

AnswerD

This approach works because Azure WAF evaluates custom rules in strict priority order, with lower numeric priority values evaluated first. Create an allow custom rule with a higher priority (for example, priority 1) that matches requests from Country X only when the required API key header is present and sets the action to Allow; then create a lower-priority block rule (for example, priority 2) with a geo-match condition for Country X. When a request from Country X contains the API key, the allow rule matches first and stops further evaluation, bypassing the block rule. Requests from Country X without the API key do not match the allow rule, fall through to the block rule, and are denied.

Why this answer

Azure WAF custom rules are evaluated in priority order, and a higher-priority 'allow' rule can override a lower-priority 'block' rule. By creating a geo-match rule to block Country X, and then a separate custom rule with a higher priority (lower numeric value) that allows requests from Country X if they contain a valid API key header, you achieve the conditional access requirement. This leverages WAF's ability to inspect request headers and apply logic based on multiple conditions within a single policy.

Exam trap

The trap here is that candidates often think geo-blocking must be done with a single rule or that managed rule sets can handle geography, but Azure WAF requires custom rules for geo-filtering and relies on rule priority to implement conditional overrides.

How to eliminate wrong answers

Option A is wrong because a geo-match custom rule to allow all countries except Country X would still allow Country X traffic (since it's not explicitly blocked), and a rate limit rule limits request frequency, not blocks based on geography or API key presence. Option B is wrong because IP restrictions on the origin are applied after the WAF, cannot inspect API keys, and would block all traffic from Country X IPs regardless of API key, which does not meet the conditional requirement. Option C is wrong because managed rule sets do not include a 'country block' capability; geo-filtering is only available through custom rules, and 'Prevention' mode simply enables action on matched rules, it does not add geo-blocking logic.

Practice this question →

26

Multi-Selectmedium

Which TWO Azure services can be used to filter inbound internet traffic to a virtual network? (Choose two.)

Select 2 answers

A.Azure Firewall

B.Azure Bastion

C.Azure Front Door

D.Network security group (NSG)

E.VPN gateway

AnswersA, D

Correct. Azure Firewall can filter inbound internet traffic using network and application rules at Layers 3-7.

Why this answer

Both Azure Firewall and Network Security Groups (NSGs) can filter inbound internet traffic to a virtual network. Azure Firewall provides centralized, stateful filtering at Layers 3-7 with features like threat intelligence and application rules. NSGs are distributed, stateful packet filters that apply to subnets or NICs, filtering traffic based on source/destination IP, port, and protocol rules, and are commonly used to block inbound internet traffic at the subnet boundary.

Exam trap

The trap here is that candidates may overlook NSGs because they are a basic security feature, thinking only a dedicated firewall service can filter inbound traffic. However, NSGs are perfectly capable of filtering inbound internet traffic at the network layer. Another common mistake is selecting Azure Bastion, which is a secure jump box for management traffic, not a general traffic filter.

Practice this question →

27

MCQhard

A company has two Azure virtual networks, VNet-A and VNet-B, connected via VNet peering. They want all traffic between the VNets to be inspected by a network virtual appliance (NVA) deployed in a subnet in VNet-A. They have configured a user-defined route (UDR) on the subnet in VNet-B that points the destination address space of VNet-A to the private IP of the NVA. However, traffic between the VNets is still not passing through the NVA. What is the most likely cause?

A.The UDR is not associated with the subnet in VNet-B.

B.The NVA's network interface (NIC) does not have IP forwarding enabled.

C.The VNet peering connection is not in a 'Connected' state.

D.The NVA is deployed in the same subnet as the source VMs.

AnswerB

IP forwarding must be explicitly enabled on the network interface (NIC) of the NVA before Azure will deliver packets whose destination IP is not assigned to that NIC. Without it, the Azure fabric drops packets that are addressed to other IPs, so even if the NVA's operating system is configured to route traffic, the packets never reach it. This is the most common omission when deploying NVAs with UDRs, and it precisely explains why traffic flows end-to-end via peering but not through the NVA — the NVA silently discards (or never receives) the forwarded packets.

Why this answer

The most likely cause is that the NVA's network interface (NIC) does not have IP forwarding enabled. Even with a correctly configured UDR on VNet-B pointing traffic to the NVA's private IP, the NVA will drop any traffic not destined for its own IP unless IP forwarding is enabled on its NIC. This setting allows the NVA to accept packets with a destination other than itself and forward them based on its routing table, which is essential for traffic inspection scenarios.

Exam trap

The trap here is that candidates often focus on UDR configuration or peering state, overlooking the critical NIC-level IP forwarding setting that is required for any NVA to function as a transit hop in Azure.

How to eliminate wrong answers

Option A is wrong because the question explicitly states that a UDR has been configured on the subnet in VNet-B, implying it is associated; if it were not associated, the UDR would have no effect, but the core issue here is the NVA's inability to forward traffic. Option C is wrong because if the VNet peering were not in a 'Connected' state, no traffic would flow between the VNets at all, but the question indicates traffic is still passing (just not through the NVA), so peering is functional. Option D is wrong because the NVA being in the same subnet as source VMs does not inherently prevent traffic inspection; UDRs can still direct traffic to the NVA, but the NVA's NIC must have IP forwarding enabled to process and forward that traffic.

Practice this question →

28

MCQhard

A company has two Azure virtual networks (VNet-A and VNet-B) connected via VNet peering. They need to ensure that all traffic between the two VNets is encrypted using IPsec and that no traffic can bypass the encryption. The security team has enabled the 'Use remote virtual network gateways' setting on the peering. However, traffic is still flowing unencrypted. What additional configuration is required to enforce encryption for all traffic between the VNets?

A.Enable 'Azure virtual network encryption' on both VNets and configure the encryption policy.

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

C.Configure a network security group (NSG) rule on each subnet to deny traffic that is not IPsec encapsulated.

D.Enable 'Allow gateway transit' on VNet-A and 'Use remote virtual network gateways' on VNet-B, and then create a VPN gateway in VNet-A.

AnswerA

Azure virtual network encryption (currently in preview) encrypts all traffic between VNets using IPsec. Enabling it on both sides ensures traffic is encrypted.

Why this answer

Azure Virtual Network Encryption provides a platform-level encryption mechanism that encrypts all traffic between virtual networks, including VNet peering traffic, without requiring a VPN gateway. Enabling this feature on both VNets and configuring the encryption policy ensures that all inter-VNet traffic is encrypted using IPsec, and since it is enforced at the infrastructure level, no traffic can bypass the encryption. The 'Use remote virtual network gateways' setting alone does not encrypt traffic; it only allows a VNet to use a remote gateway for transit routing.

Exam trap

The trap here is that candidates often assume that enabling 'Use remote virtual network gateways' on VNet peering automatically encrypts traffic, when in fact it only allows gateway transit and does not provide any encryption; the real solution is Azure Virtual Network Encryption, which is a separate feature that must be explicitly enabled.

How to eliminate wrong answers

Option B is wrong because deploying Azure VPN Gateways and creating a site-to-site VPN connection would encrypt traffic between the VNets, but it does not prevent unencrypted traffic from flowing through the VNet peering if the peering is still active; the question requires that no traffic can bypass encryption, and a VPN gateway does not disable the existing peering path. Option C is wrong because NSG rules operate at the network layer and cannot inspect or enforce IPsec encapsulation; they can only filter based on IP addresses, ports, and protocols, not the presence of IPsec headers, so they cannot ensure that all traffic is encrypted. Option D is wrong because enabling 'Allow gateway transit' and 'Use remote virtual network gateways' allows a VNet to use a VPN gateway in another VNet for outbound connectivity, but it does not encrypt traffic between the VNets themselves; the peering traffic remains unencrypted unless Azure Virtual Network Encryption or a direct VPN connection is configured.

Practice this question →

29

MCQeasy

A company deploys Azure virtual machines in a virtual network. A security policy requires that only Remote Desktop Protocol (RDP) traffic from the corporate VPN's public IP address (203.0.113.0/26) is allowed. All other inbound RDP traffic must be denied. Which configuration should be applied to the network security group (NSG) associated with the VM subnet?

A.Add an inbound rule to allow RDP from the Internet and a deny rule for RDP from the corporate IP.

B.Add an inbound rule to deny RDP from the corporate IP and a default deny all inbound.

C.Add an inbound rule to allow RDP from the corporate IP range, and add a default deny rule for all other inbound RDP traffic.

D.No additional rules are needed because the default NSG rules already deny RDP.

AnswerC

To allow RDP only from the corporate IP range, you must create an inbound NSG rule with priority number lower than any competing deny rule, permitting traffic from that source to TCP port 3389. Then a second inbound rule with a higher priority number (lower precedence) should deny RDP from all other sources, ensuring that any traffic not matching the corporate allow rule is blocked. This pair of rules works with the default DenyAllInbound rule to restrict unauthorized access while preserving the required administrative path.

Why this answer

The requirement is to allow RDP (TCP port 3389) only from the corporate VPN's public IP range (203.0.113.0/26) and deny all other inbound RDP traffic. An NSG processes rules in priority order; by adding an inbound allow rule for the corporate IP range with a high priority (e.g., 100) and relying on the default deny rule (which denies all inbound traffic not explicitly allowed), only RDP from the specified range is permitted. This matches the security policy precisely.

Exam trap

The trap here is that candidates often forget that NSGs have default rules that allow inbound traffic from the virtual network and Azure load balancer, and they mistakenly think a default deny rule already blocks all RDP, when in fact you must explicitly allow the specific source IP and rely on the default deny to block everything else.

How to eliminate wrong answers

Option A is wrong because it allows RDP from the Internet (which violates the policy) and then denies RDP from the corporate IP (which would block the allowed traffic). Option B is wrong because it denies RDP from the corporate IP (the only source that should be allowed) and relies on a default deny all inbound, which would block all RDP traffic entirely. Option D is wrong because the default NSG rules allow inbound RDP from the virtual network and Azure load balancer, but not from the Internet; they do not restrict RDP to a specific public IP range, so additional rules are required.

Practice this question →

30

MCQmedium

A company is designing a hub-spoke network topology with Azure Firewall in the hub virtual network. Spoke virtual networks are peered to the hub. They want 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's private IP address as the next hop. However, traffic is still bypassing the firewall. What is the most likely cause?

A.The Azure Firewall is in a different region than the spoke VNet.

B.The route table is not associated to the spoke subnet.

C.The Azure Firewall does not have the correct network and application rules configured.

D.The spoke VNet has the 'Use remote virtual network gateways' setting disabled.

AnswerB

A user-defined route table only takes effect when it is explicitly associated with a subnet; simply creating a route table and adding a route to the firewall's private IP does nothing otherwise. Without that association, the subnet uses Azure's default system routes, which send traffic between peered VNets directly, bypassing the firewall entirely. This is the classic cause of 'spoke traffic isn't going through the firewall' when the routes appear to be configured correctly.

Why this answer

The most likely cause is that the route table with the default route (0.0.0.0/0) pointing to the Azure Firewall's private IP has not been associated to the spoke subnet. Without this association, the route table is not applied to the subnet's traffic, so the default system route (which directs internet traffic directly to the internet) remains in effect, bypassing the firewall. Associating the route table to the subnet is a required step for user-defined routes (UDRs) to influence traffic flow.

Exam trap

The trap here is that candidates often assume creating a route table and adding a default route is sufficient, overlooking the critical step of associating the route table to the subnet, which is a distinct configuration action in the Azure portal or CLI.

How to eliminate wrong answers

Option A is wrong because Azure Firewall can be in a different region than the spoke VNet and still function correctly; cross-region peering supports traffic routing through the firewall as long as the route table is properly associated. Option C is wrong because network and application rules on the firewall control which traffic is allowed or denied, but they do not affect whether traffic is routed to the firewall in the first place; the routing issue occurs before the firewall inspects packets. Option D is wrong because the 'Use remote virtual network gateways' setting is relevant only for VPN/ExpressRoute gateway transit scenarios, not for routing traffic to an Azure Firewall via a UDR.

Practice this question →

31

MCQmedium

A company uses Azure Firewall to filter outbound traffic. They want to ensure that all DNS queries from virtual machines in a spoke VNet are routed through the Azure Firewall for logging and inspection. They have already configured the firewall to use a custom DNS server. Which additional Azure Firewall feature must be enabled to ensure that the VMs use the firewall as a DNS proxy?

A.Enable DNS proxy on the firewall policy

B.Configure a DNS forwarding rule

C.Enable Threat Intelligence DNS logging

D.Create a NAT rule for DNS traffic

AnswerA

Enabling DNS proxy on the Azure Firewall policy is the correct choice because it makes the firewall's private IP address the DNS server for virtual networks. VMs send DNS queries to the firewall, which then forwards them to the configured DNS server, ensuring that all outbound DNS traffic traverses the firewall for inspection and filtering. This gives a single, consistent path for DNS egress and enables FQDN-based rules to be applied to outbound traffic.

Why this answer

Enabling DNS proxy on the Azure Firewall policy allows the firewall to act as a DNS proxy for the virtual machines in the spoke VNet. When DNS proxy is enabled, the firewall listens on port 53 and forwards DNS queries from the VMs to the configured custom DNS server, ensuring all DNS traffic is logged and inspected. This is required even after setting a custom DNS server on the firewall, as the VMs must be configured to use the firewall's private IP address as their DNS server, and the proxy handles the forwarding.

Exam trap

The trap here is that candidates often confuse enabling DNS proxy with simply configuring a custom DNS server on the firewall, or they think that a NAT rule or forwarding rule alone will route DNS traffic through the firewall, but without the DNS proxy feature, the firewall does not listen on port 53 and cannot intercept DNS queries from VMs.

How to eliminate wrong answers

Option B is wrong because configuring a DNS forwarding rule is used to forward specific DNS queries to different DNS servers based on domain names, but it does not enable the firewall to act as a DNS proxy for all VM DNS traffic; the VMs still need to point to the firewall's IP, and the proxy feature must be enabled. Option C is wrong because enabling Threat Intelligence DNS logging only logs DNS queries that match threat intelligence indicators, but it does not route or proxy DNS traffic through the firewall; it is a logging feature, not a routing mechanism. Option D is wrong because creating a NAT rule for DNS traffic would translate the destination IP of DNS queries, but it does not make the firewall a DNS proxy; the VMs would still need to send DNS queries directly to the firewall's IP, and without DNS proxy, the firewall does not listen on port 53 for DNS queries.

Practice this question →

32

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 →

33

MCQhard

Refer to the exhibit. A security administrator runs the Azure CLI commands to create a VM with a single NIC and applies an NSG rule to deny outbound TCP traffic to the Internet on ports 80 and 443. However, the VM can still access websites on the Internet. What is the most likely reason?

A.The NSG rule uses the 'Internet' service tag incorrectly; it should specify an IP range.

B.The NSG is not associated with the NIC because the command did not specify the NIC correctly.

C.The NSG rule is applied at the NIC level, but the subnet's NSG (if any) has a default outbound allow rule that takes precedence.

D.The NSG rule should be an inbound rule to block outbound traffic.

AnswerC

If the subnet has no NSG, the default outbound allow rule permits traffic, and the NIC NSG rule is not evaluated because the first match (subnet default allow) applies.

Why this answer

When an NSG is associated with both a subnet and a NIC, effective security rules are evaluated in order of priority, and subnet-level NSG rules are evaluated before NIC-level NSG rules. If the subnet has a default outbound allow rule (or a higher-priority allow rule), it will permit outbound TCP traffic to the Internet on ports 80 and 443, overriding the deny rule applied at the NIC level. The VM can still access websites because the subnet NSG's default outbound allow rule takes precedence over the NIC-level deny rule.

Exam trap

The trap here is that candidates often assume NIC-level NSG rules always take precedence over subnet-level NSG rules, but in reality, subnet-level rules are evaluated first and can allow traffic that NIC-level rules would deny.

How to eliminate wrong answers

Option A is wrong because the 'Internet' service tag is correctly used to represent all public IP addresses reachable via the Internet, and specifying an IP range would be impractical and less secure. Option B is wrong because the Azure CLI command to create a VM with a single NIC and apply an NSG rule typically associates the NSG with the NIC correctly if the command syntax is correct; the question states the command was run, so the NSG is likely associated. Option D is wrong because outbound traffic is controlled by outbound NSG rules, not inbound rules; inbound rules only control traffic entering the NIC or subnet.

Practice this question →

34

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 →

35

MCQhard

Refer to the exhibit. You have an Azure Firewall policy with the shown rules. Traffic from 10.0.0.0/8 to www.google.com on HTTPS (443) is being blocked. What is the most likely reason?

A.The network rule collection with priority 100 denies all traffic, and it is evaluated before the application rule collection.

B.The application rule collection has an action of Deny.

C.The source address 10.0.0.0/8 is not included in the application rule.

D.The application rule collection does not allow *.google.com.

AnswerA

Network rules have higher priority than application rules when the action is Deny.

Why this answer

Azure Firewall policy rule collections are evaluated in order of priority, with lower numbers evaluated first. The network rule collection with priority 100 denies all traffic, and since network rules are evaluated before application rules, this deny rule matches the HTTPS traffic from 10.0.0.0/8 to www.google.com before the application rule collection (which would allow it) is ever reached. Therefore, the traffic is blocked by the higher-priority network rule.

Exam trap

The trap here is that candidates often assume application rules are evaluated first or that a deny action in the application rule collection is the cause, but Azure Firewall evaluates network rules before application rules, so a low-priority network deny rule can override a higher-priority application allow rule.

How to eliminate wrong answers

Option B is wrong because the application rule collection's action is Allow (as shown in the exhibit), not Deny, so it would not block traffic. Option C is wrong because the application rule collection does not require the source address to be explicitly listed; application rules apply to all sources unless a specific source condition is configured, and the exhibit shows no source restriction. Option D is wrong because the application rule collection does allow *.google.com (as shown in the exhibit), so that is not the reason for blocking.

Practice this question →

36

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 →

37

Multi-Selecteasy

Which TWO Azure services can be used to distribute incoming traffic across multiple virtual machines in a backend pool while providing layer 7 load balancing? (Choose two.)

Select 2 answers

A.Azure Load Balancer

B.Azure Application Gateway

C.Azure Traffic Manager

D.Azure VPN Gateway

E.Azure Front Door

AnswersB, E

Application Gateway is a layer 7 load balancer with HTTP/HTTPS support.

Why this answer

Azure Application Gateway is a layer 7 load balancer that can distribute incoming traffic across multiple virtual machines in a backend pool based on HTTP/HTTPS attributes such as URL path, host headers, and cookies. It also provides SSL termination, Web Application Firewall (WAF), and session affinity, making it suitable for web application traffic.

Exam trap

The trap here is that candidates often confuse Azure Load Balancer (layer 4) with Azure Application Gateway (layer 7), assuming both can perform HTTP-based routing, but only Application Gateway can inspect and route based on application-layer data.

Practice this question →

38

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 →

39

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 →

40

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 →

41

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 →

42

MCQeasy

A small business has a single Azure subscription with one virtual network containing two subnets: 'Frontend' for web servers and 'Backend' for database servers. The web servers need to access the internet to download updates, but the database servers must not have any outbound internet access. The business also needs to allow remote administration of the web servers from the internet via RDP (port 3389) but only from the IT department's public IP range (203.0.113.0/24). You need to configure network security to meet these requirements using Azure-native services. What should you do?

A.Use a network virtual appliance (NVA) for outbound inspection and configure RDP access via a jump box.

B.Create an NSG for the Frontend subnet with an inbound rule allowing RDP from 203.0.113.0/24, and a default deny for outbound. Then create an NSG for the Backend subnet with a default deny outbound rule.

C.Create a site-to-site VPN from the IT department to Azure and use Azure Bastion for RDP access.

D.Deploy Azure Firewall in the virtual network and configure DNAT rules for RDP and outbound rules for internet access.

AnswerD

Azure Firewall with DNAT rules allows RDP access from the IT department IP range (203.0.113.0/24) to the web servers. Outbound rules can be configured to allow internet access from the Frontend subnet while blocking outbound traffic from the Backend subnet, meeting all requirements efficiently and securely.

Why this answer

Azure Firewall provides a managed, scalable solution for controlling outbound internet access and inbound RDP. You can configure DNAT rules to allow RDP access from the IT department IP range (203.0.113.0/24) to the web servers, and set outbound rules to allow internet access from the Frontend subnet while blocking outbound traffic from the Backend subnet. Option B is incorrect because the described NSG configuration includes a default deny outbound rule for the Frontend subnet, which would block the web servers' ability to download updates from the internet without an explicit allow rule.

Options A and C introduce unnecessary complexity and cost, and option C does not address the outbound internet requirement.

Exam trap

A common mistake is to assume that NSGs have a default deny outbound behavior, but they actually have a default allow outbound. The option B explicitly sets a 'default deny outbound', which would block internet access unless an explicit allow rule is added. Candidates may overlook the need for that allow rule.

Practice this question →

43

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

The UDR with default route pointing to the firewall's private IP ensures that all outbound internet traffic from the spoke VMs is forwarded to the firewall for inspection and logging.

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 →

44

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 →

45

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 →

46

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 →

47

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 →

48

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 →

49

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

NSGs filter traffic between subnets.

Why this answer

Network security groups (NSGs) provide stateful filtering of inbound and outbound traffic at the subnet or NIC level. By placing each tier in a separate subnet and applying distinct NSG rules, you can allow inbound HTTP/HTTPS traffic from the internet to the web tier subnet while blocking all inbound traffic from the internet to the application and database subnets. This ensures the application and database tiers are isolated from direct internet access while still allowing necessary traffic between tiers via internal IP addresses.

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 →

50

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 →

51

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 →

52

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 →

53

Multi-Selecthard

You need to monitor and log network traffic between Azure VMs for security analysis. Which THREE components should you enable?

Select 3 answers

A.Azure Monitor Logs (Log Analytics workspace)

B.Azure Firewall logs

C.NSG flow logs

D.Traffic Analytics

E.VNet flow logs

AnswersA, C, D

Flow logs are sent to Log Analytics for querying.

Why this answer

Azure Monitor Logs (Log Analytics workspace) is correct because it serves as the central ingestion and storage destination for network monitoring data. NSG flow logs capture IP traffic through Network Security Groups, and Traffic Analytics processes those raw flow logs to provide visualizations, top-talkers, and anomaly detection. Together, these three components enable comprehensive network traffic monitoring and security analysis for Azure VMs.

Exam trap

The trap here is that candidates confuse Azure Firewall logs (which only log traffic passing through the firewall) with NSG flow logs (which log all traffic allowed or denied by a Network Security Group), and mistakenly think 'VNet flow logs' is a real Azure feature when it does not exist.

Practice this question →

54

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 →

55

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 →

56

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 →

57

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 →

58

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 →

59

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 →

60

MCQhard

Your company uses Azure Front Door to globally distribute traffic to a web app. You need to ensure that only traffic from Front Door can reach the web app, and all other traffic is blocked. The web app is behind an Azure Application Gateway. What is the most secure and reliable configuration?

A.Place the web app behind a private endpoint and connect Front Door via private link.

B.Use an NSG on the Application Gateway subnet with a deny-all rule and allow the AzureFrontDoor.Backend service tag.

C.Configure an NSG on the Application Gateway subnet to allow traffic only from the Front Door backend IP ranges.

D.Restrict the Application Gateway to only accept traffic from the Front Door frontend IP.

AnswerC

Front Door publishes backend IP ranges that can be used in NSGs.

Why this answer

Azure Front Door uses a set of backend IP ranges that are documented and change over time. By configuring an NSG on the Application Gateway subnet to allow traffic only from these specific IP ranges, you ensure that only Front Door-originated traffic reaches the Application Gateway, while all other traffic is blocked. This approach is reliable because it uses network-layer filtering that the Application Gateway subnet enforces, and it avoids the complexity of private endpoints or service tags that may not apply to the Front Door-to-Application Gateway path.

Exam trap

The trap here is that candidates often confuse the Front Door frontend IP (used by clients to reach Front Door) with the backend IP ranges (used by Front Door to reach the origin), leading them to choose Option D, which is incorrect because the Application Gateway receives traffic from Front Door's backend IPs, not its frontend IPs.

How to eliminate wrong answers

Option A is wrong because placing the web app behind a private endpoint and connecting Front Door via private link is not directly applicable here; Front Door does not support private link connectivity to an Application Gateway backend, and the web app is behind the Application Gateway, not directly exposed. Option B is wrong because the AzureFrontDoor.Backend service tag is not valid for use in NSG rules on the Application Gateway subnet; Front Door does not expose a service tag for its backend IPs, and using a deny-all rule with an incorrect service tag would block all traffic, including legitimate Front Door traffic. Option D is wrong because restricting the Application Gateway to accept traffic only from the Front Door frontend IP is impractical and insecure; Front Door frontend IPs are public and can change, and this approach would require constant updates and does not account for the fact that Front Door routes traffic through its backend IPs, not its frontend IPs, to the Application Gateway.

Practice this question →

61

MCQeasy

A company has multiple on-premises web applications that need to be securely published for remote employees. The company uses Azure AD for identity management and wants to apply Conditional Access policies, including multi-factor authentication, to these applications. The security team wants to avoid exposing the on-premises infrastructure to the internet directly. Which Azure service should they deploy to meet these requirements?

A.Azure Application Gateway

B.Azure Front Door

C.Azure AD Application Proxy

D.Azure VPN Gateway

AnswerC

Azure AD Application Proxy is the correct choice because it publishes on-premises web applications externally without opening inbound firewall ports: a lightweight connector runs inside the on-premises network and makes outbound connections to Azure AD, so the app never needs a public inbound path. It performs Azure AD pre-authentication at the cloud layer before any request reaches the on-premises application, enabling integration with Conditional Access policies and MFA. It also supports single sign-on to web apps via Kerberos constrained delegation, making it the purpose-built service for securely exposing on-premises apps to remote users.

Why this answer

Azure AD Application Proxy is the correct service because it provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports. It integrates natively with Azure AD, enabling Conditional Access policies such as multi-factor authentication (MFA) to be applied to these applications. The service works by establishing an outbound-only connection from the on-premises Application Proxy connector to Azure AD, ensuring the on-premises infrastructure is never directly exposed to the internet.

Exam trap

The trap here is that candidates often confuse Azure AD Application Proxy with Azure Application Gateway or Azure Front Door, assuming any reverse proxy can secure on-premises apps, but only Application Proxy uses an outbound-only connector that keeps the internal network completely hidden from the internet.

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 typically requires the backend applications to be internet-facing or accessible via a public IP, which violates the requirement to avoid direct internet exposure. Option B is wrong because Azure Front Door is a global load balancer and content delivery network (CDN) that also requires the backend to be publicly reachable or connected via private link, but it does not provide the outbound-only connector model needed to keep on-premises infrastructure hidden. Option D is wrong because Azure VPN Gateway creates a site-to-site or point-to-site VPN tunnel, which exposes the on-premises network to the internet via the VPN endpoint and does not natively integrate with Azure AD Conditional Access or MFA for individual web applications.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Secure networking questions.

Start 20-question session