Courseiva

CCNA Secure networking Questions

75 of 151 questions · Page 1/3 · Secure networking · Answers revealed

1
MCQeasy

You need to restrict access to an Azure Storage account so that only traffic from a specific virtual network is allowed. What should you configure?

A.Azure Firewall application rule
B.Storage account firewall and virtual network settings
C.Private endpoint connection
D.Network security group (NSG) on the subnet
AnswerB

The Storage account firewall and virtual network settings are the correct service-level control because they allow you to switch the storage account from 'All networks' to 'Selected networks,' then add a virtual network rule that permits traffic only from a specific virtual network (or subnet). This default-deny configuration explicitly blocks all other public IP ranges and network traffic that does not match an allow rule, thereby achieving the required restriction.

Why this answer

Azure Storage accounts have a built-in firewall that can be configured to restrict access based on source IP addresses or virtual network (VNet) rules. By enabling the storage account firewall and adding a rule that allows traffic only from a specific VNet/subnet, you effectively block all other traffic, including internet traffic, while permitting requests from the designated VNet. This is the native Azure method for network-level access control to storage accounts.

Exam trap

The trap here is that candidates often confuse the storage account firewall with network security groups (NSGs) or private endpoints, thinking that an NSG on a subnet can control access to a PaaS service like Storage, or that a private endpoint alone restricts access without also disabling public network access.

How to eliminate wrong answers

Option A is wrong because Azure Firewall application rules are used to allow or deny outbound HTTP/HTTPS traffic from a VNet to specific FQDNs, not to restrict inbound access to an Azure Storage account. Option C is wrong because a private endpoint connection assigns a private IP address to the storage account within a VNet, but it does not by itself restrict access; it must be combined with disabling public network access or configuring the storage account firewall to deny all public traffic. Option D is wrong because a Network Security Group (NSG) on a subnet can filter traffic to and from resources within that subnet, but it cannot directly restrict access to an Azure Storage account, which is a PaaS service with its own firewall; NSGs do not apply to the storage account's public endpoint.

2
MCQeasy

A company has several critical applications deployed in an Azure virtual network. The security team wants to protect the virtual network against Distributed Denial-of-Service (DDoS) attacks by enabling automatic attack mitigation, adaptive tuning, and access to DDoS Rapid Response Support. Which DDoS Protection tier should they enable for the virtual network?

A.DDoS Protection Basic (Free)
B.DDoS Protection Standard
C.DDoS Protection Premium
D.DDoS Protection Advanced
AnswerB

Standard is a paid tier that you enable on a virtual network, providing always-on monitoring, adaptive tuning to your application's traffic patterns, and mitigation of volumetric, protocol, and resource-layer attacks. It delivers real-time telemetry, rich diagnostic logs, and integration with Azure Monitor and Microsoft Defender for Cloud, plus access to DDoS Rapid Response Support for an additional cost. With SLA-backed protection and financial coverage during documented attacks, Standard is the correct tier for critical applications.

Why this answer

DDoS Protection Standard is the correct tier because it provides automatic attack mitigation, adaptive tuning based on traffic patterns, and access to DDoS Rapid Response Support (DRRS) for Azure virtual networks. The Basic tier only offers always-on traffic monitoring and basic mitigation without adaptive tuning or DRRS, while Premium and Advanced are not valid Azure DDoS Protection tiers.

Exam trap

The trap here is that candidates may confuse the non-existent 'Premium' or 'Advanced' tiers with the actual Standard tier, or assume the free Basic tier includes advanced features like adaptive tuning and DRRS, which are exclusive to the paid Standard tier.

How to eliminate wrong answers

Option A is wrong because DDoS Protection Basic is free but only provides always-on traffic monitoring and basic mitigation based on Azure's global network capacity; it does not include adaptive tuning or DDoS Rapid Response Support. Option C is wrong because DDoS Protection Premium is not a valid Azure DDoS Protection tier; Azure offers only Basic and Standard tiers. Option D is wrong because DDoS Protection Advanced is not a valid Azure DDoS Protection tier; the correct name for the paid tier is DDoS Protection Standard.

3
MCQeasy

You need to securely connect two Azure virtual networks in the same region to allow VM-to-VM communication using private IP addresses. The solution must minimize latency and administrative overhead. What should you use?

A.VNet peering
B.Azure VPN Gateway
C.Azure Front Door
D.ExpressRoute
AnswerA

VNet peering is the correct choice because it directly connects two virtual networks using Microsoft's private backbone, providing low-latency, high-bandwidth communication without traversing the public internet. It requires no gateway, VPN device, or extra transit, and involves simple, native configuration within Azure. Traffic remains entirely in the Microsoft network, making it both secure and cost-efficient for VNet-to-VNet connectivity.

Why this answer

VNet peering is the correct choice because it connects two Azure virtual networks in the same region using the Microsoft backbone infrastructure, enabling VM-to-VM communication over private IP addresses with near-zero latency and no intermediate hops. It requires no additional gateways or bandwidth charges within the same region, minimizing administrative overhead as it is a simple, one-time configuration.

Exam trap

The trap here is that candidates often confuse VNet peering with VPN Gateway, assuming a VPN is required for secure connectivity, but VNet peering inherently uses Microsoft's private network and provides the same security with lower latency and no gateway overhead.

How to eliminate wrong answers

Option B (Azure VPN Gateway) is wrong because it introduces a VPN tunnel over the public internet or ExpressRoute, adding latency and requiring gateway configuration and maintenance, which increases administrative overhead. Option C (Azure Front Door) is wrong because it is a global load balancer and application delivery service for HTTP/HTTPS traffic, not designed for private IP connectivity between VNets. Option D (ExpressRoute) is wrong because it is a dedicated private connection from on-premises to Azure, not for connecting two Azure VNets, and it incurs significant cost and provisioning complexity.

4
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 apply stateful allow/deny rules at the subnet and NIC level, so you can permit internet traffic to the web subnet while restricting the application and database subnets to accept traffic only from the web tier's address range, satisfying the tier isolation requirement.

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.

5
MCQeasy

You need to securely connect an on-premises network to an Azure virtual network. The connection must use the internet and provide authenticated and encrypted communication. Which Azure service should you use?

A.Azure VPN Gateway
B.Azure ExpressRoute
C.Azure Application Gateway
D.Azure Virtual WAN
AnswerA

Azure VPN Gateway is the correct service because it establishes a site-to-site IPsec/IKE VPN tunnel over the standard internet, providing encrypted connectivity between your on-premises VPN device and the Azure virtual network. It supports both policy-based and route-based gateways, and can be deployed in active-active mode for high availability, making it ideal for a secure, single-site connection without dedicated circuits.

Why this answer

Azure VPN Gateway is the correct choice because it creates an encrypted site-to-site VPN connection over the internet using IPsec/IKE protocols. This meets the requirement for authenticated and encrypted communication between an on-premises network and an Azure virtual network without needing a dedicated private link.

Exam trap

The trap here is that candidates often confuse Azure VPN Gateway with Azure ExpressRoute, thinking both provide encrypted connections, but ExpressRoute does not use the internet and encryption is optional (not default), while the question explicitly requires internet-based encrypted communication.

How to eliminate wrong answers

Option B (Azure ExpressRoute) is wrong because it provides a private, dedicated connection that bypasses the internet entirely, so it does not use the internet as specified. Option C (Azure Application Gateway) is wrong because it is a Layer 7 load balancer and web application firewall, not a network connectivity service for site-to-site VPNs. Option D (Azure Virtual WAN) is wrong because while it can include VPN gateways, it is a broader networking orchestration service; the question asks for a specific service to create the encrypted internet-based connection, and the core component is the VPN Gateway itself.

6
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.

7
MCQmedium

A company is deploying Azure Bastion to provide secure RDP/SSH access to VMs in a virtual network. The security requirement is that all administrative access must be logged and audited. What additional configuration is needed to meet this requirement?

A.Enable NSG flow logs on the subnet containing the target VMs.
B.Enable diagnostic settings on Azure Bastion to send logs to a Log Analytics workspace.
C.Enable Azure Activity Log for the Bastion resource.
D.Configure diagnostic settings on the target VMs to send logs to Log Analytics.
AnswerB

Enabling diagnostic settings on the Azure Bastion resource streams the resource-specific category, such as BastionAuditLogs, into a Log Analytics workspace. These logs contain each user connection's source IP, username, target VM, protocol, and session duration, directly satisfying the requirement to audit RDP/SSH sessions through Bastion.

Why this answer

The correct option is B: enabling diagnostic settings on Azure Bastion to send logs to a Log Analytics workspace. Azure Bastion emits session-level audit logs (such as BastionAuditLogs) that record who connected, to which VM, and when; routing these to Log Analytics makes them queryable and auditable, which directly satisfies the logging and auditing requirement. Option A does not fit because NSG flow logs capture network traffic metadata, not the administrative session identity or command context needed for Bastion access auditing.

Option C is insufficient because the Azure Activity Log records control-plane operations on the Bastion resource, not the RDP/SSH session activity. Option D is also wrong because diagnostic settings on the target VMs do not capture the Bastion-mediated administrative access events required here.

8
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.

9
MCQeasy

A company has an Azure virtual network with multiple subnets hosting different tiers of an application. The security team requires inspection of all traffic between subnets for malicious patterns and the ability to allow or deny traffic based on fully qualified domain names (FQDNs). Which Azure networking service should they implement?

A.Azure Network Security Group (NSG)
B.Azure Firewall
C.Azure Application Gateway
D.Azure VPN Gateway
AnswerB

Azure Firewall is a fully managed, stateful platform service that enforces centralized network and application rules, including FQDN-based Layer-7 filtering, TLS inspection, and threat-intelligence-based filtering. When deployed with user-defined routes (UDRs) and forced tunneling, it can inspect and control traffic flowing between subnets, providing a unified audit and management point. Its combination of network and application rules makes it the correct choice for this scenario.

Why this answer

Azure Firewall is a managed, cloud-based network security service that provides full Layer 3–7 inspection and can filter traffic based on FQDNs in network and application rules. It can inspect all traffic between subnets in a virtual network (via forced tunneling or routing) and supports threat intelligence-based filtering for malicious patterns, making it the correct choice for this requirement.

Exam trap

The trap here is that candidates often confuse NSGs with Azure Firewall, assuming NSGs can filter based on FQDNs or inspect traffic for malicious patterns, but NSGs lack Layer 7 inspection and FQDN support, which are exclusive to Azure Firewall in this context.

How to eliminate wrong answers

Option A is wrong because Network Security Groups (NSGs) operate at Layers 3 and 4 only, filtering based on source/destination IP, port, and protocol; they cannot inspect traffic for malicious patterns or filter based on FQDNs. Option C is wrong because Azure Application Gateway is a Layer 7 load balancer with a Web Application Firewall (WAF) that inspects HTTP/HTTPS traffic for web application attacks, but it does not provide general inter-subnet traffic inspection or FQDN-based filtering for non-web protocols. Option D is wrong because Azure VPN Gateway is used for encrypted site-to-site or point-to-site connectivity over the public internet; it does not perform traffic inspection or FQDN-based filtering between subnets within a virtual network.

10
MCQeasy

You need to block inbound traffic from the internet to a specific subnet except for TCP port 443. Which Azure service should you use?

A.Azure Web Application Firewall (WAF)
B.Azure Firewall
C.Network security group (NSG)
D.Azure DDoS Protection
AnswerC

A network security group is a stateful Layer 3/4 filtering component that binds directly to a subnet or network interface, allowing ordered allow and deny rules based on source/destination IP, port, and protocol. You can create a default deny rule for Internet inbound traffic and a higher-priority allow rule for the specific TCP/UDP port that must remain reachable, giving precise control over the subnet's attack surface. Because it is enforced at the subnet boundary and requires no per-application inspection overhead, this is the correct mechanism for blocking all Internet traffic except a single allowed port.

Why this answer

Network security groups (NSGs) are the correct choice because they provide stateful filtering of inbound and outbound traffic at the subnet or NIC level. By creating an inbound security rule that denies all traffic from the Internet (source 'Internet' service tag) and a higher-priority allow rule for TCP port 443, you can precisely block all inbound internet traffic except HTTPS. NSGs are the native Azure service for granular subnet-level access control lists (ACLs).

Exam trap

The trap here is that candidates often choose Azure Firewall (Option B) because it sounds like the most comprehensive security solution, but the question specifically asks for blocking inbound internet traffic to a subnet except for a single TCP port, which is a classic NSG use case—Azure Firewall is unnecessary and more expensive for this simple ACL requirement.

How to eliminate wrong answers

Option A is wrong because Azure Web Application Firewall (WAF) is designed to inspect HTTP/HTTPS traffic at the application layer (Layer 7) for web vulnerabilities (e.g., SQL injection, XSS) and does not provide general-purpose network-layer (Layer 3/4) traffic filtering to block all inbound internet traffic except a specific port. Option B is wrong because Azure Firewall is a managed, stateful firewall as a service that operates at the network and application layers, but it is overkill for a simple subnet-level ACL and incurs additional cost; NSGs are the native, cost-effective solution for this specific subnet filtering requirement. Option D is wrong because Azure DDoS Protection is a mitigation service that protects against volumetric distributed denial-of-service attacks at the network layer, not a tool for defining granular inbound traffic rules based on source, destination, and port.

11
MCQeasy

Refer to the exhibit. You have a VNet with two subnets, each with a different NSG. Both NSGs have default rules. What is the default connectivity between VMs in subnetA and subnetB?

A.Traffic is blocked by default.
B.Traffic is allowed only if the VNet has peering.
C.Traffic is allowed by default.
D.Traffic is allowed only if the subnets are in the same region.
AnswerC

This statement is correct. When an NSG is associated with a subnet or NIC, Azure automatically applies default security rules; the relevant default inbound rule, AllowVnetInBound, permits any traffic from the VirtualNetwork source and destination. This rule covers all subnets in the same VNet, so intra-VNet traffic is allowed by default. To block such traffic, you must add a custom deny rule with a higher priority than the default allow rule.

Why this answer

By default, Network Security Groups (NSGs) include an inbound rule named 'AllowVNetInBound' that permits traffic from any virtual network (including peered VNets) to any destination within the VNet. Since subnetA and subnetB are both part of the same VNet, this default rule allows all traffic between VMs in these subnets, regardless of the separate NSG assignments. No additional configuration like peering is required because the subnets share the same virtual network boundary.

Exam trap

The trap here is that candidates often assume separate NSGs on different subnets automatically block traffic between them, forgetting that the default 'AllowVNetInBound' rule overrides any implicit blocking and permits all intra-VNet communication unless explicitly denied.

How to eliminate wrong answers

Option A is wrong because the default NSG rules include an explicit 'AllowVNetInBound' rule that permits all traffic within the same VNet, so traffic is not blocked by default. Option B is wrong because VNet peering is only needed for connectivity between separate VNets, not between subnets within the same VNet; the default rules already allow intra-VNet traffic. Option D is wrong because Azure subnets within the same VNet can be in different regions (a VNet is regional), but the default NSG rules allow traffic regardless of region as long as the subnets belong to the same VNet.

12
MCQeasy

You are designing a secure network architecture for a three-tier application. The web tier must be accessible from the internet, while the application and database tiers must only be accessible from the web tier. Which Azure service should you use to isolate the tiers most securely?

A.Azure Firewall with application rules
B.Azure Front Door with Web Application Firewall
C.Network security groups (NSGs) on subnets
D.VNet peering between tiers
AnswerC

Network security groups on subnets are the correct control because they provide stateful filtering directly within the VNet using source/destination IP, port, and protocol. By associating an NSG to the web, app, and data subnets, you can enforce explicit allow rules for the necessary traffic (e.g., web to app on port 443) and add deny rules to block all other cross-tier traffic. This is the native, no-cost technique Azure provides for network segmentation, and it operates at both subnet and NIC levels for fine-grained control.

Why this answer

Network security groups (NSGs) on subnets are the correct choice because they provide stateful, layer-3/layer-4 traffic filtering at the subnet level, allowing you to explicitly deny all inbound traffic to the application and database subnets except from the web tier's subnet or private IP range. This creates a micro-segmentation boundary that enforces the principle of least privilege without introducing additional latency or routing complexity.

Exam trap

The trap here is that candidates often choose Azure Firewall or Front Door because they associate 'security' with those services, but the question specifically asks for isolating tiers within a VNet, which is a classic network segmentation task best solved by NSGs on subnets, not by perimeter or edge security appliances.

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, but it is designed for centralized policy enforcement across multiple VNets and outbound traffic control, not for isolating tiers within a single VNet; using it for tier isolation would introduce unnecessary cost and complexity. Option B is wrong because Azure Front Door with Web Application Firewall is a global load balancer and application-layer security service that protects web applications from common exploits, but it cannot restrict traffic between internal tiers (e.g., application to database) because it operates at the internet edge, not within the VNet. Option D is wrong because VNet peering connects entire VNets and allows full IP-level connectivity between them unless further restricted by NSGs or firewalls; peering alone does not provide any traffic filtering or isolation between tiers.

13
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.

14
MCQmedium

A company has an Azure virtual network with a subnet that hosts a web application. They want to allow inbound HTTPS traffic from any source on the internet (0.0.0.0/0) and block all other inbound traffic. They associate a network security group (NSG) with the subnet. What is the minimum number of inbound security rules required to achieve this?

A.One inbound rule allowing HTTPS from Internet, and one inbound rule DenyAllInbound.
B.One inbound rule allowing HTTPS from Internet.
C.Two inbound rules: one allowing HTTPS from Internet, one allowing HTTP from Internet.
D.Two inbound rules: one allowing HTTPS from Internet, one allowing RDP from Internet.
AnswerB

An NSG's default inbound security rules include a low-priority DenyAllInbound rule at priority 65500 that blocks any traffic not matched by a higher-priority allow rule. By creating one inbound allow rule for HTTPS (TCP 443) with a priority such as 100, legitimate HTTPS traffic to the web tier is permitted while all other inbound traffic is implicitly denied. Because the default deny rule is always evaluated last, this single rule fully satisfies the requirement and no other rules are necessary.

Why this answer

An NSG includes a set of default security rules that already block all inbound traffic not explicitly allowed. By adding a single inbound rule that allows HTTPS (TCP port 443) from the Internet (0.0.0.0/0), the default deny rule (DenyAllInbound) will block all other inbound traffic. Therefore, only one custom inbound rule is required to achieve the stated goal.

Exam trap

The trap here is that candidates often forget about the default NSG rules, especially the 'DenyAllInbound' rule, and incorrectly assume they must add an explicit deny rule to block all other traffic.

How to eliminate wrong answers

Option A is wrong because it suggests adding an explicit DenyAllInbound rule, which is redundant since the default NSG rule already denies all inbound traffic not explicitly permitted. Option C is wrong because it includes an unnecessary rule allowing HTTP (TCP port 80), which is not required and would violate the requirement to block all other inbound traffic. Option D is wrong because it includes an unnecessary rule allowing RDP (TCP port 3389), which is not required and would also violate the requirement to block all other inbound traffic.

15
MCQeasy

You need to secure traffic between two VNets in different Azure regions. The VNets contain virtual machines that must communicate over private IP addresses. Which Azure service should you use?

A.Azure Firewall
B.VNet peering
C.Azure VPN Gateway
D.ExpressRoute
AnswerB

VNet peering establishes a direct, low-latency connection between two virtual networks using Microsoft's backbone infrastructure, allowing private IP addresses to communicate across regions without going through the internet or a gateway. For the requirement to secure traffic between two VNets in different Azure regions, peering provides the connectivity layer, and security can then be applied via network security groups or a firewall. Peering is the correct answer because it is the native Azure mechanism for cross-region VNet-to-VNet private IP communication.

Why this answer

VNet peering enables direct, private IP connectivity between two VNets in different Azure regions (global VNet peering). Traffic flows over the Microsoft backbone network, not the public internet, ensuring low-latency and secure communication between virtual machines using private IP addresses without requiring a gateway or additional appliance.

Exam trap

The trap here is that candidates often confuse Azure VPN Gateway (which also connects VNets) with VNet peering, but VPN Gateway uses encrypted tunnels over the internet and incurs higher latency and throughput limitations, whereas VNet peering provides direct, private, high-bandwidth connectivity over the Microsoft backbone without a gateway.

How to eliminate wrong answers

Option A is wrong because Azure Firewall is a stateful, managed firewall service used to inspect and filter traffic at the network and application layers, not to connect VNets; it would be placed inline after connectivity is established, not as the connectivity mechanism itself. Option C is wrong because Azure VPN Gateway creates encrypted tunnels over the public internet, which introduces bandwidth limits (typically 1.25 Gbps per tunnel) and higher latency compared to VNet peering, and it is not the simplest or most performant solution for private IP communication between VNets. Option D is wrong because ExpressRoute provides dedicated private connectivity from on-premises networks to Azure, not between Azure VNets; while it can be used with VNet peering for hybrid scenarios, it is not the direct service for VNet-to-VNet private IP communication.

16
MCQhard

An Application Gateway WAF blocks legitimate requests because a managed rule detects a known false positive. The team wants to keep the rule set enabled. What should they configure?

A.A narrowly scoped WAF exclusion for the affected variable or rule
B.Disable WAF prevention mode for the entire gateway
C.Remove TLS from the listener
D.Move the application behind an internal load balancer only
AnswerA

A narrowly scoped WAF exclusion is the correct approach because it creates a targeted exception for a specific rule or rule set and specific request attribute (such as a header, cookie, or query string parameter) that is causing the false positive. This preserves deep inspection and blocking across all other traffic, ensuring the WAF still mitigates real attacks while allowing the legitimate request to pass. Microsoft's documentation recommends precisely this kind of exclusion to reduce false positives without weakening the overall security posture.

Why this answer

A narrowly scoped WAF exclusion is the correct approach because it allows the team to keep the managed rule set enabled while preventing false positives. By configuring an exclusion for the specific variable (e.g., RequestHeaderNames, RequestCookieNames, RequestArgNames) or rule ID that triggers the false positive, the WAF will skip inspection on that particular element without weakening the overall security posture. This maintains protection against other threats while resolving the blocking of legitimate traffic.

Exam trap

The trap here is that candidates may think disabling prevention mode or removing TLS is a quick fix, but the correct solution requires a precise, rule-level exclusion to maintain security while addressing the false positive.

How to eliminate wrong answers

Option B is wrong because disabling WAF prevention mode for the entire gateway would switch the WAF to detection mode only, which logs alerts but does not block any malicious traffic, thereby removing protection entirely instead of targeting the false positive. Option C is wrong because removing TLS from the listener would expose traffic in plaintext, breaking encryption requirements and not addressing the WAF rule false positive issue. Option D is wrong because moving the application behind an internal load balancer only would restrict access to internal networks, which does not resolve the WAF false positive and may not be suitable for internet-facing applications.

17
MCQmedium

A company has a hub-and-spoke network topology in Azure. The hub virtual network contains an Azure Firewall and a VPN gateway. Spoke virtual networks are peered to the hub. The security team wants to ensure that all outbound internet traffic from VMs in the spokes flows through the Azure Firewall. What should be configured?

A.Create a route table with a default route (0.0.0.0/0) to the Azure Firewall private IP and associate it with the spoke subnets.
B.Configure forced tunneling on the VPN gateway to route all traffic through the Azure Firewall.
C.Create a route table with a default route to the VPN gateway and associate it with the hub subnet.
D.Configure an NSG on the spoke subnets with a rule that sends traffic to the Azure Firewall.
AnswerA

In a hub-and-spoke topology, the correct way to force all outbound internet traffic from spoke VMs through an Azure Firewall is to create a route table with a 0.0.0.0/0 route whose next hop is set to the firewall's private IP address, then associate that route table with each spoke subnet. This UDR overrides the default system route for internet traffic, and because the spoke VNet is peered to the hub, packets can reach the firewall through the peering. Additionally, the firewall must be configured with its own allow rules and SNAT so replies return symmetrically to avoid asymmetric routing.

Why this answer

To force all outbound internet traffic from spoke VNets through the Azure Firewall, you must create a route table with a default route (0.0.0.0/0) that has the Azure Firewall's private IP as the next hop, and associate that route table with the subnets in the spoke VNets. This overrides the default system route and sends all internet-bound traffic to the firewall. Option B is wrong because forced tunneling on a VPN gateway is used to route on-premises traffic, not to direct spoke traffic through the firewall.

Option C is wrong because the route table should be associated with spoke subnets, not the hub subnet. Option D is wrong because NSGs do not support next-hop routing; they filter traffic, not direct it.

18
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

Azure VPN Gateway provides site-to-site connectivity over the public internet using IPsec/IKE encryption, terminating tunnels between on-premises VPN devices and the Azure virtual network gateway. This directly satisfies the encrypted, internet-based site-to-site IPsec requirement without dedicated private circuits.

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.

19
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.

20
MCQhard

You are troubleshooting connectivity between two Azure VMs in the same virtual network. VM1 can ping VM2, but VM1's application cannot connect to VM2's application on port 8080. Both VMs have NSGs that allow inbound traffic on port 8080. What is the most likely cause?

A.The VNet is peered with another VNet that has a conflicting address space.
B.An Azure Load Balancer is directing traffic away from VM2.
C.The NSG on VM2's subnet has a deny rule for port 8080.
D.The guest OS firewall on VM2 is blocking inbound port 8080.
AnswerD

The guest OS firewall on VM2 is a host-based firewall that filters traffic after the NSG has already permitted it and after the packet arrives at the virtual NIC. Even when network security groups explicitly allow port 8080, the OS firewall can still drop or reject the connection if there is no matching inbound allow rule or if an active deny rule is present. This is a common cause of 'connection refused' or timeout when all Azure network-level controls appear correct, making it the correct answer.

Why this answer

Since ICMP (ping) succeeds between the VMs, the network path is functional at Layer 3, and the NSGs are allowing traffic (as stated). The application failure on a specific port (8080) while ICMP works strongly indicates a host-level firewall blocking the TCP connection. The guest OS firewall (e.g., Windows Firewall or iptables) on VM2 is the most likely cause because it operates independently of Azure NSGs and can filter traffic by port and protocol, even when NSGs permit it.

Exam trap

The trap here is that candidates assume NSG rules are the only firewall layer in Azure, overlooking the guest OS firewall which operates independently and can block application traffic even when NSGs permit it.

How to eliminate wrong answers

Option A is wrong because VNet peering with a conflicting address space would cause routing issues for all traffic, not just a specific port; ping would also fail. Option B is wrong because an Azure Load Balancer only affects traffic destined for its frontend IP and load-balancing rules; it does not intercept direct VM-to-VM traffic within the same VNet unless explicitly configured with a backend pool and rule for that traffic. Option C is wrong because the question explicitly states that both VMs have NSGs allowing inbound traffic on port 8080; a subnet NSG deny rule would contradict that statement and would also block ICMP if it were a general deny, but ping works.

21
MCQeasy

You have an Azure virtual machine that hosts a custom web application. You need to restrict inbound internet traffic to only HTTPS (port 443) from any source. Which Azure resource should you configure?

A.Application Security Group (ASG)
B.Azure Bastion
C.Azure Firewall
D.Network Security Group (NSG)
AnswerD

A Network Security Group (NSG) is a stateful traffic-filtering resource that you can associate with a virtual machine's NIC or a virtual network subnet to allow or deny inbound and outbound traffic based on rules. To allow HTTPS from the Internet to your custom web app, you would add an inbound security rule with source set to 'Internet', destination set to the VM's IP (or its NIC/ASG), protocol set to TCP, and destination port set to 443. NSGs are the correct and simplest resource for this scenario because they enforce security rules directly at the network interface or subnet level, blocking any traffic that does not match an explicit allow rule. This is why NSG is the correct answer.

Why this answer

A Network Security Group (NSG) is the correct choice because it acts as a distributed, stateful firewall that filters inbound and outbound traffic at the subnet or network interface level. By creating an inbound security rule allowing TCP port 443 from any source (0.0.0.0/0) and denying all other inbound traffic, you can restrict internet traffic to HTTPS only. NSGs are the native Azure resource for controlling network traffic to VMs without additional cost or complexity.

Exam trap

The trap here is that candidates often confuse Azure Firewall with NSGs, thinking a full firewall is required for any traffic filtering, but for simple port-based restrictions on a single VM, an NSG is the correct and cost-effective choice.

How to eliminate wrong answers

Option A is wrong because an Application Security Group (ASG) is a logical grouping of VMs based on application roles, not a firewall; it is used in conjunction with NSG rules to define traffic flows between groups, but it cannot itself filter or restrict inbound internet traffic. Option B is wrong because Azure Bastion provides secure RDP/SSH connectivity to VMs over HTTPS, but it is not designed to filter general inbound web traffic; it only tunnels management protocols and does not block or allow arbitrary port 443 traffic from the internet. Option C is wrong because Azure Firewall is a managed, stateful firewall as a service that can filter traffic, but it is overkill for a single VM and incurs additional cost; an NSG is the simpler, more appropriate resource for this specific requirement.

22
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.

23
MCQmedium

A company has an Azure virtual network with a subnet that hosts a web application. They need to allow inbound HTTP (port 80) and HTTPS (port 443) traffic from a specific source IP range (203.0.113.0/24) to the web servers. Additionally, they need to allow inbound RDP (port 3389) traffic from a management subnet (10.0.1.0/24). They want to block all other inbound traffic. They are using a network security group (NSG) associated with the subnet. What is the minimum number of inbound security rules required?

A.3
B.4
C.5
D.2
AnswerA

You need exactly three inbound allow rules: one for HTTP (destination port 80), one for HTTPS (destination port 443), and one for RDP (destination port 3389), each scoped to the appropriate source address prefix. Azure NSGs include a default inbound deny rule, so any traffic not explicitly allowed by these three rules is automatically blocked. This satisfies the requirement with the minimum number of rules while preserving least privilege.

Why this answer

(3 rules) because an NSG includes default rules that already block all inbound traffic by default. You only need explicit allow rules for the three permitted traffic types: HTTP (port 80) from 203.0.113.0/24, HTTPS (port 443) from 203.0.113.0/24, and RDP (port 3389) from 10.0.1.0/24. The default deny rule handles blocking all other traffic, so no additional deny rule is required.

Exam trap

The trap here is that candidates often think they need an explicit deny rule to block all other traffic, forgetting that the default 'DenyAllInBound' rule already accomplishes this, leading them to overcount the required rules.

How to eliminate wrong answers

Option B (4) is wrong because it assumes a separate deny-all rule is needed, but the default deny rule already blocks all unmatched traffic. Option C (5) is wrong because it might incorrectly count separate rules for HTTP and HTTPS plus an explicit deny rule, or mistakenly include a rule for the management subnet's outbound traffic. Option D (2) is wrong because it would require combining HTTP and HTTPS into a single rule, but NSG rules cannot have multiple destination ports in a single rule unless using a port range, and port 80 and 443 are not contiguous; thus, two separate rules are needed for HTTP and HTTPS, plus one for RDP, totaling three.

24
MCQhard

You are a security engineer for Contoso. The company uses Azure Firewall for all inbound and outbound traffic. To prevent misconfiguration, you assign the Azure Policy shown in the exhibit at the management group scope. After assignment, a network administrator reports that they cannot create a new subnet in an existing virtual network. The subnet creation fails with a 'deny' policy error. You need to allow subnet creation while still blocking NSG rule changes. What should you do?

A.Change the effect to 'audit' instead of 'deny'.
B.Modify the policy rule to remove the subnet condition from the anyOf array.
C.Add an exemption for the virtual network resource group.
D.Remove the policy assignment and create a custom role to block subnet creation.
AnswerB

The `anyOf` array in an Azure Policy definition is evaluated as an OR, so if a subnet-specific condition (e.g., `Microsoft.Network/virtualNetworks/subnets`) is included alongside NSG rule conditions, the deny effect will incorrectly apply to subnet creation. Removing the subnet condition from that array narrows the policy scope to only NSG rule changes, preserving the deny behavior exactly where required while no longer blocking subnets. This is the only option that directly corrects the over-broad policy logic without losing the intended NSG rule enforcement.

Why this answer

The policy rule uses an `anyOf` array that includes conditions for both NSG rule changes and subnet creation. By removing the subnet condition from the `anyOf` array, the policy will no longer evaluate subnet creation against the deny effect, allowing subnets to be created while still blocking NSG rule modifications. This directly addresses the administrator's issue without weakening the security posture for NSG changes.

Exam trap

The trap here is that candidates may think adding an exemption (Option C) is the easiest fix, but they overlook that exemptions apply to the entire scope and would also exempt NSG rule changes, defeating the primary security requirement.

How to eliminate wrong answers

Option A is wrong because changing the effect to 'audit' would only log violations without blocking them, which fails to meet the requirement of blocking NSG rule changes. Option C is wrong because adding an exemption for the virtual network resource group would exempt all resources in that group from the policy, including NSG rule changes, thus bypassing the intended security control. Option D is wrong because removing the policy assignment and creating a custom role to block subnet creation would not prevent NSG rule changes, as custom roles do not enforce policy-based deny effects on resource modifications.

25
MCQmedium

You are a security engineer at Northwind Traders. The company has an Azure subscription with a virtual network named VNet1. You need to ensure that all outbound internet traffic from VNet1 is inspected by a central security appliance before leaving the network. You also need to log all traffic for auditing. The solution must minimize administrative effort and support scaling. What should you deploy?

A.Network security groups (NSGs) on each subnet with rules to allow only required outbound traffic, and enable NSG flow logs.
B.Azure Firewall in a hub virtual network, with user-defined routes (UDRs) in VNet1 pointing to the firewall's private IP address as the next hop for 0.0.0.0/0.
C.Azure VPN Gateway with forced tunneling configured to route all traffic through an on-premises firewall.
D.Azure Application Gateway with Web Application Firewall (WAF) and configure custom routing rules to send all outbound traffic to the gateway.
AnswerB

Azure Firewall is a managed, scalable cloud-native firewall that provides central inspection and logging. By creating a UDR in VNet1 that routes 0.0.0.0/0 to the firewall's private IP, all outbound internet traffic is forced through the firewall. This meets the inspection and logging needs with minimal management overhead and supports autoscaling.

Why this answer

Azure Firewall is a managed, cloud-native network security service that provides central inspection, logging, and scalability. By deploying it in a hub and using user-defined routes in VNet1 to direct all outbound traffic (0.0.0.0/0) to the firewall's private IP, you ensure every packet is inspected and logged. This design minimizes administrative effort because Azure manages the firewall infrastructure and scaling.

Exam trap

The trap here is assuming that network security groups alone can provide central inspection and logging of outbound traffic, when they are merely basic access control lists without payload inspection or centralized routing control.

26
Multi-Selecthard

Which THREE of the following are required to enable network traffic flow between two peered Azure virtual networks in different Azure regions?

Select 3 answers
A.Both VNets must have the Allow virtual network access setting enabled for the peering.
B.If using a network virtual appliance, the Allow forwarded traffic setting must be enabled.
C.Gateway transit must be enabled in at least one VNet.
D.An NSG rule must allow traffic between the VNets.
E.The address spaces of the VNets must not overlap.
AnswersA, B, E

The 'Allow virtual network access' setting is the master switch that permits the two virtual networks to communicate directly through peering. Both peering links must have it enabled; if one side disables it, traffic from that VNet will not be allowed to pass to the other. Without this setting, no other peering features (forwarded traffic or gateway transit) matter.

Why this answer

Option A is correct because each side of a VNet peering link has an 'Allow virtual network access' setting that must be enabled so the peered VNet's address space is reachable; if it is disabled, traffic to that VNet is blocked even though the peering exists. Option B is correct because when traffic is routed through a network virtual appliance in the peered VNet, the receiving peering must have 'Allow forwarded traffic' enabled, otherwise traffic not originating from the peered VNet's own address space is dropped. Option E is correct because VNet peering requires the address spaces of the two VNets to be non-overlapping; overlapping prefixes make routing ambiguous and the peering cannot be created.

Option C is not required: gateway transit only matters when sharing a VPN/ExpressRoute gateway, not for basic VNet-to-VNet traffic flow. Option D is not required: NSGs are optional security filters, and peering itself does not depend on an NSG rule allowing traffic.

Exam trap

The trap here is that candidates often confuse optional features like gateway transit or NSG rules as mandatory requirements for VNet peering, when in fact only the peering settings and non-overlapping address spaces are required for basic traffic flow.

27
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.

28
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

The direct VNet peering is the path letting SpokeA-to-SpokeB traffic bypass Azure Firewall entirely. Removing that peering forces traffic through the secured hub, where Azure Firewall inspects it. This is the prerequisite step before applying Azure Policy to block future direct peerings.

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.

29
Multi-Selecteasy

Which TWO of the following are supported ways to connect an on-premises network to Azure?

Select 2 answers
A.Azure Bastion
B.Azure ExpressRoute
C.Point-to-Site VPN
D.Site-to-Site VPN
E.Azure Front Door
AnswersB, D

Azure ExpressRoute is a dedicated, private network connection that extends an enterprise's on-premises infrastructure into Azure over a service provider's MPLS or similar reliable infrastructure, bypassing the public internet entirely. It uses BGP for dynamic routing and offers higher reliability, lower latency, and fixed bandwidth options, with regional redundancy. As a result, it is one of the two supported ways to connect an organization's network directly to Azure for hybrid deployments.

Why this answer

Azure ExpressRoute (B) is correct because it provides a private, dedicated connection between an on-premises network and Azure through a connectivity provider, bypassing the public internet. Site-to-Site VPN (D) is correct because it establishes an IPsec/IKE VPN tunnel over the public internet between an on-premises VPN device and an Azure VPN gateway, connecting entire networks. Azure Bastion (A) is not a network-to-network connection method; it provides secure RDP/SSH access to VMs through the Azure portal over TLS.

Point-to-Site VPN (C) connects an individual client computer to an Azure virtual network, not an on-premises network as a whole. Azure Front Door (E) is a global HTTP/HTTPS application delivery and load-balancing service, not a site-to-site connectivity solution.

Exam trap

The trap here is confusing Azure Bastion (a secure access service for VMs) with a network connectivity solution, or assuming Point-to-Site VPN can connect an entire on-premises network when it only supports individual client connections.

30
MCQeasy

A company has an Azure virtual network with a subnet that hosts a public web application. They want to allow inbound HTTPS traffic (port 443) only from the source IP range 203.0.113.0/24, and block all other inbound traffic. They associate a network security group (NSG) with the subnet. What is the minimum number of inbound security rules required in the NSG to achieve this?

A.0 (no additional rules needed because the default rules block all inbound traffic)
B.1
C.2 (one allow rule for HTTPS and one deny rule for all other traffic)
D.3 (one allow HTTPS, one allow for Azure Load Balancer health probes, and one deny all)
AnswerB

One carefully scoped inbound rule is sufficient: allow TCP 443 from the specific IP range to the subnet's destination port 443 at a priority like 100. Because NSG rules are evaluated in numeric priority order and DenyAllInBound (65500) is the final default rule, all other inbound traffic from the internet is automatically blocked without additional deny rules. This also avoids redundant rule overhead while preserving the default deny posture.

Why this answer

NSGs include default inbound rules that already block all inbound traffic not explicitly allowed. By adding a single inbound rule to allow HTTPS (port 443) from the source IP range 203.0.113.0/24, all other inbound traffic is implicitly denied by the default deny-all rule (rule 65000). No explicit deny rule is needed, and no additional rules for Azure Load Balancer health probes are required unless the application is behind a load balancer, which is not specified in the scenario.

Exam trap

The trap here is that candidates often think they need an explicit deny rule to block all other traffic, forgetting that NSGs have a built-in default deny-all rule that automatically handles this.

How to eliminate wrong answers

Option A is wrong because default rules do not block all inbound traffic; they allow traffic within the virtual network and from Azure load balancers, so additional rules are needed to restrict access to only the specified IP range. Option C is wrong because an explicit deny rule is unnecessary; the default deny-all rule (priority 65000) already blocks all traffic not matched by a higher-priority allow rule. Option D is wrong because Azure Load Balancer health probes are only relevant if a load balancer is used, and the scenario does not mention one; adding such a rule would be unnecessary and not the minimum.

31
MCQmedium

A company uses Azure Bastion to provide secure RDP and SSH access to Azure VMs without public IPs. Recently, a security audit recommended logging all connections to Bastion. What should you enable?

A.Azure Monitor alerts for Bastion resource health
B.Azure Activity Logs for the Bastion resource
C.Network Security Group flow logs on the subnet containing Bastion
D.Diagnostic settings on the Bastion resource to stream Bastion logs to a Log Analytics workspace
AnswerD

Diagnostic settings on the Bastion resource are the correct method to collect Azure Bastion's resource logs, specifically the BastionAuditLog, and stream them to a Log Analytics workspace. Once enabled, these logs capture RDP/SSH session events including the source IP address, the target VM, the username, the connection attempt result, and session duration. This data can then be queried with KQL to audit for compliance, investigate unauthorized access, and generate reports on Bastion usage—exactly the requirement in this scenario.

Why this answer

Azure Bastion does not support Network Security Group flow logs or Azure Activity Logs for capturing connection-level details like source IP, target VM, or session duration. Diagnostic settings on the Bastion resource must be enabled to stream Bastion logs (e.g., BastionAuditLogs) to a Log Analytics workspace, which records all RDP/SSH connection attempts and session metadata. This is the only way to meet the audit requirement for logging all connections to Bastion.

Exam trap

The trap here is that candidates assume NSG flow logs (Option C) capture all network traffic, but Azure Bastion operates at a higher layer and its connection logs are only available through diagnostic settings, not through traditional network-level logging.

How to eliminate wrong answers

Option A is wrong because Azure Monitor alerts for resource health only notify about service availability or degradation, not connection-level logging. Option B is wrong because Azure Activity Logs record control-plane operations (e.g., creating or deleting a Bastion resource), not data-plane connection events like RDP/SSH sessions. Option C is wrong because Network Security Group flow logs capture IP traffic through NSGs, but Azure Bastion bypasses NSGs on the subnet (it uses a dedicated, hardened service endpoint) and flow logs do not include Bastion-specific session details.

32
MCQmedium

A storage account should be reachable only from a specific subnet over the Microsoft backbone, while keeping the public endpoint firewall restricted. Which feature should be used?

A.Application Security Group
B.Azure Bastion
C.Service endpoint for Microsoft.Storage with storage firewall rules
D.Public IP prefix
AnswerC

A service endpoint for Microsoft.Storage extends the virtual network identity to the storage account, and when combined with storage firewall rules that deny all traffic except from the chosen subnet(s), it ensures the storage account is reachable only from that specific virtual network/subnet. This is the standard Azure mechanism for restricting PaaS storage to a private network segment, as the firewall rule blocks public internet and other sources while the service endpoint routes traffic from the subnet.

Why this answer

A service endpoint for Microsoft.Storage extends your virtual network private address space and the identity of your VNet to the Azure Storage service over the Microsoft backbone. By combining the service endpoint with a storage firewall rule that restricts access to only that specific subnet, you ensure the storage account is reachable only from that subnet while keeping the public endpoint firewall restricted to deny all other traffic.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, but the question explicitly requires keeping the public endpoint firewall restricted, which is exactly what service endpoints support by allowing selective subnet access through firewall rules without creating a private IP connection.

How to eliminate wrong answers

Option A is wrong because an Application Security Group is a logical grouping of VMs based on application workloads for network security group filtering, not a mechanism to restrict storage account access to a specific subnet. Option B is wrong because Azure Bastion provides secure RDP/SSH connectivity to VMs directly in the Azure portal over SSL, without exposing public IPs, but it does not control access to storage accounts. Option D is wrong because a Public IP prefix reserves a contiguous range of public IP addresses for your Azure resources, but it does not restrict storage account access to a specific subnet or enforce routing over the Microsoft backbone.

33
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.

34
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.

35
MCQmedium

Your organization has a hybrid network with an Azure VPN gateway connecting to an on-premises site. You need to ensure that traffic between Azure and on-premises is encrypted and authenticated. Which protocol should the VPN gateway use?

A.SSL/TLS
B.IPsec
C.SSH
D.HTTPS
AnswerB

IPsec is the standard protocol suite for site-to-site VPN tunnels, and Azure VPN Gateway explicitly uses IPsec/IKE to establish encrypted tunnels between on-premises networks and Azure virtual networks. IPsec operates at the network layer, providing confidentiality, data integrity, and anti-replay protection by encrypting and authenticating every IP packet in an ESP (Encapsulating Security Payload) header. This allows all traffic, not just specific applications, to be securely transmitted between sites, which is why it is the correct answer.

Why this answer

Azure VPN gateways use IPsec (Internet Protocol Security) to establish secure site-to-site tunnels between Azure and on-premises networks. IPsec provides both encryption (via protocols like AES) and authentication (via IKEv2 or IKEv1) for all traffic traversing the VPN tunnel, ensuring confidentiality and integrity. This is the required protocol for Azure VPN gateway connections as defined in Microsoft documentation.

Exam trap

The trap here is that candidates confuse SSL/TLS with IPsec because both provide encryption, but SSL/TLS is designed for client-server web security, not for routing all traffic between two entire networks via a VPN gateway.

How to eliminate wrong answers

Option A (SSL/TLS) is wrong because SSL/TLS is used for securing web traffic (HTTPS) and client-to-server connections, not for site-to-site VPN tunnels between networks. Option C (SSH) is wrong because SSH is a protocol for secure remote administration of devices (e.g., CLI access), not for encrypting bulk network traffic between sites. Option D (HTTPS) is wrong because HTTPS is an application-layer protocol for secure web browsing, not a tunneling protocol for network-to-network connectivity.

36
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.

37
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 user-defined route table on the spoke subnets, Azure's default system routes send internet-bound traffic directly out, bypassing the firewall despite peering. A 0.0.0.0/0 route with next hop Virtual appliance forces spoke egress through the hub 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.

38
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.

39
Multi-Selecteasy

You need to secure traffic between an on-premises network and Azure using a VPN connection. Which TWO configurations are required?

Select 2 answers
A.Create a virtual network gateway (VPN)
B.Deploy Azure Firewall
C.Assign a public IP to the local network gateway
D.Provision an ExpressRoute circuit
E.Create a local network gateway
AnswersA, E

The virtual network gateway is the Azure-side endpoint of a site-to-site VPN tunnel. It must be deployed in a dedicated GatewaySubnet and receives a public IP address to terminate the encrypted IPsec/IKE connection originating from the on-premises VPN device. Without this gateway, Azure has no component to establish the secure tunnel, so it is essential for securing traffic between the on-premises network and the virtual network.

Why this answer

Option A is correct because a virtual network gateway of type VPN is the Azure-side endpoint that terminates the IPsec/IKE tunnel and is mandatory for any site-to-site VPN connection. Option E is correct because the local network gateway is the Azure resource that represents the on-premises VPN device, holding its public IP address and address spaces so Azure knows how to route traffic to the remote network. Together, the virtual network gateway and local network gateway form the two required endpoints for a site-to-site VPN.

Option B is not required because Azure Firewall provides traffic filtering and security policies, not the VPN tunnel itself. Option C is not required because the public IP is assigned to the on-premises VPN device (or referenced in the local network gateway), not to the local network gateway resource itself. Option D is not required because ExpressRoute is a separate dedicated private connectivity service, not a VPN solution.

Exam trap

The trap here is that candidates often confuse the local network gateway (a configuration object) with needing a public IP assigned to it, or think Azure Firewall can serve as a VPN endpoint, when in fact it is a separate security service.

40
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.

41
Multi-Selecthard

Which TWO components are required to implement a secure hybrid network that connects on-premises to Azure using ExpressRoute? (Choose two.)

Select 2 answers
A.Virtual network gateway in Azure.
B.ExpressRoute circuit.
C.Azure Firewall.
D.Azure VPN Gateway for failover.
E.Azure Front Door.
AnswersA, B

A virtual network gateway in Azure is the required ExpressRoute gateway deployed in the gateway subnet of a virtual network. It terminates the ExpressRoute circuit at the Azure side and enables routing between on-premises networks and the VNet, with SKUs like ErGw1Az/ErGw2Az/ErGw3Az. Without this gateway, the circuit cannot be attached to a virtual network.

Why this answer

Option A is correct because an ExpressRoute connection terminates on a virtual network gateway of type 'ExpressRoute' (ExpressRouteGateway) deployed in the Azure virtual network's GatewaySubnet, which is the mandatory Azure-side endpoint that peers with the ExpressRoute circuit. Option B is correct because the ExpressRoute circuit is the connectivity resource provisioned through a connectivity provider (or ExpressRoute Direct) that establishes the private Layer 3 connection between on-premises and Microsoft's edge, and it is the fundamental component required for any ExpressRoute-based hybrid network. Option C is not required for the connectivity itself; Azure Firewall is an optional security service for traffic inspection and does not establish the ExpressRoute link.

Option D is not required because a VPN Gateway is only an optional failover path (or a separate S2S VPN design), not a mandatory component of an ExpressRoute implementation. Option E is not required because Azure Front Door is a global Layer 7 HTTP/HTTPS load balancer and CDN service, unrelated to private ExpressRoute hybrid connectivity.

Exam trap

A common trap is assuming the Azure VPN Gateway is a required component for ExpressRoute. In fact, it is only used for failover and is not mandatory. The required components are the ExpressRoute circuit and the virtual network gateway.

42
MCQhard

Your company uses Azure Firewall Premium with TLS inspection to filter outbound traffic from Azure VMs. Users report that some websites are not loading. You have configured the firewall to inspect traffic to *.microsoft.com. What is the most likely cause of the issue?

A.The firewall rule for *.microsoft.com is misconfigured.
B.The firewall cannot inspect HTTPS traffic.
C.The firewall is blocking HTTP traffic.
D.The client does not trust the certificate presented by the firewall during TLS inspection.
AnswerD

During TLS inspection, Azure Firewall Premium acts as a proxy: it establishes the TLS connection from the client and presents a certificate issued by your organization's private CA (or custom root). Every client that sends HTTPS through this inspection path must trust that CA certificate in its local certificate store; otherwise the browser or application aborts the handshake with a certificate authority invalid / unknown issuer error. Because the rule configuration and the firewall's inspection capability are both valid, the missing trust anchor on the client is the only remaining explanation.

Why this answer

Azure Firewall Premium with TLS inspection acts as a man-in-the-middle (MITM) proxy. It decrypts outbound HTTPS traffic, inspects it, then re-encrypts it using a certificate signed by an internal CA. If the client VM does not trust the firewall's internal CA certificate (e.g., it is not installed in the Trusted Root Certification Authorities store), the browser will reject the connection, causing websites to fail to load even though the firewall rule is correctly configured.

Exam trap

The trap here is that candidates assume the firewall rule is misconfigured or that HTTPS inspection is impossible, when in fact the core issue is client-side certificate trust, not firewall policy or protocol capability.

How to eliminate wrong answers

Option A is wrong because the firewall rule for *.microsoft.com is explicitly configured and working; the issue is not a misconfiguration of the rule itself but a certificate trust problem. Option B is wrong because Azure Firewall Premium is specifically designed to inspect HTTPS traffic via TLS termination and re-encryption, so it can inspect HTTPS. Option C is wrong because the firewall is not blocking HTTP traffic; the problem is with HTTPS inspection, and HTTP traffic would not be affected by TLS inspection at all.

43
MCQhard

You are a security engineer at Adventure Works. The company has an Azure Kubernetes Service (AKS) cluster that uses the Azure CNI network plugin. The cluster's pods must access an Azure SQL Database securely without traversing the public internet. You need to configure private connectivity from the AKS cluster to the Azure SQL server. What should you implement?

A.Deploy an Azure Firewall in the AKS virtual network and configure DNAT rules to forward SQL traffic to the Azure SQL server's public endpoint.
B.Enable Azure Private Link service on the AKS cluster and create a private endpoint for the SQL server in the AKS subnet.
C.Configure a service endpoint for Microsoft.Sql on the AKS subnet and restrict the Azure SQL server firewall to that subnet.
D.Create an Azure Private Endpoint for the Azure SQL server in a subnet within the AKS virtual network, and configure private DNS integration.
AnswerD

Azure Private Endpoint creates a private IP address for the Azure SQL server inside your virtual network. With private DNS integration, the SQL server's fully qualified domain name resolves to that private IP, so traffic from AKS pods stays on the Microsoft backbone and never goes over the public internet. This meets the secure private connectivity requirement.

Why this answer

Azure Private Endpoint creates a network interface with a private IP address from your virtual network subnet for the Azure SQL server. Combined with private DNS zone integration, the SQL server's name resolves to that private IP, ensuring all traffic from AKS pods remains on the Microsoft backbone. This provides secure, private connectivity without exposing traffic to the public internet.

Exam trap

The trap here is confusing service endpoints with private endpoints; service endpoints secure traffic to the public endpoint of a PaaS service, while private endpoints assign a private IP address within your virtual network for truly private connectivity.

44
MCQeasy

You need to provide secure remote access to Azure virtual machines for developers without exposing public IP addresses. The solution must authenticate users via Microsoft Entra ID and support multifactor authentication. Which service should you use?

A.Azure Front Door
B.Azure VPN Gateway
C.Azure Bastion
D.Azure Firewall
AnswerC

Azure Bastion is a fully managed, agentless PaaS service that provides secure, seamless RDP and SSH connectivity to Azure VMs directly through the Azure portal over TLS. It is deployed in a dedicated subnet (AzureBastionSubnet) and lets users connect to VMs without any public IP, NSG rule allowing inbound RDP/SSH, or additional client software. Bastion integrates with Microsoft Entra ID authentication, MFA, and RBAC, making it the ideal answer for secure browser-based remote access to Azure VMs.

Why this answer

Azure Bastion provides secure RDP/SSH connectivity to Azure virtual machines directly from the Azure portal over TLS, without exposing public IP addresses. It integrates with Microsoft Entra ID for authentication and supports multifactor authentication (MFA) when combined with Conditional Access policies, meeting all requirements.

Exam trap

The trap here is that candidates often confuse Azure Bastion with Azure VPN Gateway, assuming a VPN is required for secure remote access, but Bastion is the correct choice when the goal is to avoid public IPs and integrate directly with Microsoft Entra ID for authentication and MFA.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is a global load balancer and application delivery service for HTTP/HTTPS traffic, not a tool for RDP/SSH access to VMs. Option B is wrong because Azure VPN Gateway creates an encrypted tunnel from on-premises or remote clients to an Azure virtual network, but it requires a public IP address on the gateway and does not natively authenticate via Microsoft Entra ID or enforce MFA without additional components. Option D is wrong because Azure Firewall is a managed network security service that filters traffic based on rules, not a remote access solution for VMs.

45
Multi-Selectmedium

You are designing network security for a three-tier application. You need to isolate each tier (web, application, data) and control traffic between them. Which TWO Azure services should you use to achieve this? (Choose two.)

Select 2 answers
A.Network Security Groups (NSGs)
B.VNet peering
C.Azure Policy
D.Azure Firewall
E.Application Security Groups (ASGs)
AnswersA, E

Network Security Groups (NSGs) serve as the core stateful filtering mechanism inside Azure VNets, with rules evaluated by priority to permit or deny traffic based on the 5-tuple (source, destination, port, protocol, direction). Applying NSGs to subnets or VM NICs allows you to segment a three-tier application by isolating the web, business, and data tiers from each other. They are the native, default choice for tier isolation because they require no extra cost and offer granular control over east-west traffic.

Why this answer

Network Security Groups (NSGs) are correct because they let you define inbound and outbound security rules (by IP, port, and protocol) that filter traffic to and from subnets or NICs, which is exactly how you enforce isolation and control traffic between the web, application, and data tiers. Application Security Groups (ASGs) are correct because they let you group VMs by workload role (for example, web, app, or data) and then reference those groups as sources/destinations in NSG rules, so you can control tier-to-tier traffic without hardcoding individual IP addresses. Together, NSGs provide the filtering mechanism and ASGs provide the logical grouping that makes tier-based rules scalable and maintainable.

VNet peering only connects virtual networks for private IP communication and does not itself filter or isolate tier traffic. Azure Policy is a governance/compliance tool for enforcing resource configurations, not a runtime traffic filter. Azure Firewall is a centralized, stateful network security service, but it is not the service used to isolate individual tiers within a VNet via subnet/NIC-level rules and workload grouping.

Exam trap

The trap here is that candidates often choose Azure Firewall for all traffic control scenarios, overlooking that NSGs and ASGs are the native, lightweight solution for east-west traffic isolation within a single VNet, while Azure Firewall is designed for centralized, cross-VNet, and outbound traffic inspection.

46
Multi-Selecthard

You are designing a secure network architecture for a multi-region application. You need to ensure that traffic between virtual networks in different Azure regions is encrypted and uses the Microsoft backbone network, and you must minimize latency. Which TWO configurations should you implement?

Select 1 answer
A.Enable 'Gateway transit' on the peering to use a VPN gateway if needed, but not required for encryption.
B.Configure VNet peering between the virtual networks.
C.Use Azure ExpressRoute with Microsoft peering.
D.Deploy Azure VPN Gateway in each region and connect them via site-to-site VPN.
E.Place an Azure Firewall in each region to inspect cross-region traffic.
AnswersB

VNet peering connects VNets using the Microsoft backbone and can be enabled globally.

Why this answer

Option B (Configure VNet peering between the virtual networks) is correct because Azure VNet peering routes traffic directly over the Microsoft backbone network, keeping it off the public internet and providing the lowest-latency path between VNets in different regions (global VNet peering). Option C is incorrect because ExpressRoute with Microsoft peering is used to reach Microsoft public services such as Microsoft 365 and Azure PaaS, not to connect virtual networks to each other, and ExpressRoute does not encrypt traffic by default. Option A is not required because gateway transit only lets a peered VNet share a VPN/ExpressRoute gateway; it does not itself provide encryption for VNet-to-VNet traffic.

Option D is not the best choice because site-to-site VPN traffic traverses the public internet and typically adds latency compared with backbone-based peering. Option E is incorrect because Azure Firewall inspects and filters traffic but does not encrypt cross-region traffic or optimize latency.

Exam trap

Candidates often assume that a VPN gateway or ExpressRoute is required for encrypted cross-region VNet traffic, but VNet peering already routes traffic over the Microsoft backbone. Note that ExpressRoute with Microsoft peering is for Microsoft public services, not VNet-to-VNet connectivity, and does not provide encryption by default.

47
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.

48
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 or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

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

49
MCQhard

Refer to the exhibit. You have an Azure Application Gateway WAF policy with the above JSON configuration. A user from IP address 10.1.2.3 reports they cannot access the web application. What is the most likely cause?

A.The WAF policy is in prevention mode and detected a SQL injection.
B.The WAF policy is set to detection mode and logs the request.
C.The custom rule is disabled due to a syntax error.
D.The custom rule blocks all private IP addresses.
AnswerD

The custom rule explicitly defines a match condition on the client's source IP and uses action "Block" to deny traffic from RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). Because the request's source IP falls inside 10.0.0.0/8, the custom rule matches and enforces the block immediately. In Application Gateway WAF, custom rules are evaluated before managed rule sets, so this request is denied without ever being inspected for SQL injection or other managed signatures.

Why this answer

The custom rule in the WAF policy explicitly blocks all traffic from IP addresses in the 10.0.0.0/8 private range. Since the user's IP address (10.1.2.3) falls within this range, the rule matches and blocks the request. The WAF policy is in prevention mode, so the rule actively blocks the request rather than just logging it.

Exam trap

The trap here is that candidates may overlook the custom rule's IP range and assume the issue is related to SQL injection or detection mode, when in fact the problem is a simple IP-based block rule targeting private addresses.

How to eliminate wrong answers

Option A is wrong because the JSON configuration shows no SQL injection detection rules are configured; the only rule is a custom IP-based block rule. Option B is wrong because the WAF policy is set to 'Prevention' mode (as shown in the JSON), not 'Detection' mode, so it actively blocks requests rather than just logging them. Option C is wrong because the custom rule is syntactically valid (it has proper JSON structure, a valid priority, condition, and action), and there is no indication of a syntax error.

50
Multi-Selecteasy

Which TWO are valid connection methods for Azure VPN Gateway? (Choose two.)

Select 2 answers
A.Point-to-Site
B.VNet-to-VNet
C.Site-to-Site
D.Azure Bastion
E.ExpressRoute
AnswersA, C

Azure VPN Gateway's Point-to-Site method allows individual client computers to establish a secure connection to a VNet from any location, using SSTP, IKEv2, or OpenVPN protocols. Each client authenticates via certificates or Azure AD, and traffic is wrapped in IPsec for IKEv2/OpenVPN or SSL/TLS for SSTP. It is one of the two primary VPN connection methods, distinct from Site-to-Site because it does not require a public-facing VPN device on the customer side.

Why this answer

Point-to-Site (P2S) is a valid connection method for Azure VPN Gateway because it allows individual client computers to connect securely to an Azure virtual network from anywhere using the SSTP, IKEv2, or OpenVPN protocols. This method is ideal for remote workers who need encrypted access without requiring a site-level VPN device.

Exam trap

The trap here is that candidates often confuse VNet-to-VNet as a distinct connection method when it is actually a specific use case of Site-to-Site, and they may also mistakenly think Azure Bastion or ExpressRoute are VPN gateway connection types when they are separate Azure services with different purposes.

51
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.

52
MCQeasy

Your organization needs to securely connect an on-premises data center to Azure for disaster recovery. The connection must be encrypted and use the public internet. Which Azure service should you use?

A.Azure Front Door.
B.Azure ExpressRoute with private peering.
C.Azure VPN Gateway.
D.Azure DNS.
AnswerC

Azure VPN Gateway is correct because it implements a site-to-site IPsec/IKE VPN tunnel over the public internet between an on-premises VPN device and an Azure virtual network gateway. The tunnel encrypts traffic using industry-standard protocols such as IKEv2 and ESP, and the gateway supports active-active configurations and BGP for dynamic routing. This is the Azure service explicitly designed for secure internet-based hybrid connectivity.

Why this answer

Azure VPN Gateway is the correct choice because it provides encrypted site-to-site IPsec/IKE VPN tunnels over the public internet, enabling secure connectivity between an on-premises data center and Azure for disaster recovery. This meets the requirement for encryption and use of the public internet, as VPN Gateway leverages standard protocols like IKEv2 and IPsec to protect data in transit.

Exam trap

The trap here is that candidates often confuse Azure ExpressRoute with VPN Gateway, assuming ExpressRoute can be used over the public internet, but ExpressRoute always uses a private, dedicated connection that does not traverse the internet, making it unsuitable when the requirement explicitly states 'use the public internet'.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is a global load balancer and application delivery controller that operates at Layer 7 (HTTP/HTTPS), not a site-to-site VPN solution; it does not provide encrypted tunnels between on-premises networks and Azure over the public internet. Option B is wrong because Azure ExpressRoute with private peering provides a private, dedicated connection that bypasses the public internet entirely, which contradicts the requirement to use the public internet. Option D is wrong because Azure DNS is a domain name resolution service that translates domain names to IP addresses and has no capability to create encrypted network connections between on-premises and Azure.

53
MCQeasy

A company deploys Azure Firewall to inspect and control outbound traffic from a virtual network. The security team wants to allow outbound HTTPS traffic only to specific FQDNs such as *.microsoft.com and *.windowsupdate.com, while blocking all other outbound internet access. Which type of rule should they configure in Azure Firewall to achieve this filtering?

A.Network Rule
B.Application Rule
C.NAT Rule
D.DNAT Rule
AnswerB

Application rules in Azure Firewall are purpose-built for outbound and east-west traffic filtering based on FQDNs, supporting wildcard patterns such as *.microsoft.com to match any subdomain. They work by inspecting the Host header of HTTP sessions or the SNI/TLS extension of encrypted connections, and with DNS proxy enabled they resolve FQDNs to current IPs before forwarding. This allows the firewall to enforce a precise allowlist of target domains, making it the correct rule type for this requirement.

Why this answer

Azure Firewall uses Application Rules to filter outbound traffic based on fully qualified domain names (FQDNs) for HTTP/HTTPS protocols. Since the requirement is to allow HTTPS traffic to specific FQDNs like *.microsoft.com and *.windowsupdate.com, an Application Rule is the correct choice because it can inspect the TLS Server Name Indication (SNI) extension to match the target FQDN, enabling granular allow/deny decisions for web traffic.

Exam trap

The trap here is that candidates often confuse Network Rules with Application Rules, mistakenly thinking that port 443 and IP addresses can achieve FQDN-based filtering, but Network Rules lack the ability to inspect the application layer (FQDN) and can only filter by IP/port, which is insufficient for domain-specific allowlisting.

How to eliminate wrong answers

Option A is wrong because Network Rules filter traffic based on source/destination IP addresses, ports, and protocols (TCP/UDP), not FQDNs, so they cannot selectively allow HTTPS to specific domain names. Option C is wrong because NAT Rules (Destination Network Address Translation) are used to translate inbound traffic to internal resources, not to filter outbound traffic. Option D is wrong because DNAT Rules are synonymous with NAT Rules in Azure Firewall and serve the same inbound translation purpose, not outbound FQDN filtering.

54
MCQhard

You are a security engineer for Adventure Works. The company has an Azure subscription with a virtual network named VNet1 that contains a subnet named Subnet1. Subnet1 hosts an Azure App Service Environment (ASE) and several Azure virtual machines. You need to inspect all traffic between Subnet1 and the internet for malicious content and generate alerts for suspicious activity. You also need to ensure that the solution can decrypt and inspect HTTPS traffic. What should you do?

A.Configure Azure Application Gateway with Web Application Firewall (WAF) in VNet1. Create a user-defined route to direct traffic from Subnet1 to the Application Gateway.
B.Configure Azure Firewall in VNet1. Create application rules to allow outbound traffic and enable threat intelligence in alert mode. Configure the VMs and ASE to use Azure Firewall as the default gateway.
C.Deploy a network virtual appliance (NVA) from Azure Marketplace that supports TLS inspection. Configure a user-defined route to direct traffic from Subnet1 to the NVA.
D.Deploy Azure Firewall Premium in VNet1. Enable TLS inspection and configure the firewall to use a certificate stored in Azure Key Vault. Create a user-defined route to direct traffic from Subnet1 to the firewall's private IP address.
AnswerD

Azure Firewall Premium supports TLS inspection, which allows it to decrypt, inspect, and re-encrypt HTTPS traffic. It requires a certificate stored in Azure Key Vault. To ensure all traffic from Subnet1 is inspected, you must create a user-defined route that directs traffic to the firewall's private IP address as the next hop. This solution meets the requirements for deep inspection and alerting on suspicious activity.

Why this answer

To inspect all traffic between Subnet1 and the internet, including HTTPS, deploy Azure Firewall Premium and enable TLS inspection. This allows the firewall to decrypt and inspect encrypted traffic. You must also configure a user-defined route to force traffic from Subnet1 through the firewall's private IP address.

This ensures all outbound traffic is inspected and alerts can be generated for suspicious activity.

Exam trap

The trap here is assuming that Azure Firewall Standard or threat intelligence alone can decrypt HTTPS traffic; TLS inspection is a Premium feature that requires a certificate and explicit configuration.

55
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 or tap steps into the slots.

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.

56
MCQmedium

You are a security engineer at Adatum. The company has an Azure subscription with a virtual network named VNet1 that contains an Azure Firewall in a subnet named AzureFirewallSubnet. You need to ensure that all outbound traffic from a subnet named AppSubnet is inspected by the firewall, including traffic to other subnets in VNet1 and to the internet. What should you configure?

A.Create a user-defined route (UDR) on AppSubnet with a default route (0.0.0.0/0) that has a next hop type of Virtual appliance and points to the private IP address of the Azure Firewall.
B.Enable Azure Firewall forced tunneling by configuring a UDR with a next hop type of Virtual network gateway on AppSubnet.
C.Associate a network security group (NSG) with AppSubnet that denies all outbound traffic except to the firewall's private IP address.
D.Configure Azure Firewall to use DNS proxy and set the DNS servers on AppSubnet to the firewall's private IP address.
AnswerA

Azure Firewall inspects traffic only if it is routed through the firewall. A UDR on AppSubnet with a default route pointing to the firewall's private IP as a virtual appliance ensures all outbound traffic, including intra-VNet and internet-bound, is sent to the firewall for inspection.

Why this answer

Azure Firewall inspects traffic only when it is in the data path. A user-defined route on AppSubnet with a default route using next hop Virtual appliance and the firewall's private IP ensures all outbound traffic, including to other subnets and the internet, is sent to the firewall. Without this UDR, traffic would bypass the firewall.

Exam trap

The trap here is assuming that associating a network security group or enabling DNS proxy will automatically route traffic through Azure Firewall, when only a user-defined route can change the next hop.

57
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.

58
MCQhard

A company wants to deploy an Azure VPN Gateway in active-active mode to ensure high availability for their site-to-site VPN connection. They have two on-premises VPN devices, each with a distinct public IP address. What is the minimum configuration required for the Azure VPN Gateway to utilize both on-premises devices?

A.Create two local network gateways, each with one on-premises public IP, and connect each to a different IP of the VPN gateway.
B.Create one local network gateway that includes both on-premises IP addresses and enable BGP on the connection.
C.Use active-passive mode and configure a second VPN gateway in the same virtual network.
D.Deploy two separate VPN gateways in different Azure regions.
AnswerA

In active-active mode, the Azure VPN gateway is deployed with two public IP addresses, and the correct configuration requires two separate on-premises VPN devices, each represented by its own local network gateway. By creating a local network gateway for each on-premises public IP and connecting each one to a different gateway IP address via separate connections, you establish two independent IPsec tunnels that operate concurrently. This satisfies high availability because failure of one on-premises device or one Azure gateway instance still leaves a functional tunnel. Without this placement — one local network gateway per on-premises IP — the gateway cannot build active-active tunnels to two distinct on-premises endpoints.

Why this answer

Active-active mode requires two distinct IP addresses on the Azure VPN gateway, and each on-premises VPN device must be represented by its own local network gateway. By creating two local network gateways (one per on-premises public IP) and connecting each to a different Azure VPN gateway IP, you establish two independent IPsec tunnels, achieving high availability. This configuration ensures that if one on-premises device or one Azure instance fails, traffic can still flow through the other tunnel.

Exam trap

The trap here is that candidates often think a single local network gateway can hold multiple on-premises IPs or that BGP alone can handle dual tunnels, but Azure requires a separate local network gateway per on-premises device to establish distinct IPsec SAs in active-active mode.

How to eliminate wrong answers

Option B is wrong because a single local network gateway can only define one on-premises public IP address; including both IPs in one gateway is not supported, and enabling BGP does not solve the need for separate tunnels to each on-premises device. Option C is wrong because active-passive mode uses only one active tunnel at a time, so it cannot utilize both on-premises devices simultaneously; deploying a second VPN gateway in the same VNet is not a valid configuration (only one gateway per VNet is allowed). Option D is wrong because deploying two VPN gateways in different Azure regions creates a multi-region disaster recovery setup, not an active-active site-to-site VPN within a single region, and it does not leverage both on-premises devices for the same connection.

59
MCQeasy

You need to allow a specific IP address (203.0.113.5) to access an Azure Storage account over the internet. All other internet traffic must be denied. You have enabled the storage account firewall. What should you configure?

A.Create a private endpoint for the storage account.
B.Add the IP address to the firewall rules of the storage account.
C.Configure an NSG on the subnet to allow the IP address.
D.Add a service endpoint for Microsoft.Storage to the subnet.
AnswerB

The storage account firewall supports IP-based network rules, allowing you to explicitly list 203.0.113.5/32 as an allowed client IP. All other public traffic is denied by default, making this the only option that directly addresses access from a specific public IP address. You can add the IP rule either on the storage account's Networking blade or programmatically via the REST API, and existing connections remain unaffected.

Why this answer

The Azure Storage account firewall allows you to configure IP-based access control rules. By adding the specific IP address 203.0.113.5 to the firewall rules, you explicitly permit traffic from that IP while denying all other internet traffic, as the default rule is to deny when the firewall is enabled.

Exam trap

The trap here is confusing network-level controls (NSGs, service endpoints, private endpoints) with the storage account's built-in IP firewall, which is the only mechanism that can whitelist a specific internet IP address when the storage account firewall is enabled.

How to eliminate wrong answers

Option A is wrong because a private endpoint uses a private IP address from your virtual network to access the storage account over Microsoft's backbone network, not over the internet, and it does not allow a specific internet IP address. Option C is wrong because NSGs operate at the subnet or NIC level within a virtual network and cannot control access to an Azure Storage account over the internet; they only filter traffic within the VNet. Option D is wrong because a service endpoint extends your VNet identity to the storage account, allowing traffic from the subnet without a public IP, but it does not provide a mechanism to allow a specific internet IP address; it still relies on the storage account firewall rules for IP-based access.

60
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

Azure Firewall is a stateful, managed network security service that inspects and filters inbound internet traffic at the virtual network boundary, satisfying the requirement to control traffic entering the VNet from the internet using FQDN and threat intelligence rules.

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.

61
MCQmedium

A company has two application tiers: web servers and application servers. They want to allow traffic from the web servers to the application servers on port 8080, but only for a specific set of web servers. They have deployed the web servers in an Availability Set and want to use a single NSG rule to allow traffic from any web server that is part of that application tier. Which component should they use?

A.Application security group
B.Service tag
C.Source IP address range
D.Virtual network peering
AnswerA

An application security group (ASG) is the correct choice because it lets you group VM network interfaces by workload role, such as all web servers, and reference that group directly as the source in a network security group (NSG) rule. As VMs are added or removed from the tier, the ASG membership updates automatically, so the NSG rule dynamically reflects the current set of web server IP addresses without requiring manual edits. ASGs provide a scalable, intent-based way to enforce microsegmentation and zero-trust network access across VMs.

Why this answer

An Application Security Group (ASG) allows you to group virtual machines logically by their application roles (e.g., web servers) and then use that ASG as the source in a single NSG rule. Since the web servers are in an Availability Set, you can assign the same ASG to their NICs, and the NSG rule will dynamically include all current and future VMs in that ASG. This meets the requirement to allow traffic from any web server in that tier to the application servers on port 8080 without maintaining individual IP addresses.

Exam trap

The trap here is that candidates often confuse Application Security Groups with Network Security Groups themselves, or mistakenly think Service Tags can be used to group custom sets of VMs, when in fact Service Tags are only for Azure services or broad network scopes.

How to eliminate wrong answers

Option B is wrong because a Service Tag (e.g., 'VirtualNetwork') represents a predefined group of IP addresses from Azure services or the entire virtual network, not a custom set of specific VMs like the web servers in an Availability Set. Option C is wrong because using a Source IP address range would require you to list the individual private IPs of each web server, which is not dynamic and would break the requirement to use a single rule for any web server in the tier. Option D is wrong because Virtual Network Peering connects two virtual networks at the network layer, but it does not provide granular control to filter traffic from a specific subset of VMs within a peered network; it simply enables connectivity between the entire VNets.

62
Multi-Selectmedium

You are a security engineer at Litware. The company has an Azure virtual network named VNet1 with a subnet named Subnet1 that hosts several virtual machines. You need to restrict outbound internet access from Subnet1 to only allow traffic to specific FQDNs, such as *.microsoft.com and *.azure.com, while blocking all other outbound internet traffic. You also need to log allowed and denied traffic. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Create a user-defined route (UDR) in Subnet1 that directs all outbound traffic (0.0.0.0/0) to the Azure Firewall's private IP address as the next hop.
B.Enable Azure DDoS Protection Standard on VNet1 to filter outbound traffic based on domain names.
C.Configure a network security group (NSG) on Subnet1 with outbound rules that allow traffic to the FQDNs and deny all other outbound traffic.
D.Deploy an Azure Application Gateway with WAF and configure custom rules to allow the FQDNs for outbound traffic.
E.Deploy Azure Firewall and configure application rules to allow the specified FQDNs, then set a default deny for all other outbound traffic.
AnswersA, E

A user-defined route with address prefix 0.0.0.0/0 and next hop type Virtual appliance, pointing to the Azure Firewall's private IP, forces all outbound traffic from Subnet1 through the firewall. Without this route, traffic would bypass the firewall and go directly to the internet, so it is essential to enforce inspection.

Why this answer

To restrict outbound internet access to specific FQDNs and log traffic, you need Azure Firewall with application rules that allow the desired FQDNs and deny everything else. You also need a user-defined route in Subnet1 that sends all outbound traffic (0.0.0.0/0) to the firewall's private IP. This combination ensures traffic is forced through the firewall and filtered by FQDN, with logging of allowed and denied flows.

Exam trap

The trap here is assuming that network security groups can filter by FQDN or that simply deploying Azure Firewall without a user-defined route will automatically redirect traffic through it.

63
Multi-Selecthard

You are a security engineer for Fabrikam. The company has an Azure virtual network named VNet1 that contains a subnet named Subnet1 with several VMs. You need to ensure that all traffic from Subnet1 to the internet is inspected by Azure Firewall, and that the VMs can resolve external DNS names using Azure-provided DNS. The firewall is deployed in a subnet named AzureFirewallSubnet. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Create a service endpoint for Microsoft.Storage on Subnet1 to allow VMs to resolve external DNS names.
B.Deploy an Azure Bastion host in VNet1 and configure the VMs to use it as a DNS forwarder.
C.Associate a network security group with Subnet1 that allows outbound traffic only to the Azure Firewall's private IP address.
D.Configure the Azure Firewall to use DNS proxy, and set the DNS servers on Subnet1 to the private IP address of the Azure Firewall.
E.Create a user-defined route on Subnet1 with address prefix 0.0.0.0/0 and next hop type Virtual appliance, pointing to the private IP address of the Azure Firewall.
AnswersD, E

Enabling DNS proxy on Azure Firewall allows the firewall to resolve external names on behalf of clients. Setting Subnet1's DNS servers to the firewall's private IP ensures that DNS queries from the VMs are sent to the firewall, which then forwards them to Azure-provided DNS, satisfying the name resolution requirement.

Why this answer

To inspect all internet-bound traffic from Subnet1 with Azure Firewall, a user-defined route must direct that traffic to the firewall's private IP. To allow VMs to resolve external names, enable DNS proxy on the firewall and point Subnet1's DNS settings to the firewall's private IP. Together, these actions meet both requirements.

Exam trap

The trap here is assuming that a network security group or service endpoint can redirect traffic to Azure Firewall or provide DNS resolution, when only a user-defined route and DNS proxy configuration achieve those goals.

64
Multi-Selecthard

Which THREE are best practices for securing network traffic in Azure? (Choose three.)

Select 3 answers
A.Use private endpoints for Azure services
B.Assign public IP addresses to every VM
C.Allow direct outbound internet access from VMs
D.Implement just-in-time (JIT) VM access
E.Use service tags in NSG rules
AnswersA, D, E

Azure Private Endpoints use a network interface with a private IP from your VNet to connect to PaaS services (e.g., Storage, SQL DB), so traffic flows entirely over the Microsoft backbone and never reaches the public internet. This eliminates data exposure to the internet and enables secure connections from on-premises via ExpressRoute or VPN, while also helping prevent data exfiltration by keeping service communication inside your virtual network.

Why this answer

Option A is correct because private endpoints assign a private IP address from your VNet to an Azure PaaS service via Azure Private Link, keeping traffic on the Microsoft backbone and eliminating exposure to the public internet. Option D is correct because just-in-time (JIT) VM access in Microsoft Defender for Cloud opens NSG rules only on demand for a limited time and from approved source IPs, reducing the attack surface of management ports like RDP 3389 and SSH 22. Option E is correct because service tags in NSG rules let you allow or deny traffic to specific Azure services (for example, Storage or Sql) by Microsoft-managed IP ranges, avoiding broad 0.0.0.0/0 or Internet rules and simplifying maintenance.

Option B is not a best practice because assigning public IP addresses to every VM directly exposes them to internet scanning and brute-force attacks; VMs should generally be reached via Bastion, VPN, or private endpoints. Option C is not a best practice because allowing direct outbound internet access from VMs bypasses inspection and enables data exfiltration and command-and-control traffic; outbound traffic should be routed through Azure Firewall, NAT Gateway, or a user-defined route to a controlled egress point.

Exam trap

The trap here is that candidates often confuse 'just-in-time VM access' (which controls RDP/SSH access) with network traffic security, but it is indeed a best practice for reducing the attack surface of management ports, so it is correct; the real distractors are the obviously insecure options B and C that test your understanding of exposure minimization.

65
MCQmedium

You are designing network security for a hybrid application that uses Azure Front Door and Azure Application Gateway. The application must block malicious requests at the edge before they reach the backend. You need to implement Web Application Firewall (WAF) protection with the lowest latency and the ability to inspect traffic at the application layer. Which solution should you use?

A.Enable Azure DDoS Protection on the virtual network.
B.Apply WAF policy on Azure Application Gateway only.
C.Apply WAF policy on Azure Front Door.
D.Use Azure Firewall with threat intelligence-based filtering.
AnswerC

Applying a WAF policy on Azure Front Door is the correct choice because Front Door operates at the global edge, inspecting all incoming HTTP/S requests in the closest PoP to the client, which minimizes latency and blocks malicious traffic before it travels to the origin or Application Gateway. Front Door's WAF supports managed rule sets (e.g., OWASP Core Rule Set), custom rules, geo-filtering, rate limiting, and bot protection, allowing comprehensive application-layer defense at the edge. This design keeps the hybrid application's internal network and gateway isolated from attack traffic, reducing the risk of resource exhaustion and ensuring only legitimate requests are forwarded.

Why this answer

Azure Front Door's WAF operates at the edge of the Microsoft global network, inspecting HTTP/HTTPS traffic at the application layer (Layer 7) with minimal latency due to its distributed point-of-presence (PoP) architecture. This allows malicious requests to be blocked before they traverse the backbone to the origin, meeting the requirement for edge protection and low latency.

Exam trap

The trap here is that candidates often confuse Azure Application Gateway's WAF (which is regional and higher latency) with Azure Front Door's WAF (which is global and edge-based), leading them to choose Option B because they assume all WAF policies are equivalent, ignoring the latency and edge placement requirements.

How to eliminate wrong answers

Option A is wrong because Azure DDoS Protection operates at the network layer (Layer 3/4) and does not inspect application-layer traffic or provide WAF capabilities to block malicious HTTP requests. Option B is wrong because applying WAF on Azure Application Gateway only protects traffic after it reaches the regional gateway, not at the edge, which introduces higher latency and does not block malicious requests before they enter the Azure backbone. Option D is wrong because Azure Firewall with threat intelligence-based filtering operates at the network and transport layers (Layer 3/4) and does not perform deep application-layer inspection or WAF rule matching for HTTP/HTTPS payloads.

66
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.

67
Multi-Selectmedium

Which TWO actions should you take to secure a virtual network in Azure? (Choose two.)

Select 2 answers
A.Apply network security groups (NSGs) to subnets.
B.Configure Azure DNS zones.
C.Deploy Azure Bastion for VM access.
D.Implement Azure Firewall for perimeter control.
E.Set up Azure Monitor alerts.
AnswersA, D

Network security groups (NSGs) are a core, stateful filtering layer in Azure that enforce allow/deny rules based on source/destination IP, port, and protocol. When applied to subnets, they segment traffic between workloads inside a VNet and control traffic entering or leaving the subnet from the internet or peered networks. NSGs also provide default rules and support service tags, making them a fundamental security action for any VNet.

Why this answer

Network security groups (NSGs) are a fundamental Azure security control that filter traffic at the subnet or network interface level. Applying an NSG to a subnet allows you to define inbound and outbound security rules based on source/destination IP, port, and protocol, effectively segmenting and protecting the virtual network from unauthorized access.

Exam trap

The trap here is that candidates often confuse Azure Bastion (a PaaS management service) with a network security control, or think Azure Monitor alerts can actively block traffic, when in fact neither provides traffic filtering or perimeter security.

68
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.

69
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.

70
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.

71
MCQmedium

Your company uses Azure Firewall Premium. You need to inspect outbound traffic for malware using signature-based detection. Which feature should you enable?

A.Web categories
B.URL filtering
C.Threat intelligence-based filtering
D.Intrusion Detection and Prevention System (IDPS)
AnswerD

Intrusion Detection and Prevention System (IDPS) in Azure Firewall Premium provides deep packet inspection using a signature-based detection engine. It compares traffic patterns against a large database of known malware and exploit signatures and can alert or block malicious packets in real time. This feature directly inspects packet payloads for signature matches, making it the correct option for inspecting traffic for malware signatures.

Why this answer

Intrusion Detection and Prevention System (IDPS) on Azure Firewall Premium uses signature-based detection to inspect outbound traffic for known malware patterns. It can alert or block traffic matching malicious signatures, making it the correct feature for this requirement.

Exam trap

The trap here is that candidates often confuse Threat intelligence-based filtering (which uses IP/domain reputation) with signature-based malware detection, but IDPS is the only feature that inspects packet payloads for known malware signatures.

How to eliminate wrong answers

Option A is wrong because Web categories classify traffic by content type (e.g., social media, gambling) but do not perform signature-based malware inspection. Option B is wrong because URL filtering allows or denies traffic based on specific URLs or FQDNs, not by inspecting packet payloads for malware signatures. Option C is wrong because Threat intelligence-based filtering uses known malicious IPs, domains, and URLs from Microsoft feeds, not signature-based detection of malware patterns in traffic.

72
MCQeasy

You are analyzing network traffic patterns. You have configured NSG flow logs with Traffic Analytics as shown in the exhibit. You need to identify which virtual machines are communicating with a specific malicious IP address. Which tool should you use to query the flow log data?

A.Azure Storage Explorer
B.Log Analytics workspace using KQL queries
C.Azure Monitor Metrics Explorer
D.Network Watcher Topology
AnswerB

Network Watcher Traffic Analytics enriches NSG flow logs and sends them to a Log Analytics workspace, where you can use KQL to investigate traffic. For example, you can query the AzureNetworkAnalytics_CL table, filter by DestinationIP, group by FlowDirection_s, and summarize total bytes or flow counts to identify traffic to a specific IP. KQL supports time-series analysis, joins, and aggregations, making it the correct and efficient tool for this task.

Why this answer

NSG flow logs with Traffic Analytics are stored in a Log Analytics workspace. To query the flow log data and identify which virtual machines are communicating with a specific malicious IP address, you must use Log Analytics with Kusto Query Language (KQL). KQL allows you to filter, aggregate, and join flow log records based on source/destination IP addresses, ports, and protocols, enabling precise identification of affected VMs.

Exam trap

The trap here is that candidates may confuse NSG flow logs with metrics or topology tools, but only Log Analytics with KQL can perform the ad-hoc, IP-specific queries required to identify malicious communications from the raw flow data.

How to eliminate wrong answers

Option A is wrong because Azure Storage Explorer is a GUI tool for browsing and managing Azure Storage accounts (blobs, files, queues, tables), but it cannot run KQL queries against flow log data stored in a Log Analytics workspace. Option C is wrong because Azure Monitor Metrics Explorer is designed for querying and visualizing numeric time-series metrics (e.g., CPU, network throughput), not for analyzing detailed flow log records with IP addresses and connection states. Option D is wrong because Network Watcher Topology provides a visual representation of the network infrastructure and relationships between resources, but it does not support querying historical flow log data or filtering by specific IP addresses.

73
MCQmedium

Your company deploys a web application in an Azure App Service that needs to securely connect to an Azure SQL Database. You want to avoid exposing the database to the public internet. What is the recommended approach?

A.Configure the SQL database firewall to allow only the App Service outbound IP
B.Use Azure Firewall to block outbound traffic to the database
C.Create an NSG on the database subnet to deny internet traffic
D.Use a private endpoint for the SQL database and VNet integration for the App Service
AnswerD

Using a private endpoint for the SQL database combined with VNet integration for the App Service is the correct approach because it removes the database's public endpoint entirely. The private endpoint assigns the SQL database a private IP address inside your VNet, and VNet Integration routes the App Service's traffic through that VNet, ensuring all communication stays within the Microsoft backbone and never traverses the public internet. After enabling the private endpoint, you can set the SQL server's public network access to 'Disabled', which fully blocks any internet-based access and leaves only the private connection. This provides a secure, stable, and compliant network path for the app-to-database traffic.

Why this answer

It uses Azure Private Endpoint to place the Azure SQL Database on a virtual network, removing its public endpoint, and combines it with VNet integration for the App Service to route traffic through the same VNet. This ensures the database is never exposed to the public internet, meeting the security requirement without relying on IP-based firewall rules that can change or be spoofed.

Exam trap

The trap here is that candidates often assume IP-based firewall rules (Option A) are sufficient for security, but Azure explicitly recommends private endpoints for PaaS services to avoid reliance on dynamic public IPs and to achieve true network isolation.

How to eliminate wrong answers

Option A is wrong because allowing only the App Service outbound IP is unreliable—App Service outbound IPs can change without notice (e.g., during scaling or region failover) and still expose the database to the internet via that IP, which is not truly private. Option B is wrong because Azure Firewall blocks outbound traffic from the App Service to the database, which would prevent the connection entirely rather than securing it. Option C is wrong because an NSG on the database subnet cannot deny internet traffic to the database if the database has a public endpoint; NSGs filter traffic at the subnet level but do not remove the public exposure of the database's FQDN.

74
MCQmedium

You are configuring a site-to-site VPN connection between your on-premises network and Azure. You need to ensure that traffic between the networks is encrypted and authenticated. Which Azure service should you use?

A.Azure Virtual WAN
B.Azure ExpressRoute
C.Azure Firewall
D.Azure VPN Gateway
AnswerD

Azure VPN Gateway is the specific Azure service designed to create site-to-site (S2S) VPN connections by terminating IPsec/IKE tunnels between on-premises networks and Azure virtual networks. It supports multiple configurations, including active-active instances, BGP routing, and both policy-based and route-based VPN devices, making it the exact fit for the scenario. This is the correct choice because it directly provides the encrypted, secure tunnel required for a site-to-site VPN.

Why this answer

Azure VPN Gateway is the correct service because it provides encrypted and authenticated site-to-site VPN connections using IPsec/IKE protocols. It establishes a secure tunnel between your on-premises VPN device and the Azure VPN gateway, ensuring confidentiality and integrity of traffic across the public internet.

Exam trap

The trap here is that candidates often confuse Azure Virtual WAN (which includes VPN gateway capabilities) with the specific service required, or they assume ExpressRoute provides encryption by default, when in fact it does not encrypt traffic unless additional measures are taken.

How to eliminate wrong answers

Option A is wrong because Azure Virtual WAN is a networking service that aggregates multiple VPN, ExpressRoute, and SD-WAN connections into a unified hub, but it is not the specific service that directly provides the encrypted site-to-site VPN tunnel; it relies on VPN Gateway instances within its hubs. Option B is wrong because Azure ExpressRoute provides a private, dedicated connection to Azure that bypasses the public internet, but it does not natively encrypt traffic; encryption must be added separately (e.g., over ExpressRoute with MACsec or IPsec), and it is not a VPN service. Option C is wrong because Azure Firewall is a managed, cloud-based network security service that filters and inspects traffic, but it does not terminate VPN tunnels or provide site-to-site VPN connectivity; it can be used in conjunction with a VPN gateway for inspection but is not the VPN service itself.

75
MCQeasy

You need to provide secure remote access to Azure virtual machines for administrators without exposing them to the public internet. The solution must use a single entry point and support Azure Active Directory (now Microsoft Entra ID) authentication. Which Azure service should you use?

A.Azure Bastion.
B.Just-in-time (JIT) VM access with Microsoft Defender for Cloud.
C.Azure Front Door with private endpoints.
D.Azure VPN Gateway with point-to-site VPN.
AnswerA

Azure Bastion is a fully managed PaaS service deployed inside the VNet that brokers RDP and SSH sessions over TLS to the Azure portal, so VMs never need a public IP address or inbound internet-facing NSG rules. It authenticates with Entra ID (Azure AD) and can require MFA or Conditional Access before brokering the session, and it connects directly to the VM's private IP over the Bastion subnet. This is the only option here that gives administrators portal-based, client-less remote access while completely removing VMs from internet exposure.

Why this answer

Azure Bastion provides secure, seamless RDP/SSH connectivity to Azure VMs directly from the Azure portal over TLS, without exposing public IP addresses. It uses a single entry point (the Bastion host) and supports Azure AD authentication for login, meeting both requirements.

Exam trap

The trap here is that candidates often confuse Just-in-time VM access (which reduces exposure but still requires public IPs) with a true zero-public-IP solution, or they assume a VPN gateway provides a single entry point when it actually creates multiple client-specific tunnels.

How to eliminate wrong answers

Option B is wrong because Just-in-time (JIT) VM access reduces exposure by opening ports only when needed but still requires the VM to have a public IP address and does not provide a single entry point or native Azure AD authentication for the connection. Option C is wrong because Azure Front Door is a global load balancer and application delivery service, not designed for direct VM remote access; it operates at the HTTP/HTTPS layer and cannot proxy RDP/SSH traffic. Option D is wrong because Azure VPN Gateway with point-to-site VPN creates a tunnel into the virtual network but requires clients to install a VPN client and does not provide a single entry point for all administrators; it also does not natively support Azure AD authentication for the VPN connection itself.

Page 1 of 3 · 151 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Secure networking questions.