Task 2.3: Implement security for Azure network services

• AA rule that denies the Internet service tag inbound at priority 100

  Incorrect

  Traffic from a peered spoke isn't Internet traffic.

• BAn outbound rule on the dev spoke's NSG that denies VirtualNetwork

  Incorrect

  That would also block the dev VMs from their own virtual network and the hub's other services.

• CAn inbound rule that denies the dev spoke's address range

  Correct

  AllowVnetInBound uses the VirtualNetwork tag, which includes peered networks, so the spoke needs an explicit deny.

• DRemoval of the AllowVnetInBound default rule

  Incorrect

  Default rules can't be removed, only overridden by higher-priority rules.

The default AllowVnetInBound rule allows the VirtualNetwork service tag, which covers the virtual network's address space, peered virtual networks, connected on-premises address spaces and more. Default rules can't be deleted, so to block a peered spoke while keeping on-premises access, add an explicit deny rule for the spoke's range with a higher priority (lower number) than 65000.

• AAn NSG rule with priority 100 copied into every application NSG

  Incorrect

  Application teams could edit or remove the copied rules.

• BA security admin rule with the Allow action for the scanners' range on TCP 22

  Incorrect

  An Allow admin rule is followed by NSG evaluation, so an NSG can still deny the traffic.

• CA security admin rule with the Always Allow action for the scanners' range on TCP 22

  Correct

  Always Allow sends the traffic to the resource and stops further evaluation by NSG rules.

• DA connectivity configuration that peers the scanners' network with every virtual network

  Incorrect

  Connectivity doesn't override NSG denies.

Security admin rules are evaluated before NSG rules. An Allow rule passes the traffic on to NSG evaluation, while Always Allow and Deny terminate evaluation: Always Allow delivers the traffic directly to the resource, preventing denial by conflicting NSG rules, and Deny drops it.

• APut the application rule collection in its own rule collection group that has a higher priority

  Incorrect

  Network rules are always processed before application rules, whatever the rule collection group priority.

• BEnable threat intelligence in alert-only mode

  Incorrect

  Alert-only mode logs known-bad traffic but doesn't restrict destinations.

• CAdd a deny-all application rule in a higher-priority collection

  Incorrect

  The traffic is already allowed by the network rule before application rules run.

• DLimit the network rule to the specific addresses that app needs

  Correct

  Rules are terminating and network rules run first, so a broad network allow bypasses the FQDN filtering.

Azure Firewall processes DNAT rules, then network rules, then application rules, regardless of rule collection group or collection priority. Rules are terminating, so a network rule that allows TCP 443 to any address matches web traffic before any application rule is evaluated. Narrow the network rule to what the legacy app needs.

• AUpgrade the gateway to a zone-redundant SKU

  Incorrect

  The gateway SKU isn't what Entra authentication depends on here.

• BSwitch to OpenVPN, with users on the Azure VPN Client

  Correct

  Microsoft Entra ID authentication is supported only for OpenVPN, and clients must use the Azure VPN Client.

• CKeep IKEv2 and SSTP and add a RADIUS server that forwards to Microsoft Entra ID

  Incorrect

  RADIUS is a separate authentication type, not native Entra sign-in with Conditional Access.

• DIssue user certificates from Microsoft Entra ID

  Incorrect

  Entra authentication replaces certificates; it doesn't issue them.

Point-to-site VPN can authenticate users with Microsoft Entra ID, which brings Conditional Access and MFA to VPN sign-in. Microsoft Entra ID authentication is supported only for the OpenVPN protocol, and clients must use the Azure VPN Client. IKEv2 and SSTP work with certificate or RADIUS authentication.

• AApplication rules are preferred, because the firewall always SNATs traffic they process

  Correct

  SNAT keeps the return path symmetric through the firewall.

• BIf network rules are used, SNAT must be configured to keep the flows symmetric

  Correct

  Network rules don't SNAT private destinations by default.

• CNSG rules on the private endpoint subnet filter this traffic without any extra setting

  Incorrect

  Network policies are disabled for private endpoint subnets by default, so NSGs are bypassed unless you enable them.

• DPrivate endpoints need a public IP address for the firewall to inspect their traffic

  Incorrect

  Private endpoints use private IPs; inspection doesn't need public addresses.

• EThe firewall must use FQDN application rules for the SQL traffic in redirect mode

  Incorrect

  SQL FQDN filtering in application rules works in proxy mode only; redirect mode uses network rules.

To inspect traffic to private endpoints, Microsoft recommends application rules, because Azure Firewall always SNATs traffic with application rules and so keeps flows symmetric. If network rules or an NVA are used, configure SNAT. NSG and UDR support on the private endpoint subnet needs network policies enabled. SQL FQDN filtering in application rules requires proxy mode.

• AAssociating an NSG with each subnet so that the configuration has something to attach to

  Incorrect

  Security admin rules apply to virtual networks without NSGs.

• BWaiting for Azure Policy to evaluate the network group

  Incorrect

  The network group is already correct.

• CDeploying the configuration to the regions of those virtual networks

  Correct

  Configurations don't take effect until they're deployed to the selected regions.

• DAssigning Network Contributor to the network manager on each virtual network

  Incorrect

  Applying configurations within the manager's scope doesn't need per-network role assignments.

Azure Virtual Network Manager applies configurations through deployments: a configuration doesn't take effect until it's deployed, and you choose the regions when you commit. Only one security admin configuration per network manager can be deployed to a region at a time, so put several rule sets into rule collections of that configuration.

• AFrom the lowest priority number (100) to the highest (65,000)

  Correct

  Rule collections are processed in priority order by rule type, lower numbers first.

• BAlphabetically by rule collection name

  Incorrect

  Names don't decide order.

• CIn the order they were created

  Incorrect

  Creation time doesn't decide order.

• DFrom the highest priority number to the lowest

  Incorrect

  Lower numbers are processed first.

Azure Firewall denies all traffic until rules allow it. It processes rule collections in priority order by rule type, from lower numbers to higher (100 to 65,000), and rules are terminating: processing stops at the first match.

• AA Basic internal load balancer

  Incorrect

  Basic Load Balancer isn't supported.

• BA Standard Load Balancer in the same region

  Correct

  Private Link service is tied to a Standard Load Balancer frontend.

• CAzure Application Gateway in any region

  Incorrect

  A Private Link service references a Standard Load Balancer.

• DAzure Traffic Manager

  Incorrect

  Traffic Manager is DNS-based and can't back a Private Link service.

A Private Link service references the frontend IP configuration of an Azure Standard Load Balancer; Basic Load Balancer isn't supported. The service must be in the same region as its virtual network and load balancer.

• ADDoS Network Protection and DDoS IP Protection

  Correct

  Network Protection covers resources in a virtual network; IP Protection is per protected IP.

• BDDoS Basic Protection and DDoS Premium Protection

  Incorrect

  Those aren't the current tier names.

• CDDoS Standard and DDoS Enterprise

  Incorrect

  Those aren't the current tier names.

• DDDoS Edge and DDoS Origin

  Incorrect

  Those aren't Azure DDoS Protection tiers.

Azure DDoS Protection has two tiers: DDoS Network Protection, tuned to resources in a virtual network and including DDoS rapid response, cost protection and WAF discounts, and DDoS IP Protection, a pay-per-protected-IP model with the same core mitigation.

• ARemove the trusted root certificate from the point-to-site configuration

  Incorrect

  That revokes every client certificate generated from the root, so all users lose access.

• BDisable the laptop owner's account in Microsoft Entra ID

  Incorrect

  Certificate authentication checks the client certificate, not the user's Entra account.

• CAdd the stolen laptop's client certificate thumbprint under Revoked certificates

  Correct

  The revocation list denies P2S connections for individual client certificates while the others keep working.

• DReset the VPN gateway to drop the laptop's current connection

  Incorrect

  A reset reboots the gateway and reapplies its configuration; the certificate stays valid, so the laptop can connect again.

Removing a trusted root certificate revokes access for every client certificate it signed. To block one client, add the thumbprint of its client certificate to the revocation list on the gateway's Point-to-site configuration page; other certificates from the same root stay valid. That's why unique client certificates per client are recommended: a shared one would have to be replaced on every client that uses it.