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

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 delete the BlockAllOther443 inbound security rule.

Does this meet the goal?

    Correct Answer: A

    The issue arises because the 'BlockAllOther443' rule with priority 200 is blocking traffic on TCP port 443, despite the existence of an 'Allow_131.107.100.50' rule with priority 100 that should allow the traffic. By deleting the 'BlockAllOther443' rule, traffic from 131.107.100.50 on port 443 will no longer be blocked. Additionally, the 'AllowAzureLoadBalancerInbound' rule with priority 65001 will allow traffic from the Azure Load Balancer, resolving the issue. Thus, deleting the 'BlockAllOther443' rule will ensure that connections to App1 can be successfully established from 131.107.100.50 over TCP port 443.

Discussion
mlantonisOption: B

Correct Answer: B - No Allow_131.107.100.50 rule has a higher priority (100) than BlockAllOther441 (200) and it allows inbound traffic over TCP 443 from source 131.107.100.50. App1 (VM1 and VM2) is in a VNet, so this rule applies. Unfortunately, we still cannot access App1, so the issue is somewhere else, maybe the VMs are off, or the firewall is blocking it.

mlantonis

It's a tricky question. It might also be YES. The Load Balancer backend pool VMs may not be responding to the probes due to any of the following reasons: - Load Balancer backend pool VM is unhealthy. - Load Balancer backend pool VM is not listening on the probe port. - Firewall, or a network security group is blocking the port on the Load Balancer backend pool VMs. - Other misconfigurations in Load Balancer. Note: Check if a Deny All network security groups rule on the NIC of the VM or the subnet that has a higher priority than the default rule that allows LB probes & traffic (network security groups must allow Load Balancer IP of 168.63.129.16). Reference: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-troubleshoot-health-probe-status

klexams

The communication on these ports with 168.63.129.16 is not subject to the configured network security groups. So answer is No. Dont worry about 168.63.129.16. https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16

alexander_890512

Hello guys, the NIC is not attached to any vm, look at the attach options.

pcfixok

You're right! So simple!

Nighty470

'Detach..' being grayed out only means that the VM has only one NIC attached, which cannot be removed for obvious reason. 'Attach..' being active means that the VM is not running.

alexandrud

This question was in my exam today, and I specifically looked at the "Attach network interface" button and it was grayed out (not enabled like in this screenshot). Creating the Allow inbound from the LB may fix the issue. This was my answer for that question today and I scored 909. Not sure if it was the correct answer though, but here I think it is still NO.

kansaj

also the destination is for virtual network only so its doesn't matter still wouldn't work

Goofer

Answer should be A (yes) I think. Because deleting rule BlockAllOther443, would cause default rule 65001 to allow the traffic from the loadbalancer reach VM1/VM2

MoyuihftgOption: A

Answer should be A (yes) I think. Because deleting rule BlockAllOther441, would cause default rule 65001 to allow the traffic from the loadbalancer reach VM1/VM2

cyna58

I think B is correct as Allow_131.107.100.50 rule has higher priority

ScreamingHand

An active "Attach network interface" suggests that VM2 is not running.

itgg11

I think you are spot on. the VM is off. Answer: B

rupayan87

but VM1 may be running. The NSG is tied to subnet

garmatey

omg thank you, ive been looking through the comments of all three of these questions looking for this answer

Lkk51

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

rawrkadia

You could be right, its hard to tell (insufficient info). That rule could be blocking health probes as explained in a later discussion in the series. It could also be that its off or something else blocking the connection.

rimvydukasOption: A

Ok, lets dig in :) Rule with prio 100 allows required traffic from required IP but the App1 still is not working. Why? Because of the rule with prio 200. Why? Because as we can see from the rules - App1 is on 443 port. So most likely health probes are also configured against this port and these health probes are blocked with rule with prio 200. LB thinks that VMs are not active and does not send the traffic to these VMs. When we'll delete this rule, health probes will start to work because of rule with prio 65001 and everything will start to work again:) And one more thing, maybe not so important in this case. "Attach Network Interface" button is active, so VM2 is probably powered off. But we still have VM1 left in any case :)

hidefo6963

in a lab starting a VM really makes the "Attach..." button inactive

garmateyOption: A

Traffic from 131.107.100.50 over TCP port 443 is allowed, however, to get to app1 the traffic must go through the LB, which is being blocked by the "Blockallother443" rule. Is any of this incorrect?

3GS

Correct. correct answer is Yes. You can see more clearly in Question #132 (Topic 5)

RandomNickname

Yea. If LB health probe is down not traffic will pass.

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!

WuhaoOption: A

allow the LB to health probe

krzysiekr

"Attach network interface" Button is enabled! That means, VM is Stopped and deallocated!" Copied from another.

BrkyUluknOption: A

Correct Answer: A There is a rule 65001 that allows the LB to access VMs, and the rule 200 blocks it for port 443. Most probably the NSG2 is shared between Vm1 and Vm2. The active button "Attach Network Interface" indicates VM2 is stopped, but nothing is known about VM1 which is supposed to be able to accept connections. Reference: https://fastreroute.com/azure-network-security-groups-explained/

adilkhanOption: A

YES is correct and make sense! Based on the provided network security group (NSG) rules for VM2, let's analyze the rules and their priority: Allow_131.107.100.50: Priority 100, allows traffic from 131.107.100.50 on TCP port 443. BlockAllOther443: Priority 200, blocks traffic on TCP port 443 from any source. AllowVnetInbound: Priority 65000, allows traffic from the virtual network. AllowAzureLoadBalancerInbound: Priority 65001, allows traffic from Azure Load Balancer. DenyAllInbound: Priority 65500, denies all inbound traffic. The reason connections from 131.107.100.50 over TCP port 443 are failing is because of the BlockAllOther443 rule with priority 200, which blocks all traffic on port 443 except for the specific allow rule with priority 100. By deleting the BlockAllOther443 rule, you will allow the previously specified allow rule (priority 100) to take effect, thus permitting traffic from 131.107.100.50 on port 443.

bobothewisemanOption: B

No! You need to attached network interface

tashakoriOption: A

Yes is correct

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). Standard SKU must be used, Basic SKU is typically for testing ONLY, see Ref1 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.) Ref1 2. The security rule we remove will 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.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

Flow 131.107.100.50 -> LB -> servers. Deleting the rule will allow second half of the flow. So, it solve the problem.

JD908Option: B

Question literally says "You verify that the Load Balancer rules are configured correctly". If its configured correctly than why would you delete one of the rules?

hidefo6963Option: A

There is a rule 65001 that allows the LB to access VMs, and the rule 200 blocks it for port 443. Most probably the NSG2 is shared between Vm1 and Vm2. The active button "Attach Network Interface" indicates VM2 is stopped, but nothing is known about VM1 which is supposed to be able to accept connections.

Josete1106Option: B

N is correct!

bsakshamOption: A

Azure evaluates network security group (NSG) rules in ascending order by priority value, with lower numbers taking precedence over higher numbers. When a traffic flow matches a rule with a deny action, the traffic is blocked and the NSG evaluation stops. Therefore, the allow rule with a priority of 100 will not be applied if there is a matching deny rule with a higher priority of 200. so First is Yes!!