Harbor pilots still RDP to lock-chamber virtual machines over the Internet because each VM has a public IP. How should the security engineer provide remote access while removing those public IPs?
Select an answer to reveal the explanation.
Short Explanation
Strip the public IPs off those lock VMs and park Bastion in the hub. Pilots still get RDP/SSH, but the session rides TLS through Bastion—no 3389 hanging on the open water.
Full Explanation
Azure Bastion in the hub, with public IPs removed from the lock-chamber virtual machines, is the secure remote-access pattern. Bastion brokers RDP and SSH over TLS through the Azure control plane into the private NIC of each VM, so harbor pilots keep interactive management without exposing TCP 3389 or 22 on the open Internet. Placing Bastion in the hub also centralizes the jump path for spoke lock VMs that peer to that hub, which matches typical hub-and-spoke canal designs.
Keeping the public IPs and allowing TCP 3389 from Any fails by concept: that widens the attack surface instead of removing it and leaves management ports permanently reachable from the Internet. A DIY jump VM with its own public IP in the same subnet merely relocates the exposed RDP endpoint; it is not Bastion, still requires hardening and patching of a permanent public host, and often becomes a standing risk. Azure Firewall DNAT that publishes RDP to each chamber VM is inbound port forwarding of the management protocol—it is not Bastion’s TLS-brokered portal or native-client path and still presents RDP to untrusted networks.
Exam caveat: Bastion requires its own dedicated AzureBastionSubnet (commonly at least /26) and does not live in the workload subnet with the lock VMs. Operational check: after deploy, confirm each lock-chamber VM has no public IP, connect through Bastion from the portal (or native client if licensed), and verify NSGs still deny direct Internet RDP to the private addresses.