Exam AZ-104 All QuestionsBrowse all questions from this exam
Go to Exam
Question 404

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.

After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.

You have an app named App1 that is installed on two Azure virtual machines named VM1 and VM2. Connections to App1 are managed by using an Azure Load

Balancer.

The effective network security configurations for VM2 are shown in the following exhibit.

You discover that connections to App1 from 131.107.100.50 over TCP port 443 fail.

You verify that the Load Balancer rules are configured correctly.

You need to ensure that connections to App1 can be established successfully from 131.107.100.50 over TCP port 443.

Solution: You create an inbound security rule that allows any traffic from the AzureLoadBalancer source and has a cost of 150.

Does this meet the goal?

    Correct Answer: B

    The solution provided does not meet the goal. The suggested action is to create an inbound security rule that allows any traffic from the AzureLoadBalancer source with a priority of 150. However, the primary issue is with the existing rule with priority 200, which blocks all inbound traffic on TCP port 443, including traffic from the Load Balancer health probe. This rule prevents the Load Balancer from correctly assessing the VM's health and routing traffic to it. Adding a rule with priority 150 to allow traffic from the AzureLoadBalancer would indeed allow health probes, but it doesn't directly address the problem of the blocked traffic from 131.107.100.50 over TCP 443 due to the existing deny rule at priority 200. Therefore, removing or adjusting the block rule with priority 200 would be necessary to resolve the connectivity issue.

Discussion
Bursuc03Option: A

The rule with priority 200 blocks all inbound trafic. That involves the Azure Load Balancer health probe directed to the VM. That results in VM2 being considered unhealthy and the LB does not route traffic to it (hence the issue). By placing a rule with the priority 150 that allows the AzureLoadBalancer traffic tag, VM2 is discovered as functional/healthy, the LB directs traffic to it => problem solved.

nzalex1

Thanks, true. The issue here is deeper than it looks and the issue is broken health probes by rule 200, you are right

magichappens

How would this solve the problem of a NIC that seems to be detached from the VM?

suryamk

rule with priority 200 is only blocking 442 inbound connection and not all the traffic.

Durden871

Health probes can be port 80 or 443. I'm not overly experienced in this field (hence why I'm using this after using labs and courses), but my presumption here is that we're making the assumption the probe is using port 443. 443 is allowed from the public IP of the client, but it's not going to be the IP of the load balancer. The load balancer will show up as unhealthy and fail if it can't communicate.

djhyfdgjk

LB Health Probe can be configured with TCP protocol, which is allowed by NSG

darsy2001

the "attach network interface" button is available. I have tested this in lab and this button only appears clikable when the vm is stopped. Should this be the problem in the whole series of questions?

mbravo

"The effective network security configurations for VM2 are shown" - this doesn't mean that the NSG is attached to the VM. From the show exhibit, it is clear that this NSG is attached to a subnet which renders your comment obsolete.

s9p3r7

how so?! if the VM is powered off that mean the whole NSG rules stuff is misleading, the admin should start the VM before even begin to start NSG rules evaluation

orion1024

why ? if VM is off no traffic is ever going to get there.

boyzz

doesn't mean that the "other" VM (VM1) also has the same attach network interface option enabled as it is off.. the screenshot clearly shows only VM2 and not VM1 and we definitely cannot afford to think VM1 is off too. So the AzLB rule in NSG takes precedence

ukivanlamlpi

i don't think a VM can create without network interface

RemmyTOption: B

The question appears in several case studies. Suggested possible solutions: NO - You create an inbound security rule that denies all traffic from the 131.107.100.50 source and has a cost of 64999. - You modify the priority of the Allow_131.107.100.50 inbound security rule. - You create an inbound security rule that allows any traffic from the AzureLoadBalancer source and has a cost of 150. - You create an inbound security rule that denies all traffic from the 131.107.100.50 source and has a priority of 64999. YES - You delete the BlockAllOther443 inbound security rule. - You create an inbound security rule that allows any traffic from the AzureLoadBalancer source and has a priority of 150. In this case traffic from the AzureLoadBalancer is blocked (port 443). There is no cost concept associated with a security rule, only priority. Cost refers to multiple networking routes with different cost (depending on bandwidth, delay, load, ,max MTU). In the context of routing protocols, "metric" or "cost" refers to a value used to determine the best path to a destination within a network.

RemmyTOption: B

There is no cost concept associated with a security rule in Azure, only priority. Cost refers to multiple networking routes with different cost (depending on bandwidth, delay, load, ,max MTU). YES: • You delete the BlockAllOther443 inbound security rule. • You create an inbound security rule that allows any traffic from the AzureLoadBalancer source and has a priority of 150. In this case traffic from the AzureLoadBalancer is blocked (port 443).

jhodaxOption: A

Answer A When an Azure Load Balancer get created, it will probe backend to detect if the backend service is healthy or not, the probe packet is sent from source address "AzureLoadBalancer", the IP address of "AzureLoadBalancer" is always 168.63.129.16. https://msazure.club/addendum-of-azure-load-balancer-and-nsg-rules/ What is happening here is the LB Health Probe of TCP 443 to VM1 & VM2 are getting blocked by Rule 200 so it thinks both VM1 and VM2 are down. Hence App1 is failing as the LB won't direct any 443 traffic anywhere as it considers all Hosts are down. Make a new rule above 200 or move rule 65001 up to <200, so the Health Probe will start working again, it will find a health host and start to direct 443 traffic from 131.107.100.50 to it. App1 is alive!

bobothewisemanOption: B

Network interface is not attached. It means the vm is currenltly i stopped state

Tayhull2023Option: A

Okay so the answer of the load balancer needing to be at priority 150 / allow makes sense to me except that the deny is only for 443, couldn't the load balancer just be using 80? This question has me stumped even after reading all the references.

Alex1184Option: B

It specifies the Load Balancer rules have been created correctly. Part of the set-up of rule 100 would be to specify the Health Probe...so rule 200 cannot be blocking it. I think the answer here must be No, certainly creating a rule that allows all Traffic makes no sense, when Rule 100 appears to do what you need....

87dffd4Option: B

Suggested solution reads "....and has a cost of 150". There is no concept of cost, only concept of priority. Therefore the correct answer is 'No'.

VICEROYOption: A

add a higher priority for loadbalancer

CharlesS76Option: B

NIC is not attached to the VM, answer is B!

aikoooOption: A

I think answer is A

BlueeeOption: A

A is correct, as rules at from top down and it will hit the allowed rule (150) and exit, before hitting the deny (200)

belyoOption: A

funniest part is default rule 65001 AllowAzureLoadBalancerInBound does the same job, however you cannot change the priority or delete it, so it renders it useless... so described proposal should work technically also deleting the rule with 200 priority should also work [this answer come in earlier in question set]

amsiosoOption: A

YES Azure Load Balancer probes: Allow incoming traffic from the source as the AzureLoadBalancer service tag. This rule is created by default for NSGs. You must not override it with a manual Deny rule to ensure smooth operations of your application gateway. https://learn.microsoft.com/en-us/azure/application-gateway/configuration-infrastructure#inbound-rules

nchebbiOption: A

From the exibit we can see that the NSG is applied only to the subnet (it's not applied to none of the network interfaces of VM1 nor VM2). 1. the first rule is required for standard LB as they are closed by default in order to allow traffic to flow to the backend pool resources, unless you have NSG on the VM NIC or subnet. (basic SKU is open by default.) See Ref1 Standard SKU should be used, as Basic SKUis tipycally for testing ONLY, see Ref1. 2. The security rule we add is allow the LoadBalancer to check the health of theVMs, the LB is marking them as unhealthy, though not sending traffic to them, that's why it's failing.See Ref2 Ref1: https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-load-balancer-security-baseline Ref2: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview#probe-source-ip-address

nchebbi

From Ref1: " The Standard Load Balancer is designed to be secure by default and part of a private and isolated Virtual Network. It is closed to inbound flows unless opened by network security groups to explicitly permit allowed traffic, and to disallow known malicious IP addresses. Unless a network security group on a subnet or NIC of your virtual machine resource exists behind the Load Balancer, traffic is not allowed to reach this resource." Ref1: "Note: Using a Standard Load Balancer is recommended for your production workloads and typically the Basic Load Balancer is only used for testing since the basic type is open to connections from the internet by default and doesn't require network security groups for operation."

MOSES3009Option: A

traffic flow => IP 131.107.100.50 -> LB (whatever IPs) -> Servers IPs. Rule 1 take care on first half of the flow. Rule 2 denied second half of the flow. This is why is required one rule between 1 and 2, as an exception if you want, that will allow second half of the flow = one rule to allow access from LB to server/s.