4 of the 20 questions we have for this objective, shown with the answer and the reasoning.
Implement security for Azure network services
Wide World Importers is building a site-to-site VPN from its Hamburg data center to the virtual network vnet-eu-prod. The on-premises firewall is certified only for IKEv2 with AES-256 and SHA-256 integrity, Diffie-Hellman group 14 for IKE, and Perfect Forward Secrecy group 14 for IPsec, with an IPsec SA lifetime of 3,600 seconds. The company's security baseline forbids falling back to any weaker proposal that Azure offers by default.
Which two actions should you perform? Each correct answer presents part of the solution.
- ADeploy a route-based VPN gateway in vnet-eu-prod.Custom IPsec/IKE policies are supported only on route-based VPN gateways. Route-based gateways use IKEv2 for site-to-site connections, which matches the on-premises device.
- BConfigure a custom IPsec/IKE policy on the site-to-site connection that specifies AES256 and SHA256 for IKE with DHGroup14, AES256 and SHA256 for IPsec with PFS14, and an SA lifetime of 3,600 seconds.A custom policy on the connection replaces the default proposal set with exactly one combination, so Azure never negotiates a weaker algorithm than the baseline allows.
- CDeploy a policy-based VPN gateway in vnet-eu-prod.Policy-based gateways support only IKEv1, a single tunnel, and no custom IPsec/IKE policies, so they cannot meet the IKEv2 or algorithm requirements.
- DConfigure the custom IPsec/IKE policy on the VPN gateway resource so that it applies to all connections.Custom IPsec/IKE policies are a property of the connection, not the gateway. There is no gateway-level policy setting.
- EEnable BGP on the connection and advertise the on-premises prefixes.BGP exchanges routes dynamically and has no bearing on which cryptographic proposals are negotiated.
Why: By default an Azure VPN gateway offers a list of IPsec/IKE proposals and accepts the first one the peer agrees to, which can include algorithms a strict baseline does not permit. A custom IPsec/IKE policy pins the negotiation to one explicit set of encryption, integrity, DH group, PFS group, and SA lifetime values, and it is configured per site-to-site or VNet-to-VNet connection. Because the feature exists only on route-based gateways, the gateway type is part of the solution. The deciding constraints are the fixed algorithm set and the ban on weaker fallback, which make the default proposals unacceptable. The traps are the policy-based gateway, which looks like it matches the word policy but is IKEv1-only, and placing the policy on the gateway rather than the connection.
Implement security for Azure network services
Graphic Design Institute has a site-to-site VPN from its campus to the virtual network vnet-gdi. Faculty on campus must upload files to the storage account stgdiarchive, and the security policy states that traffic to the storage account must never be sent to a public IP address, whether from the campus or from VMs in vnet-gdi.
What should you configure?
- AA private endpoint for stgdiarchive in vnet-gdi.A private endpoint assigns the storage account a private IP from the VNet. Both VNet workloads and on-premises clients connected through the VPN reach that private IP, so no traffic is sent to a public address.
- BA Microsoft.Storage service endpoint on the subnets in vnet-gdi and a virtual network rule on stgdiarchive.Service endpoints keep the storage account on its public IP and optimize routing for Azure subnets only. On-premises traffic from the campus cannot use a service endpoint.
- CIP network rules on the storage firewall for the campus public address range.An IP rule permits the campus to reach the public endpoint of the storage account, which is exactly the public IP traffic the policy prohibits.
- DExpressRoute with Microsoft peering to reach Azure Storage.Microsoft peering advertises the public prefixes of Azure services, so traffic still targets public IP addresses, and it would replace rather than use the existing VPN.
Why: The distinction between service endpoints and private endpoints is a recurring exam theme. A service endpoint is a subnet-level routing optimization that lets Azure Storage identify traffic by its source VNet and subnet, but the destination remains the service's public IP and the feature does not extend to on-premises networks. A private endpoint is a network interface in your VNet with a private IP that maps to a specific storage account; because it is simply an address inside the VNet, any network that can reach the VNet, including a site-to-site VPN or ExpressRoute private peering, can use it. The deciding constraint is the ban on public IP destinations from both locations, which only the private endpoint meets.
Implement security for Azure network services
Fourth Coffee publishes a web farm through a Standard public load balancer named lb-web-pub. The backend VMs sit in the subnet snet-web, whose network security group nsg-web contains a single custom inbound rule: priority 200, Deny, source Any, destination Any, any protocol, any port, which an administrator added to block all inbound traffic. Since then the TCP 443 health probes report every backend unhealthy and internet clients cannot connect on TCP 443. The deny rule must stay, and only HTTPS from the internet plus the load balancer health probes may be allowed into snet-web.
Which two inbound rules should you add to nsg-web? Each correct answer presents part of the solution.
- APriority 100, Allow, source service tag AzureLoadBalancer, destination Any, TCP 443.Health probes originate from the AzureLoadBalancer service tag (168.63.129.16). The custom Deny at 200 is processed before the default AllowAzureLoadBalancerInBound rule at 65001, so an explicit allow with a lower priority number than 200 is required for the probes to reach the backends.
- BPriority 110, Allow, source service tag Internet, destination Any, TCP 443.A Standard public load balancer preserves the client source IP on inbound flows, so backend traffic arrives from internet addresses, and Standard load balancers are secure by default, so an explicit NSG allow is mandatory. Priority 110 is evaluated before the Deny at 200.
- CPriority 300, Allow, source service tag Internet, destination Any, TCP 443.Rules are evaluated in ascending priority order and processing stops at the first match. The Deny at 200 matches HTTPS first, so an allow at 300 is never reached.
- DDelete the default DenyAllInBound rule at priority 65500.Default rules cannot be deleted or modified, and the traffic is being dropped by the custom Deny at 200, not by the default rule.
- EPriority 120, Allow, direction Outbound, destination service tag Internet, TCP 443.NSGs are stateful, so return traffic for an allowed inbound flow is permitted automatically. An outbound rule does not fix an inbound connectivity failure.
Why: A Standard load balancer is closed by default: traffic reaches a backend only if an NSG explicitly allows it, and because the load balancer does not perform source NAT for inbound flows, the backend sees the original client IP, so the rule must allow the Internet service tag (or a narrower public range), not the load balancer frontend address. Health probes come from the AzureLoadBalancer service tag; normally the default AllowAzureLoadBalancerInBound rule at 65001 admits them, but custom rules are evaluated before default rules, so a blanket custom Deny shadows that default and the probes need their own allow with a lower priority number. The deciding details are rule ordering (allows must sit below the Deny at 200, so 300 is useless) and the immutability of default rules. The outbound distractor tests the stateful nature of NSGs: allowed inbound flows get their replies without a matching outbound rule.
Implement security for Azure network services
Contoso Logistics has configured Microsoft Entra Private Access. A private network connector group named cg-dallas is installed on two servers in the Dallas data center, Quick Access is configured for 10.50.0.0/16, and users are assigned. A pilot user on a Microsoft Entra joined Windows 11 laptop reports that connections to 10.50.3.20 time out from the corporate Wi-Fi and from home.
What is most likely missing on the laptop?
- AThe Global Secure Access client with the Private Access traffic forwarding profile enabled.The Global Secure Access client intercepts traffic that matches the Private Access traffic forwarding profile and tunnels it to the Global Secure Access edge, which relays it through the connector group. Without the client, traffic to 10.50.3.20 is routed normally and fails.
- BThe Azure VPN Client with an imported point-to-site profile.The Azure VPN Client connects to an Azure VPN Gateway. Microsoft Entra Private Access does not use a VPN gateway or the Azure VPN Client.
- CA Microsoft Entra private network connector installed on the laptop.Connectors are installed on servers inside the private network to relay traffic outbound to the service. They are never installed on user devices.
- DA static route for 10.50.0.0/16 pointing to the Global Secure Access edge.Traffic steering is performed by the Global Secure Access client based on the forwarding profile, not by operating system routes.
Why: Microsoft Entra Private Access has three moving parts: the Global Secure Access client on the user's device, the Global Secure Access edge in Microsoft's network, and one or more private network connectors inside the customer network. The client evaluates the traffic forwarding profiles enabled for the tenant and intercepts matching destinations, such as Quick Access IP ranges, tunneling them to the edge; the edge then brokers the connection through a connector that reaches the resource. The deciding clue is that the failure happens from any network, which points at the device, and the only device-side component is the client. The trap is reaching for VPN concepts such as clients, routes, or connectors on endpoints, none of which belong in this architecture.