4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
Configure secure access to virtual networks
Elmcroft Publishing has a virtual machine named VM-Build in subnet snet-ci. NSG-CI is associated with the subnet, and NSG-Build is associated with the VM's NIC. The build agent on VM-Build must reach a package feed on the internet over TCP 443, but the connection fails. Both NSGs have only the default rules plus the custom outbound rules shown:
NSG-CI (subnet) outbound:
Priority | Name | Destination | Dest port | Action
100 | Allow-Internet-443 | Internet | 443 | Allow
NSG-Build (NIC) outbound:
Priority | Name | Destination | Dest port | Action
100 | Deny-Internet | Internet | * | Deny
Why does the connection fail?
- AOutbound traffic is evaluated by the NIC NSG first; the Deny-Internet rule in NSG-Build matches and the packet is dropped before NSG-CI is ever consulted.For outbound traffic, the NIC NSG is processed first and the subnet NSG second. A deny at the NIC level ends evaluation.
- BThe default DenyAllOutBound rule in NSG-CI blocks the traffic because custom outbound rules require a matching inbound rule.NSGs are stateful; a return path does not need a separate rule. Also, NSG-CI explicitly allows the traffic at priority 100.
- COutbound traffic is evaluated by the subnet NSG first; the Allow-Internet-443 rule allows it, but the AllowInternetOutBound default rule at 65001 in NSG-Build then overrides the custom deny.Default rules have the highest priority numbers and are evaluated last; they never override a custom rule, and the subnet-first order is wrong for outbound traffic.
- DThe Allow-Internet-443 rule in NSG-CI is ignored because the Internet service tag cannot be used as a destination in outbound rules.The Internet service tag is valid as a destination in outbound rules; it is the standard way to reference public address space.
Why: NSG evaluation order depends on direction. Inbound traffic hits the subnet NSG first and then the NIC NSG; outbound traffic hits the NIC NSG first and then the subnet NSG. In both directions the traffic must be allowed by every NSG it passes through, and a deny at any level is final. In this scenario the NIC-level NSG denies all outbound internet traffic at priority 100, so the subnet-level allow never matters. The distractors test two misconceptions: that default rules can override custom rules (they cannot, because they are evaluated last) and that NSGs are stateless (they are stateful). To fix the problem, add an allow rule for port 443 to NSG-Build at a priority below 100 or remove the deny.
Configure secure access to virtual networks
Solvane Biotech plans to deploy an Azure Bastion host with the Basic SKU in an existing virtual network named VNet-Research (10.30.0.0/16). The network currently has three subnets named snet-web, snet-app, and snet-mgmt. Bastion must be able to serve RDP and SSH sessions to any VM in VNet-Research and in its peered spoke networks, and the deployment must succeed on the first attempt.
Which two actions should you perform before creating the Bastion host? Each correct answer presents part of the solution.
- ACreate a subnet named AzureBastionSubnet with a prefix of /26 or larger.Bastion requires a dedicated subnet with exactly this name and a minimum size of /26 for the Basic, Standard, and Premium SKUs.
- BCreate a Standard SKU, static public IP address in the same region as VNet-Research.A Bastion host (other than the Developer offering) needs a Standard SKU public IP in the same region; this is the address the Bastion service listens on for TLS sessions.
- CCreate a subnet named BastionSubnet with a prefix of /28.The subnet must be named exactly AzureBastionSubnet, and /28 is too small; the minimum is /26.
- DAssign a public IP address to each target virtual machine.The purpose of Bastion is to reach VMs that have no public IP address; adding public IPs to the targets is unnecessary and reduces security.
- EAssociate a network security group with snet-mgmt that allows inbound TCP 3389 and 22 from the Internet service tag.Bastion connects to VMs over their private IP from the AzureBastionSubnet, so the target NSG needs to allow 3389 and 22 from the Bastion subnet range or VirtualNetwork tag, not from the Internet.
Why: A standard Bastion deployment has two prerequisites that trip people up: a dedicated subnet named exactly AzureBastionSubnet sized /26 or larger (the /27 minimum from earlier years is no longer accepted for new deployments), and a Standard SKU static public IP address in the same region. The Bastion host itself handles TLS from the browser or native client and then opens RDP or SSH to the target VM's private IP, so targets never need public IPs. The peered-spoke requirement is met natively because Bastion supports connecting to VMs in peered virtual networks. The deciding detail is that the deployment must succeed first time, which means both prerequisites must be in place.
Configure secure access to virtual networks
Kestrel Foods has a virtual machine named VM-POS whose NIC has an associated NSG, while the subnet it sits in has a different NSG. A junior administrator needs to see the complete, merged list of inbound and outbound rules that actually apply to VM-POS, including the default rules and the expanded address prefixes behind service tags, without running a per-flow test.
What should the administrator open?
- AThe Effective security rules view on the network interface of VM-POS.Effective security rules shows the combined rules from the subnet NSG and the NIC NSG as applied to that interface, including default rules and the prefixes behind each service tag.
- BThe Effective routes view on the network interface of VM-POS.Effective routes shows the merged routing table (system, BGP, and user-defined routes), not security rules.
- CThe Inbound security rules blade of the subnet NSG.This shows only the rules in one NSG; it does not include the NIC NSG or expand service tags.
- DConnection troubleshoot in Network Watcher.Connection troubleshoot tests a single connection between a source and destination; it does not list the full applied rule set.
Why: Because an NSG can be applied at both the subnet and the NIC, reading one NSG in isolation gives an incomplete picture. The Effective security rules feature (available from the NIC blade and from Network Watcher) merges every NSG that applies to an interface, shows the default rules, and expands service tags such as VirtualNetwork and AzureLoadBalancer into the actual address prefixes in use. The deciding requirements are a complete merged list and no per-flow test, which rules out IP flow verify and Connection troubleshoot. Effective routes is the routing counterpart and is the most common mix-up.
Configure secure access to virtual networks
Alderley Shipping has a storage account named stalderleydata and a virtual network named VNet-Ops with a subnet named snet-batch. The company wants VMs in snet-batch to reach the storage account over the Azure backbone using the storage account's existing public endpoint, and wants the storage account firewall to reject traffic from all other networks. The solution must minimize cost; no private IP address for the storage account is required.
What should you do?
- AEnable the Microsoft.Storage service endpoint on snet-batch, then add snet-batch as an allowed virtual network in the storage account's networking settings and set public access to Enabled from selected virtual networks and IP addresses.Service endpoints are enabled per subnet per service, and the storage firewall must then list that subnet. Together they route traffic over the backbone and restrict access to the subnet.
- BCreate a private endpoint for the blob service of stalderleydata in snet-batch and link the privatelink.blob.core.windows.net DNS zone to VNet-Ops.A private endpoint meets the security goal but assigns a private IP and incurs hourly and per-GB charges; the scenario explicitly says no private IP is needed and cost must be minimized.
- CAttach a NAT gateway to snet-batch and add its public IP address to the storage account firewall's allowed IP list.Storage firewall IP rules have no effect on requests that originate from the same Azure region as the storage account, so this does not grant access; it also adds NAT gateway cost and keeps traffic off the service endpoint path.
- DEnable the Microsoft.Storage service endpoint on snet-batch and set the storage account public network access to Disabled.Disabling public network access blocks service endpoint traffic as well, because service endpoints still use the public endpoint of the service. Access would then require a private endpoint.
Why: A virtual network service endpoint extends the virtual network identity to a PaaS service: once enabled on a subnet for Microsoft.Storage, traffic from that subnet to Azure Storage travels over the Azure backbone and arrives with the subnet as its source, so the storage firewall can allow that subnet and deny everything else. Service endpoints have no additional charge and do not create a private IP, which fits the cost constraint. The two-part trap is that enabling the endpoint on the subnet alone does nothing until the storage account firewall lists the subnet, and that setting public network access to Disabled breaks service endpoints because they still target the public endpoint. Private endpoints are the right answer only when traffic must come from on-premises or a private IP is required.