Troubleshooting and Performance Optimization Flashcards

A newly deployed Azure Firewall Premium is not decrypting TLS traffic for IDPS inspection. What must be configured?

Answer: Configure a TLS inspection policy with a CA certificate and associate it with the firewall policy

TLS inspection in Azure Firewall Premium requires a CA certificate (uploaded to Key Vault) configured in the firewall policy so the firewall can perform man-in-the-middle TLS decryption.

An on-premises network uses address space 10.0.0.0/8. An Azure VNet also uses 10.0.0.0/16. They are connected via ExpressRoute. Users report connectivity issues. What is the fundamental problem?

Answer: The overlapping address spaces cause routing ambiguity that cannot be resolved without NAT

Overlapping address spaces between on-premises and Azure VNets create routing ambiguity that requires NAT or re-IP to resolve since Azure VNet peering and ExpressRoute do not support overlapping prefixes.

Azure Traffic Manager is directing all users to one endpoint even though multiple healthy endpoints exist. The routing method is set to Performance. What is a likely cause?

Answer: Users are resolving the Traffic Manager DNS from a location where one endpoint has the lowest measured latency

Performance routing selects the endpoint with lowest latency from the user's DNS resolver location, so users from the same region will consistently be sent to the same closest endpoint.

After migrating a VM to a new subnet, the VM loses connectivity. The subnet has different NSGs and route tables. What is the fastest way to identify which rule is blocking traffic?

Answer: Use Network Watcher IP Flow Verify specifying the new source/destination to pinpoint the blocking rule

IP Flow Verify tests a specific traffic flow and returns exactly which NSG rule (name and action) is responsible for allowing or denying it.

You need to enforce that all outbound internet traffic from multiple spoke VNets passes through a centralized Azure Firewall in a hub VNet. What combination of configurations achieves this?

Answer: Create UDRs in each spoke with 0.0.0.0/0 pointing to the Azure Firewall private IP, and ensure spoke-to-hub peering allows forwarded traffic

UDRs with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP in each spoke, combined with peering settings that allow forwarded traffic, force all spoke internet traffic through the firewall.

A Connection Monitor test between two Azure VMs shows packet loss only during business hours. Azure Monitor metrics show no CPU or memory pressure on the VMs. What should you investigate next?

Answer: Whether the VMs' network bandwidth limit is being reached due to high business-hour traffic

Time-correlated packet loss without CPU/memory pressure on a VM typically indicates the VM's network bandwidth cap is being reached during peak usage periods.

An Azure Virtual WAN hub is deployed but branch sites connected via S2S VPN cannot reach spoke VNets. Routing intent is not configured. What default behavior explains this?

Answer: Virtual WAN hubs do not route between VPN and VNet connections without Routing Intent or custom route tables

Without Routing Intent or custom Virtual WAN route tables, the hub does not automatically route traffic between VPN branch connections and spoke VNet connections.