Design identity, governance, and monitoring solutions →hardMultiple ChoiceObjective-mapped

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Refer to the exhibit.
{
  "type": "Microsoft.Network/networkWatchers/connectionMonitors",
  "apiVersion": "2022-01-01",
  "properties": {
    "endpoints": [
      {
        "name": "sourceVM",
        "resourceId": "/subscriptions/123/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm1"
      },
      {
        "name": "destinationVM",
        "resourceId": "/subscriptions/123/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm2",
        "address": "10.0.1.4"
      }
    ],
    "testConfigurations": [
      {
        "name": "TCPTest",
        "protocol": "TCP",
        "tcpConfiguration": {
          "port": 443
        }
      }
    ],
    "testGroups": [
      {
        "name": "TestGroup1",
        "disable": false,
        "sources": ["sourceVM"],
        "destinations": ["destinationVM"],
        "testConfigurations": ["TCPTest"]
      }
    ]
  }
}

Refer to the exhibit. You deploy this Azure Network Watcher connection monitor to test TCP connectivity on port 443 between two VMs. The test consistently shows 'Unreachable' status. Both VMs are running and have correct NSG rules allowing inbound port 443 from the source VM's IP. What is the most likely cause?

⚠ Common exam trap

A common mix-up: candidates assume NSG rules are the sole cause of connectivity failures, overlooking the prerequisite that the Network Watcher Agent must be installed on both VMs for connection monitor to function.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The source VM does not have the Network Watcher Agent installed.

Azure Network Watcher connection monitor relies on the Network Watcher Agent extension installed on both source and destination VMs to collect and report connectivity data. Without the agent on the source VM, the test cannot initiate the TCP probes, resulting in a persistent 'Unreachable' status regardless of NSG rules or VM health.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The source VM does not have the Network Watcher Agent installed.
Why this is correct
Connection Monitor relies on the Network Watcher Agent (AzureNetworkWatcherExtension) installed in the source VM's guest OS to originate synthetic probe traffic. Without that agent, the monitor cannot even send TCP 443 tests to the destination, so the probe results will show 'unreachable' regardless of how permissive the NSGs or route tables are. The exhibit confirms all NSG rules are correct, so a missing source agent is the definitive root cause.
✗
The destination VM's NSG is blocking the traffic despite the rule.
Why it's wrong here
If the destination NSG were blocking the traffic, inbound TCP 443 packets would be dropped at the subnet/VM network interface before reaching the guest OS, causing the connection monitor to report a failure with a 'SecurityRule' reason. However, the exhibit explicitly shows the NSG rules are correct and in the right priority (allow inbound 443), so an invalid/blocking NSG rule cannot explain the problem. NSG misconfiguration is a common Network Watcher diagnostic finding, but it is ruled out here because the observed rules already permit the traffic.
✗
The destination VM's private IP address is incorrect.
Why it's wrong here
The destination VM's private IP address is a mandatory parameter in the connection monitor test configuration, and if that IP were wrong the monitor would probe an unrelated—or nonexistent—host, producing an 'InvalidEndpoint' or timeout error. The exhibit provides the VM's private IP and confirms it matches the target VM's NIC, so addressing is not the source of the failure. A typo in the IP address would generate a different symptom (no response from the intended host) than the generic agent-related failure described.
✗
A firewall on the destination VM is blocking TCP port 443.
Why it's wrong here
A host-level firewall such as Windows Firewall or iptables on the destination VM could block TCP 443 even when the Azure NSG permits it, because that firewall filters traffic after the packet reaches the VM's OS network stack. The problem statement gives no indication of an OS firewall rule, and the more fundamental cause is that the source VM has no Network Watcher Agent to send any test traffic at all—so the destination firewall would not even see a probe. Without evidence of a host firewall, and with the source agent missing, this option remains an unsupported distraction rather than the actual root cause.

Visual reference

Go deeper

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question