Review Mode Set 3 – AZ-104 Azure Administrator Question 15

[Mohamed Ben Abdeljelil]

Hello,
I think there may be an issue with the explanation provided in this scenario.

From the information given:

1. <strong data-start=”255″ data-end=”311″>“Traffic to TD1 is restricted by TDNSG1” → Incorrect<br data-start=”311″ data-end=”314″> The inbound rules of TDNSG1 all target <code data-start=”356″ data-end=”369″>10.0.2.0/24which means they filter traffic destined for TD2, not TD1. Therefore, TDNSG1 cannot be restricting traffic to TD1.

2. <strong data-start=”492″ data-end=”551″>“TD1 and TD2 are in the same virtual network” → Correct<br data-start=”551″ data-end=”554″> The ICMP test shows that TD1 can ping TD2 without any additional inbound rule. This is explained by the default NSG rule <code data-start=”678″ data-end=”696″>AllowVNetInBound which confirms that both VMs are in the same VNet.

3. <strong data-start=”755″ data-end=”818″>“TDNSG1 is associated with the NIC of TD2” → Not conclusive<br data-start=”818″ data-end=”821″> The fact that the rules are written for the destination <code data-start=”880″ data-end=”893″>10.0.2.0/24 only shows the <em data-start=”909″ data-end=”920″>intention to filter traffic to TD2. However, there is no evidence that TDNSG1 is actually associated with the NIC (or subnet) of TD2.

   <ul data-start=”1050″ data-end=”1473″>

4. The TCP test on port 443 being unreachable does not prove an NSG block, because rule 300 already allows TCP from <code data-start=”1165″ data-end=”1178″>10.0.1.0/24 to <code data-start=”1182″ data-end=”1195″>10.0.2.0/24The deny rule with priority 310 would not be processed. The failure is most likely due to the VM itself not listening on port 443.

5. Network Watcher’s <strong data-start=”1353″ data-end=”1380″>Connection Troubleshoot does not reveal NSG associations; it only shows if the connection is reachable or blocked.

👉 For this reason, I believe it is not accurate to conclude that <em data-start=”1541″ data-end=”1585″>“TDNSG1 is associated with the NIC of TD2” based solely on the tests shown.

[JR-TutorialsDojo]

Hi Mohamed Ben Abdeljelil,

Thanks for the feedback.

You’ve raised a fair point about the limitations of what Network Watcher’s Connection Troubleshoot can reveal, and you’re absolutely right that it doesn’t explicitly show NSG associations. However, in the context of this scenario, which is designed to simulate an exam-style question, the goal is to assess your ability to infer the most likely configuration based on the clues provided, not to confirm every detail with full diagnostic output.

The scenario clearly states that TDNSG1 was created and configured with inbound rules targeting 10.0.2.0/24, which is the subnet TD2 is connected to. That’s a strong indicator that TDNSG1 is intended to filter traffic to TD2. If it were associated with TD1, those rules wouldn’t apply, since the destination wouldn’t match.

Additionally, the ICMP test succeeds and the TCP 443 test fails, which aligns with the NSG allowing traffic and the fact that ICMP is explicitly allowed in TD2’s Windows firewall. These behavioral clues support the conclusion that TDNSG1 is associated with TD2.

While we understand the desire for more explicit evidence, the scenario is intentionally scoped to test reasoning based on available information. In that context, concluding that TDNSG1 is associated with TD2’s NIC or subnet is both reasonable and aligned with the configuration details provided.

Take note that there are questions in the actual Azure exam that are difficult, tricky, and ambiguous. You have to be prepared to look for specific keywords or key phrases in order to find the most suitable answer. This is the style that we are trying to mimic in our practice tests. Some of the questions do not explicitly show the obvious keywords or phrases that will easily point to the answer.

Hope this helps! Let us know if you need further assistance.

Best regards,
JR @ Tutorials Dojo