AZ-700 Practice Questions

The primary function of Azure Route Server is to simplify dynamic routing between your Network Virtual Appliances (NVAs) and your Azure virtual network. It establishes BGP peering with NVAs and injects their routes into the VNet's route table. This avoids the need for complex, manually configured User-Defined Routes (UDRs) to direct traffic to the NVA. It doesn't inspect or filter traffic itself; it only facilitates the exchange of routing information.

Azure Front Door Premium tier supports integrating with Private Link to secure the connection to the origin (backend). By enabling Private Link on the origin configuration in Front Door and approving the private endpoint connection on the App Service, traffic flows from Front Door to the App Service over the Azure private backbone network. This ensures the backend is not exposed to the public internet and all communication is private and secure.

Azure's route-based VPN gateways can connect to on-premises policy-based VPN devices by configuring a specific option on the connection. You must enable 'UsePolicyBasedTrafficSelectors' in a custom IPsec/IKE policy. This setting makes the Azure gateway behave like a policy-based gateway by using traffic selector prefixes to negotiate the IPsec tunnel, matching the behavior of the on-premises device. Azure no longer offers a dedicated 'policy-based' gateway SKU; instead, this compatibility is handled through connection settings.

Azure Virtual WAN is a managed networking service that brings together networking, security, and routing functionalities into a single operational interface. It is specifically designed to be the central hub in a global hub-spoke architecture, providing scalable, any-to-any connectivity for branches (S2S VPN), users (P2S VPN), and private connections (ExpressRoute). It simplifies large-scale network deployments compared to a manually configured hub VNet.

A single private DNS zone can be linked to multiple virtual networks. The administrator does not need to create a new zone. They can simply navigate to the existing 'corp.local' private DNS zone and add a new virtual network link pointing to VNet1. Once linked, VMs in VNet1 will be able to resolve records in that zone. It's important to note that a virtual network can only have one private DNS zone linked for automatic registration, but it can be linked to multiple zones for resolution purposes.

Standard SKU Load Balancers are 'secure by default' and do not provide automatic outbound NAT like the Basic SKU. To enable outbound internet access for backend pool members, you must explicitly define it. This can be done by either creating an outbound rule on the load balancer, which configures Source Network Address Translation (SNAT) using the load balancer's public IP, or by associating the subnet containing the VMs with a NAT Gateway.

Azure Virtual WAN is the ideal solution for this scenario. By creating a Virtual WAN and deploying hubs in both regions, Contoso can connect their ExpressRoute circuits directly to the hubs. The Virtual WAN's global transit architecture automatically enables full mesh connectivity, allowing spokes in Southeast Asia to communicate with spokes in West Europe over the Microsoft backbone (Requirement 1). Furthermore, because the Singapore ExpressRoute circuit is connected to the WAN, it gains transitive routing to the West Europe hub and its connected spokes, allowing the Singapore on-premises network to reach West Europe Azure resources privately and with low latency (Requirements 2 & 3). This managed service is inherently scalable and highly available (Requirement 4).

The correct method to force traffic between subnets through a Network Virtual Appliance (NVA) is called service chaining, which is implemented using User-Defined Routes (UDRs). By creating a route table and associating it with the source subnet (AppSubnet), you can define a custom route for traffic destined for the target subnet (DataSubnet). Setting the next hop type to 'VirtualAppliance' and specifying the NVA's private IP address ensures that all traffic matching the route is sent to the NVA for inspection first. NSGs control access but do not redirect traffic flow. VNet peering is for connecting separate VNets, not subnets within the same VNet.

Azure Firewall Manager is the correct service for this scenario. It provides a centralized security policy and route management for cloud-based security perimeters. It is specifically designed to manage Azure Firewall policies across multiple secured virtual hubs (in a Virtual WAN context) or hub virtual networks. This allows for consistent security policy enforcement globally. While Azure Policy can enforce deployment standards and Network Watcher provides monitoring, neither offers the centralized firewall rule management that Firewall Manager does.

The best practice for handling a false positive in WAF is to be as specific as possible to avoid weakening security. Creating a per-rule exclusion is the most precise method. By specifying the rule ID (942100) and limiting the exclusion to the specific request argument name (e.g., 'search_query'), you are telling the WAF to ignore this specific SQL injection check only for that parameter, while keeping the rule active for all other parts of the request. Disabling the rule entirely or switching to Detection mode would significantly increase the security risk. A custom allow rule for apostrophes is too broad and could be exploited.