A contractor tries to deploy Azure Bastion into the same subnet as the lock-chamber virtual machines and the deployment fails. What must the security engineer create for Bastion?
Select an answer to reveal the explanation.
Short Explanation
Bastion is picky about its parking spot: a subnet literally named AzureBastionSubnet, sized at least /26, and empty of your lock VMs. Drop it next to the chambers and the deploy fails.
Full Explanation
Azure Bastion must land in a dedicated subnet whose name is exactly AzureBastionSubnet, with a prefix large enough for the service (at least /26 in current guidance), and that subnet must not host user workloads such as lock-chamber VMs. The platform expects that reserved naming and sizing so Bastion scale units, private endpoints, and management traffic can be placed correctly; co-locating Bastion NICs with application VMs is a common deployment failure the canal contractor hit.
Reusing GatewaySubnet fails by concept: GatewaySubnet is reserved for VPN or ExpressRoute gateways and must not host Bastion or other NICs. Placing Bastion NICs in the lock-chamber subnet and hoping an NSG service tag isolates traffic fails because Bastion deployment validation rejects non-dedicated subnets—service tags do not substitute for AzureBastionSubnet. Assuming a Virtual WAN secured hub automatically supplies a Bastion subnet for every spoke is incorrect; you still provision Bastion according to the hub design with its required dedicated subnet rather than inventing an auto-created per-spoke Bastion network.
Exam caveat: the subnet name is case-sensitive in practice as AzureBastionSubnet; renaming a generic subnet after the fact is not the same as creating the correctly named empty subnet before deploy. Operational check: in the hub VNet, confirm AzureBastionSubnet exists with adequate prefix, contains no lock-chamber NICs, and that Bastion deploys successfully before removing public IPs from the chambers.