Correct Answer: Box 1: Remove the public IP address from VM1 Note: A public load balancer can provide outbound connections for virtual machines (VMs) inside your virtual network. These connections are accomplished by translating their private IP addresses to public IP addresses. Public Load Balancers are used to load balance internet traffic to your VMs. Load balancer and the public IP address SKU must match when you use them with public IP addresses. Only Basic SKU IPs work with the Basic SKU load balancer and only Standard SKU IPs work with Standard SKU load balancers. Box 2: Create and configure an NSG NSGs are used to explicitly permit allowed traffic. If you do not have an NSG on a subnet or NIC of your virtual machine resource, traffic is not allowed to reach this resource.

Guys !! its simple! Don't get confused with complicated text book explanation in comment section . 1) Remove Public IP address from VM1 --> Reason being when you create a LB and add VM to backend pool make sure VM doesn't have a Public IP assigned to it . 2) Create and configure an NSG . --> key thing to notice in question is "STANDAR LB " . Backend pool VM in standard LB should compulsorily have NSG associated to it and configured with required port to be allowed. I created an LB with Basic sku and not standard.. Example : With basic sku LB i was able to connect vm via rdp without any nsg.. Now when I tested with standard LB I had to configure and NSG for the vm nic and allow port 3389 to rdp it.. Without nsg it won't allow to connect

- Create and assign NSG to VM1 - Remove the public IP Adress from VM1

This question was in exam 01/03/2024

I am a bit confused. Just testet the scenario and I was able to SSH access the VM1 over LB1's FrontEnd IP. No NSG exists, VM1 has its Public IP and even that no problem to SSH from home PC.

Cleared Exam today 26 Feb, This question was there in exam.

Summary: There is no correct answer for Box 1 or 2 Maybe historically there were limitations but as Feb 2023, they do not apply. Justification: Lab Test Results (Feb '23): Created Standard SKU LB Created VM (FreeBSD) with : -Basic PIP -Dynamic LIP -In an Availability Set -NO Network Security Group Attempted to create a Backend Pool in the LB: -I could create a BackEnd pool (IP Configuration) on the LB and add this VM above to the Backend pool of the LB. So there is actually NOTHING you MUST do to CREATE the backend pool. There is no correct answer for Box 1 NEXT I created a new load balancing rule for TCP22 on the LB to the backend pool with the VM in it. Succeeded no problem Attempted Connection to FrontEnd PIP of LB on TCP22 in Putty and got the certificate pop up you would accept. Accepted the certificate and got the login prompt So there is actually NOTHING you MUST do to CONNECT to VM1 from the LB There is no correct answer for Box 2 It was all good practice for me for my exam anyway :)

box1: remove IP because dynamic IP is not compatible with standard LB. box2: NSG because Standard load balancer is built on the zero trust network security model. Standard load balancers and standard public IP addresses are closed to inbound connections unless opened by Network Security Groups.

Given Answer

please see: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#securebydefault - Standard load balancer is built on the zero trust network security model. - Standard Load Balancer is secure by default and part of your virtual network. The virtual network is a private and isolated network. - Standard load balancers and standard public IP addresses are closed to inbound connections unless opened by Network Security Groups. NSGs are used to explicitly permit allowed traffic. If you don't have an NSG on a subnet or NIC of your virtual machine resource, traffic isn't allowed to reach this resource. To learn about NSGs and how to apply them to your scenario, see Network Security Groups. - Basic load balancer is open to the internet by default. - Load balancer doesn't store customer data.

Given Answer is correct and mlantonis is well explained

Just tested in the Azure portal. I was able to put the VM in the backend pool WITHOUT a NSG. The dynamic IP addresses are not compatible with a standard load balancer, as those IP's are basic. Basic Ip's cannot be mixed and used with a standard LB. The dynamic addresses had to be deleted from the NIC, and a static one created. mlantonis actually wrong on this one. Also, front facing LB's do not need Vms with public IP addresses as they have one themselves. Delete it Box 1: Remove the public IP address from VM1 Box2: Change Private IP address to static again, you do not need a NSG to connect a VM to a backend pool

Received this on my exam today 19/03/2022

I think that Box1 should be to change the private IP to static. If I understood well the documentation, you need both a static private IP address and a NSG. Box 1 asks what you "must" do. I don't think you "must" delete the public IP address, it just won't work.

Correct. Regarding box 2, reason is because Standard Load Balancer is "Closed to inbound flows unless allowed by a network security group" https://docs.microsoft.com/en-us/azure/load-balancer/skus#skus

guys, joke? Dinamic for LB??????????????

Verified it in Azure by setting this up. Box 1: Remove the public IP address from VM1 - You can only attach virtual machines in the backend pool that have a standard SKU public IP configuration or no public IP configuration. Since the Public IP of VM is dynamic, the IP must be a Basic SKU IP. You cannot add such a VM (with Basic SKU IP) to a standard SKU load balancer. The VM does not even show up in the backend pool portal for selection unless you remove the public IP or convert it to a Standard SKU IP. Box 2: Create and configure an NSG - Standard load balancer is built on the zero trust network security model. Standard load balancers and standard public IP addresses are closed to inbound connections unless opened by Network Security Groups. NSGs are used to explicitly permit allowed traffic.