AZ-500 Secure networking: 105 practice questions

12 of the 105 Secure networking questions in the Certsqill AZ-500 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-500? Take the free 5-min readiness check →

1. The request is allowed because rule Priority 100 matches: What happens?

1. The request is allowed because rule Priority 100 matches first and allows TCP 443 from the 10.0.0.0/8 range, which includes 10.1.2.3 ✓

   NSG rules are evaluated in ascending priority order (lowest number = highest priority). Priority 100 matches 10.1.2.3 (which is in 10.0.0.0/8) on port 443 and allows the traffic. Once a rule matches, evaluation stops — Priority 200 is never reached.
2. The request is denied because the Priority 65500 default deny-all rule applies to any packet not matched earlier in the set.

   The default deny at 65500 is evaluated last; Priority 100 matches 10.1.2.3 and allows the traffic before that default rule is ever reached.
3. The traffic is allowed by Priority 100, then re-evaluated against Priority 200 on the response path, where the deny rule drops the reply.

   NSGs are stateful, so return traffic for an allowed inbound flow is permitted automatically without re-evaluating the rules on the response path.
4. The request is denied because Priority 200 explicitly denies TCP 443 from Any, and higher-numbered deny rules override the lower-numbered allow.

   Rules are evaluated in ascending priority order, so Priority 100 is processed first, matches the source, allows the traffic, and evaluation stops before 200.

NSG rules evaluate in ascending priority order. Priority 100 matches 10.1.2.3 on port 443 and allows it — evaluation stops there.

2. Deploy Azure Firewall Premium: Which Azure Firewall configuration is required?

1. Deploy Azure Firewall Basic with application rules for the HTTPS endpoints and enable threat intelligence in Alert mode to block the C2 traffic patterns.

   Azure Firewall Basic is a cost-optimized SKU without IDPS or TLS inspection, and Alert mode does not block; it cannot inspect encrypted payloads or stop C2.
2. Deploy Azure Firewall Premium, enable TLS inspection with a CA certificate stored in Key Vault, and configure the IDPS policy in Alert and Deny mode ✓

   Azure Firewall Premium is the only SKU that supports TLS inspection (decrypts HTTPS to inspect payload) and IDPS (Intrusion Detection and Prevention System). TLS inspection requires a CA certificate in Key Vault to sign re-encrypted traffic. IDPS in Alert and Deny mode blocks matching signatures including C2 patterns.
3. Deploy Azure Firewall Premium and enable DNS proxy, which decrypts the HTTPS sessions and applies the IDPS malware signatures to the payloads.

   DNS proxy routes DNS queries for FQDN filtering and does not decrypt HTTPS; TLS inspection is a separate feature requiring an explicit CA certificate.
4. Deploy Azure Firewall Standard, enable threat intelligence-based filtering, and configure FQDN rules to inspect the encrypted payload and block the C2 domains.

   Azure Firewall Standard supports threat intelligence filtering but not TLS inspection or IDPS, so it cannot inspect encrypted payload or detect behavioral C2 patterns.

Azure Firewall Premium with TLS inspection and IDPS in Alert and Deny mode is required for encrypted traffic inspection and C2 pattern blocking.

3. Azure DDoS IP Protection: Which DDoS protection option should they choose?

1. Azure DDoS Network Protection — enable it on the whole VNet to protect every public IP inside, the cheapest way to cover just a single public IP.

   Network Protection is billed per protected VNet and covers all public IPs; it is more expensive than IP Protection when only one public IP needs coverage.
2. Enable Azure Front Door with WAF so it absorbs the volumetric DDoS floods at the edge with adaptive tuning before the traffic ever reaches the single protected public IP.

   Front Door with WAF protects against Layer 7 attacks like SQLi and XSS and is not a substitute for volumetric L3/L4 DDoS protection with adaptive tuning.
3. Azure DDoS IP Protection — enables DDoS protection on a single public IP address with adaptive tuning, at lower cost than protecting an entire VNet ✓

   DDoS IP Protection (formerly per-IP protection) protects individual public IP addresses with the same adaptive tuning and mitigation capabilities as Network Protection but scoped to a single IP. It is cost-effective when only one public IP needs protection.
4. Azure DDoS Infrastructure (Basic) Protection — it is free, automatic, and adds adaptive tuning that learns the application's normal traffic on that one public IP address.

   Infrastructure (Basic) protection is free and automatic but has no adaptive tuning, attack telemetry, or SLA, so it fails the adaptive tuning requirement.

DDoS IP Protection provides per-public-IP adaptive DDoS mitigation at lower cost than VNet-level Network Protection — ideal when protecting a single IP.

4. The query resolves to the public IP of the storage account: What happens when a VM in the spoke VNet queries f

1. The query automatically resolves to the private endpoint IP because Azure DNS detects the private endpoint in the subscription and overrides the public storage DNS response for that VNet.

   Azure DNS does not auto-redirect for private endpoints; a privatelink Private DNS zone with an A record must be created and linked to the VNet.
2. The query resolves to the private endpoint IP because the custom DNS server forwards to Azure DNS at 168.63.129.16, which is aware of every private endpoint provisioned in the subscription.

   Azure DNS returns private endpoint records only when the corresponding Private DNS zone is linked to the querying VNet; otherwise it returns the public CNAME chain.
3. The query fails with an NXDOMAIN response because creating the private endpoint removes the public DNS record for the storage account, leaving no resolvable public address at all.

   Private endpoints do not remove the public DNS records; the public FQDN stays resolvable, and only linked Private DNS zones return the private IP.
4. The query resolves to the public IP of the storage account because no Azure Private DNS zone has been linked to the VNet — the private endpoint alone does not redirect DNS resolution ✓

   Creating a private endpoint assigns a private IP but does NOT automatically update DNS resolution. Without an Azure Private DNS zone (privatelink.blob.core.windows.net) linked to the spoke VNet with an A record for the storage account, DNS resolution follows the public path and returns the public IP.

A private endpoint alone does not redirect DNS — an Azure Private DNS zone must be created and linked to the VNet for the FQDN to resolve to the private endpoint IP.

5. Configure the WAF policy in Detection mode: Which WAF mode configuration achieves this?

1. Configure the WAF policy in Detection mode — all requests are inspected and matching rule violations are logged but no requests are blocked ✓

   Detection mode logs potential attack traffic and generates alerts without blocking any requests. This allows the security team to analyze logs, identify false positives, create exclusions, and tune the configuration before switching to Prevention mode.
2. Deploy the Application Gateway without a WAF policy and enable network flow logs capturing the Layer 7 patterns WAF rules would match.

   Network flow logs capture IP-level connection data and cannot identify Layer 7 attack patterns; Detection mode is required to see which requests would match.
3. Configure the WAF policy in Prevention mode but set every managed rule's action to Log instead of Block, so requests are recorded without any disruption.

   Per-rule Log action is complex to manage across the rule set; Detection mode is the purpose-built, simplest mode for observation without blocking.
4. Configure the WAF policy in Prevention mode and raise the anomaly score threshold to its maximum of 100, so requests are logged for tuning but never blocked.

   Anomaly scoring only sets how many rules must match before blocking; a high threshold still blocks real attacks, whereas Detection mode blocks nothing.

WAF Detection mode logs rule violations without blocking traffic — it is designed for the initial tuning phase before switching to Prevention mode.

6. Deploy Azure Bastion in the VNet: Which solution satisfies all constraints?

1. Configure a Just-In-Time VM access policy in Defender for Cloud so RDP port 3389 is opened only for approved requests, letting administrators reach the VMs over HTTPS without assigning any public IP to them.

   JIT temporarily opens NSG rules for RDP from specific source IPs and still needs a reachable path; the scenario forbids any open 3389 rule and any VPN.
2. Deploy Azure Bastion in the VNet — administrators connect via the Azure portal or native client over HTTPS (port 443) to Bastion, which then creates RDP sessions to VMs using their private IPs ✓

   Azure Bastion is a managed PaaS service deployed in a dedicated AzureBastionSubnet. Admins connect via HTTPS from a browser or native client — no public IP on VMs, no open RDP port in NSGs, and no VPN required. Bastion handles the RDP session internally within the VNet.
3. Assign a public IP to each VM only during the administration window and remove it afterward, so port 3389 is exposed briefly and no NSG needs a standing inbound RDP allow rule.

   Temporary public IPs violate the no-public-IP requirement and expose RDP to the internet during the window, creating exactly the risk to be avoided.
4. Use an Azure VPN Gateway in point-to-site mode with certificate authentication, which tunnels the administrators' RDP traffic to the private VM IPs without opening port 3389 in any NSG.

   Point-to-site VPN requires client software and certificates on each workstation, but the scenario states no VPN connection may be required from admin workstations.

Azure Bastion provides browser/native-client RDP access to private VMs over HTTPS without public IPs, open RDP ports, or a VPN requirement.

7. Configure forced tunneling by advertising a default route: What configuration forces internet traffic through

1. Enable BGP on the VPN Gateway and use AS path prepending on the advertised routes to deprioritize Azure's built-in default internet route, so outbound traffic prefers the on-premises path to reach the corporate proxy for inspection.

   AS path prepending only influences BGP preference and cannot override Azure system routes; forced tunneling needs a 0.0.0.0/0 default route Azure will actually prefer.
2. Create a User-Defined Route on the spoke subnet with destination 0.0.0.0/0 whose next hop is an Azure NAT Gateway in the hub, forcing all internet-bound flows through the corporate proxy on-premises.

   NAT Gateway provides outbound connectivity over Azure's own internet path and does not send traffic on-premises; the next hop must be the VPN Gateway or an NVA.
3. Configure forced tunneling by advertising a default route (0.0.0.0/0) from the on-premises VPN gateway to override the Azure default internet route, and ensure BGP route propagation is enabled on the spoke VNet route tables ✓

   Forced tunneling routes all traffic (including internet-bound) through the VPN Gateway to on-premises by overriding Azure's default 0.0.0.0/0 internet route. The on-premises router advertises 0.0.0.0/0 via BGP, which propagates to spoke route tables when route propagation is enabled. Internet traffic goes: VM → Hub VPN Gateway → On-premises → Corporate Proxy → Internet.
4. Apply an NSG outbound rule on the spoke subnet that denies destination 0.0.0.0/0, which redirects all of the internet-bound traffic away from Azure's default path and through the on-premises corporate proxy.

   An NSG deny rule blocks traffic entirely rather than redirecting it; forced tunneling reroutes internet-bound traffic to on-premises, it does not drop it.

Forced tunneling is achieved by advertising 0.0.0.0/0 from on-premises via BGP through the VPN Gateway, overriding Azure's default internet route for all spoke subnet traffic.

8. The traffic is denied: What is the result?

1. The traffic is denied — network rules are evaluated before application rules, and the deny rule in RCG-Security (priority 100) blocks TCP 443 to 10.0.5.0/24 before the application rule in RCG-App is ever evaluated ✓

   Azure Firewall evaluates rule collection groups in ascending priority order. Within a rule collection group, network rules are evaluated before application rules. RCG-Security at priority 100 contains a deny for TCP 443 to 10.0.5.0/24. Since 10.0.5.10 falls in that range, the deny matches and traffic is blocked. The application rule in RCG-App (priority 200) is never reached.
2. The traffic is allowed, because in Azure Firewall an application rule collection always takes precedence over a network rule collection whenever both match the same HTTPS flow to contoso.com

   In Azure Firewall, network rules do NOT lose to application rules as a global precedence. Rule collection groups are evaluated by priority number (lower = higher priority), and within a group NAT rules run first, then network rules, then application rules. The denying network rule in the higher-priority group (100 vs 200) wins.
3. The traffic is denied by the default implicit deny at the end of the rule set, because HTTPS destined for a private IP range such as 10.0.5.0/24 is always blocked by Azure Firewall unless an explicit network allow rule exists

   While Azure Firewall does have an implicit deny at the end of all rules, the specific deny from RCG-Security is the actual matching rule in this scenario. The result is caused by the explicit deny rule, not the implicit fallback, and private IPs are not universally blocked.
4. The traffic is allowed, because Azure Firewall evaluates only application rules for HTTPS traffic and applies network rules exclusively to non-HTTP protocols such as SSH or RDP on other ports

   This is incorrect. Azure Firewall can apply network rules to any protocol and port including TCP 443. Network rules match on IP, port, and protocol while application rules match on FQDN/URL, and both can match HTTPS traffic — evaluation order determines which wins.

Rule collection groups are evaluated by priority ascending. RCG-Security (priority 100) denies TCP 443 to 10.0.5.0/24 before RCG-App (priority 200) can allow the application rule.

9. Use the 'AzureMonitor' service tag as the source: Which source specification achieves this?

1. Use the 'Internet' service tag as the NSG source and add application-level filtering on top to restrict the allowed traffic to only Azure Monitor endpoints

   The 'Internet' service tag represents all public IP space outside Azure, which would allow traffic from any internet source. NSGs operate at L3/L4 and cannot perform application-layer filtering, so this approach is both overly broad and technically infeasible.
2. Use the 'AzureMonitor' service tag as the source in the NSG inbound rule — Microsoft automatically keeps service tags updated with current IP ranges for the service ✓

   Service tags are named groups of IP address prefixes managed by Microsoft for specific Azure services. The 'AzureMonitor' service tag represents all IP ranges used by Azure Monitor. As Microsoft expands capacity, the service tag is updated automatically — no manual NSG rule changes are required.
3. Create a custom NSG application security group (ASG) for Azure Monitor and populate it with every published Azure Monitor IP range so the rule stays current as the service expands

   Application Security Groups (ASGs) are used to group Azure VM network interfaces for simplified NSG rule targeting — they cannot contain external service IP ranges. ASGs are not a mechanism for representing Azure service IP ranges in NSG rules.
4. Download the Azure IP ranges JSON file on a weekly schedule and run a PowerShell script that updates the NSG rule with the latest Azure Monitor prefixes each time they change

   While technically possible, this manual approach is error-prone and requires ongoing maintenance. Service tags are the designed solution for exactly this use case because they stay current automatically without custom download-and-update automation.

Service tags like 'AzureMonitor' are Microsoft-managed IP prefix groups that auto-update as services expand, eliminating the need to manually track and update IP ranges in NSG rules.

10. Company A configures a Private Link Service: Which Azure components must each company configure?

1. Both companies configure VNet peering with non-overlapping address spaces, and Company A then exposes the internal load balancer IP directly into Company B's subnet for the application traffic

   The requirement explicitly states no VNet peering between companies. VNet peering also requires non-overlapping address space, which may not be guaranteed across independent organizations. Private Link is specifically designed for cross-VNet/cross-tenant service access without peering.
2. Company A creates a Private Endpoint for their internal load balancer, and Company B deploys a Virtual Network Gateway to establish the tunnel that reaches Company A's endpoint from its own VNet

   Private Endpoints are consumer-side resources that represent services inside a consumer's VNet. Company A (the provider) configures a Private Link Service on their load balancer, not a Private Endpoint. A Virtual Network Gateway is for site-to-site or point-to-site VPN and is not used for Private Link consumption.
3. Company A configures a Private Link Service on their internal load balancer. Company B creates a Private Endpoint in their VNet that connects to Company A's Private Link Service — no VNet peering is required ✓

   Private Link Service (provider side) attaches to an Azure Standard Internal Load Balancer and enables the service to be consumed by others. Private Endpoint (consumer side) creates a private NIC in Company B's VNet with a private IP that connects to Company A's Private Link Service. Traffic flows through the Microsoft backbone without VNet peering.
4. Company A fronts the service with an Azure Application Gateway that exposes a public endpoint, and Company B's VMs then connect to it across the public internet, relying on TLS certificate validation to secure the session

   Using a public endpoint routes traffic over the internet, which is less secure and does not provide the private IP inside Company B's VNet as required. Private Link enables purely private connectivity within the Microsoft backbone instead.

Company A deploys a Private Link Service on their internal load balancer. Company B creates a Private Endpoint in their VNet — traffic flows privately without VNet peering.

11. Create a parent Firewall Policy with baseline rules: Which Azure Firewall Manager capability enables this hier

1. Configure a management group over the hub subscriptions and assign RBAC roles that restrict regional teams from modifying the resource group holding the baseline firewall policy definitions

   RBAC can prevent unauthorized modifications but does not create a policy inheritance hierarchy. Regional teams would simply be blocked from modifying anything rather than being able to add region-specific rules on top of an enforced baseline.
2. Use Azure Blueprints to lock the baseline firewall rules across all five hubs and assign a separate blueprint per region so each regional team can layer in their own local firewall rules

   Azure Blueprints are a deployment-time governance tool (now deprecated in favor of Template Specs and Deployment Stacks). They do not provide a runtime hierarchical Firewall Policy inheritance mechanism between a parent and child policy.
3. Create a single Azure Policy definition that encodes the baseline rule conditions, assign it to every firewall resource group, and have regional teams modify their firewall via their own ARM templates

   Azure Policy governs resource configurations and compliance but does not create a hierarchical Firewall Policy structure. ARM templates create resources but do not provide the parent-child policy inheritance model that the scenario requires.
4. Create a parent Firewall Policy with baseline rules. Create child Firewall Policies per region that inherit the parent policy — child policies can add regional rules but cannot override parent rules ✓

   Azure Firewall Manager supports a hierarchical policy model. A parent policy defines baseline rules enforced across all firewalls. Child policies inherit all parent rules (read-only for child) and can add local rules. This gives central security control over baseline while allowing regional customization.

Azure Firewall Manager's parent-child policy hierarchy enforces baseline rules centrally while allowing child policies to add regional rules without overriding the parent.

12. Create two Application Security Groups: Which Azure feature achieves this?

1. Use Azure Service Endpoints on the shared subnet so that the database tier VMs will only accept inbound connections that originate from the web tier VMs, and rely on new VMs automatically picking up that restriction as soon as they are added to the subnet

   Service endpoints restrict traffic from VNets to Azure PaaS services such as Azure SQL and Storage. They cannot create allow rules between VMs within the same VNet, so micro-segmentation between web and database VMs must use NSG rules, ideally with ASGs.
2. Create two Application Security Groups (ASGs) — 'ASG-WebTier' and 'ASG-DatabaseTier'. Assign each VM's NIC to the appropriate ASG. Create one NSG rule: Source = ASG-WebTier, Destination = ASG-DatabaseTier, Port = 1433, Allow. New VMs added to an ASG automatically inherit the rule ✓

   ASGs group VM NICs logically. NSG rules can reference ASGs as source/destination instead of IP addresses. When new VMs are assigned to an ASG, they automatically participate in all rules referencing that ASG — no rule updates needed.
3. Create an individual NSG rule for each VM using its specific source and destination IP addresses on port 1433, and then add the IP addresses of any newly provisioned web tier or database tier VMs into the rule set manually each time they come online in the subnet

   The requirement explicitly states no individual IP-based rules should be used and that new VMs must be covered automatically. Per-VM IP rules require manual updates on every new VM, which is exactly the maintenance burden that ASG-based rules eliminate.
4. Create a User-Defined Route (UDR) on the shared subnet that sends all port 1433 traffic to an Azure Firewall NVA for deep inspection, so that only the web-to-database flows which pass that inspection are permitted to continue to the target

   UDRs route traffic to a next hop but do not enforce allow/deny rules between VMs, and traffic between VMs in the same subnet is not forced through a UDR by default. ASG-based NSG rules are the correct mechanism for same-subnet micro-segmentation.

ASGs enable VM group-based NSG rules. Assigning a VM's NIC to an ASG automatically applies all rules referencing that ASG — no IP-based rule management required.

Other AZ-500 domains

• Manage security operations — 137 questions →
• Secure compute, storage, and databases — 132 questions →
• Manage identity and access — 126 questions →
• All 500 AZ-500 questions →