Troubleshooting practice questions

You are troubleshooting an issue where users are unable to access a sensitive application protected by a Conditional Access policy. The policy requires MFA from trusted locations, but users are reporting that they are prompted for MFA even when connecting from the corporate office, which is defined as a trusted location. What is the most likely cause?

Trap 1: The policy is configured to require MFA for all locations…

If the policy were configured to require MFA for all locations regardless of trust, then users outside the office would also be challenged, but more importantly the trusted-location condition would be ignored entirely. However, the problem description indicates the policy is intended to require MFA only from outside trusted locations, so the location condition must still be scoped to trusted locations. A misconfigured 'any location' condition would produce broad MFA prompts across all networks, not a specific failure at the corporate office. Therefore, this setting does not explain the observed issue.

Trap 2: The policy is set to 'Require MFA' instead of 'Require MFA from…

There is no separate Conditional Access grant called 'Require MFA from trusted locations'; rather, an administrator uses the Locations condition to include or exclude trusted named locations and then applies a standard 'Require MFA' grant to that scope. The description in the problem states the policy requires MFA from trusted locations, meaning the administrator already scoped the location condition correctly so trusted locations are evaluated as exempt. If the grant were simply 'Require MFA' without the location exclusion, users at the office would still be prompted but only because of the missing condition, not because of the grant control name. Since the policy description already reflects the intended location-aware behavior, this option is not the root cause.

Trap 3: Users are not assigned to the policy

If users were not assigned to the Conditional Access policy, the policy would have no effect on their sign-ins, and they would not receive an MFA challenge from this policy. The fact that users are being prompted proves they are in scope—either directly, through a group, or through all users—and the policy is being evaluated. An assignment omission would cause silent success without MFA, which is the opposite of the reported symptom. Therefore, user assignment is not the cause of the MFA prompt at the corporate office.

A
The corporate office's public IP address is not correctly defined in the trusted location
A named location in Microsoft Entra ID must exactly match the current public egress IP range of the corporate network. If the range is stale, missing, or mistakenly configured with the wrong CIDR (for example, after an ISP change or a new NAT device), the user's source IP at the office will not match the trusted location. As a result, the Conditional Access policy sees the request as coming from an untrusted network and enforces MFA even though the user is physically inside the office. Verify the public IP and CIDR range in the named location, and confirm that the office's outbound IP has not changed.
B
The policy is configured to require MFA for all locations regardless of trust
Why it fails: If the policy were configured to require MFA for all locations regardless of trust, then users outside the office would also be challenged, but more importantly the trusted-location condition would be ignored entirely. However, the problem description indicates the policy is intended to require MFA only from outside trusted locations, so the location condition must still be scoped to trusted locations. A misconfigured 'any location' condition would produce broad MFA prompts across all networks, not a specific failure at the corporate office. Therefore, this setting does not explain the observed issue.
C
The policy is set to 'Require MFA' instead of 'Require MFA from trusted locations'
Why it fails: There is no separate Conditional Access grant called 'Require MFA from trusted locations'; rather, an administrator uses the Locations condition to include or exclude trusted named locations and then applies a standard 'Require MFA' grant to that scope. The description in the problem states the policy requires MFA from trusted locations, meaning the administrator already scoped the location condition correctly so trusted locations are evaluated as exempt. If the grant were simply 'Require MFA' without the location exclusion, users at the office would still be prompted but only because of the missing condition, not because of the grant control name. Since the policy description already reflects the intended location-aware behavior, this option is not the root cause.
D
Users are not assigned to the policy
Why it fails: If users were not assigned to the Conditional Access policy, the policy would have no effect on their sign-ins, and they would not receive an MFA challenge from this policy. The fact that users are being prompted proves they are in scope—either directly, through a group, or through all users—and the policy is being evaluated. An assignment omission would cause silent success without MFA, which is the opposite of the reported symptom. Therefore, user assignment is not the cause of the MFA prompt at the corporate office.

Read the full DNS explanation →

Question 2hardmultiple choice

You are troubleshooting connectivity issues from an Azure VM to an on-premises server. The VM is in a VNet that uses a custom DNS server. The on-premises network is connected via ExpressRoute. You can ping the on-premises server by IP address but not by name. What is the most likely cause?

Trap 1: The ExpressRoute circuit is not configured for DNS forwarding.

ExpressRoute is a Layer 3 connectivity service that extends an on-premises network into Azure; it does not provide DNS resolution or DNS forwarding. DNS forwarding is a server-side function performed by a DNS resolver (e.g., the custom DNS server you configured for the virtual network). An ExpressRoute circuit only carries IP traffic—including DNS queries—but it cannot be 'configured for DNS forwarding' itself. Therefore, the issue is not a missing DNS forwarder on the circuit, but a missing conditional forwarder on your custom DNS server.

Trap 2: The Azure Private DNS zone does not include the on-premises…

Azure Private DNS zones are used to provide DNS resolution for records within a virtual network (or networks linked to the zone), such as custom domain names that you create in Azure. An on-premises hostname is not a record in any Azure Private DNS zone, and adding it there would not make your custom DNS server forward queries to the on-premises DNS. The core problem is the lack of a forwarding path from the Azure-side DNS resolver to the on-premises DNS infrastructure, not a missing zone or record in Azure. Additionally, Private DNS zones are not designed for integrating with on-premises DNS servers—that integration is done via conditional forwarders or DNS server-to-server zone transfers.

Trap 3: An NSG rule is blocking DNS traffic.

An NSG rule that blocks DNS traffic would prevent the VM from sending or receiving UDP/TCP port 53 traffic to whatever DNS server it uses. However, the symptom is that name resolution fails specifically for an on-premises hostname, while IP connectivity works—if an NSG blocked DNS, all name resolution would fail, not just for on-prem names, and you likely couldn't resolve Azure names either. Furthermore, NSGs apply to traffic entering/leaving network interfaces or subnets; they do not selectively filter which DNS names can be resolved. Since the VM can reach the on-premises host by IP, the underlying network path is fine, ruling out NSG blocking as the cause.

A
The ExpressRoute circuit is not configured for DNS forwarding.
Why it fails: ExpressRoute is a Layer 3 connectivity service that extends an on-premises network into Azure; it does not provide DNS resolution or DNS forwarding. DNS forwarding is a server-side function performed by a DNS resolver (e.g., the custom DNS server you configured for the virtual network). An ExpressRoute circuit only carries IP traffic—including DNS queries—but it cannot be 'configured for DNS forwarding' itself. Therefore, the issue is not a missing DNS forwarder on the circuit, but a missing conditional forwarder on your custom DNS server.
B
The custom DNS server does not have a conditional forwarder to the on-premises DNS.
When you set a custom DNS server on an Azure virtual network, all VMs in that network send their DNS queries to that server. Because your VM can ping the on-premises host by IP but cannot resolve its name, the custom DNS server is receiving the query but does not know where to send it. A conditional forwarder specifically forwards queries for a given on-premises domain suffix (e.g., corp.contoso.com) to the on-premises DNS server. Without this forwarder, the custom DNS server either tries to resolve the name against the internet root hints or responds with an error, failing to resolve the on-premises hostname.
C
The Azure Private DNS zone does not include the on-premises hostname.
Why it fails: Azure Private DNS zones are used to provide DNS resolution for records within a virtual network (or networks linked to the zone), such as custom domain names that you create in Azure. An on-premises hostname is not a record in any Azure Private DNS zone, and adding it there would not make your custom DNS server forward queries to the on-premises DNS. The core problem is the lack of a forwarding path from the Azure-side DNS resolver to the on-premises DNS infrastructure, not a missing zone or record in Azure. Additionally, Private DNS zones are not designed for integrating with on-premises DNS servers—that integration is done via conditional forwarders or DNS server-to-server zone transfers.
D
An NSG rule is blocking DNS traffic.
Why it fails: An NSG rule that blocks DNS traffic would prevent the VM from sending or receiving UDP/TCP port 53 traffic to whatever DNS server it uses. However, the symptom is that name resolution fails specifically for an on-premises hostname, while IP connectivity works—if an NSG blocked DNS, all name resolution would fail, not just for on-prem names, and you likely couldn't resolve Azure names either. Furthermore, NSGs apply to traffic entering/leaving network interfaces or subnets; they do not selectively filter which DNS names can be resolved. Since the VM can reach the on-premises host by IP, the underlying network path is fine, ruling out NSG blocking as the cause.

Question 3hardmultiple choice

You are troubleshooting connectivity between two Azure VMs in the same virtual network. VM1 can ping VM2, but VM1's application cannot connect to VM2's application on port 8080. Both VMs have NSGs that allow inbound traffic on port 8080. What is the most likely cause?

Trap 1: The VNet is peered with another VNet that has a conflicting address…

VNet peering address space conflicts are irrelevant here because VM1 and VM2 reside within the same VNet. Azure VNet peering is a connection between separate VNets, and any overlapping address space would only prevent peering or affect cross-VNet routing; it does not alter the built-in system routes that deliver intra-VNet traffic between two subnets in the same VNet. Thus, a conflicting peered address space cannot explain a failure to reach VM2 on port 8080.

Trap 2: An Azure Load Balancer is directing traffic away from VM2.

An Azure Load Balancer operates at Layer 4 and only handles traffic destined for its own frontend IP address and port configuration. Direct traffic from VM1 to VM2's private IP address does not traverse the load balancer, because the load balancer is not inserted into the data path for VM-to-VM communications within a VNet. Even if VM2 is in the backend pool, the load balancer only influences traffic that is explicitly sent to its frontend, so it cannot 'direct traffic away' from VM2 in this scenario.

Trap 3: The NSG on VM2's subnet has a deny rule for port 8080.

The scenario explicitly states that the NSG on VM2's subnet allows port 8080 inbound. NSGs are stateful packet filters that evaluate traffic at the subnet or NIC level, and if there were a deny rule for port 8080, it would block the connection before it ever reached the guest OS. Since no such deny rule exists (or the existing allow rule applies), the NSG is not the cause of the connectivity failure.

A
The VNet is peered with another VNet that has a conflicting address space.
Why it fails: VNet peering address space conflicts are irrelevant here because VM1 and VM2 reside within the same VNet. Azure VNet peering is a connection between separate VNets, and any overlapping address space would only prevent peering or affect cross-VNet routing; it does not alter the built-in system routes that deliver intra-VNet traffic between two subnets in the same VNet. Thus, a conflicting peered address space cannot explain a failure to reach VM2 on port 8080.
B
An Azure Load Balancer is directing traffic away from VM2.
Why it fails: An Azure Load Balancer operates at Layer 4 and only handles traffic destined for its own frontend IP address and port configuration. Direct traffic from VM1 to VM2's private IP address does not traverse the load balancer, because the load balancer is not inserted into the data path for VM-to-VM communications within a VNet. Even if VM2 is in the backend pool, the load balancer only influences traffic that is explicitly sent to its frontend, so it cannot 'direct traffic away' from VM2 in this scenario.
C
The NSG on VM2's subnet has a deny rule for port 8080.
Why it fails: The scenario explicitly states that the NSG on VM2's subnet allows port 8080 inbound. NSGs are stateful packet filters that evaluate traffic at the subnet or NIC level, and if there were a deny rule for port 8080, it would block the connection before it ever reached the guest OS. Since no such deny rule exists (or the existing allow rule applies), the NSG is not the cause of the connectivity failure.
D
The guest OS firewall on VM2 is blocking inbound port 8080.
The guest OS firewall on VM2 is a host-based firewall that filters traffic after the NSG has already permitted it and after the packet arrives at the virtual NIC. Even when network security groups explicitly allow port 8080, the OS firewall can still drop or reject the connection if there is no matching inbound allow rule or if an active deny rule is present. This is a common cause of 'connection refused' or timeout when all Azure network-level controls appear correct, making it the correct answer.

Question 4easymultiple choice

A security administrator is troubleshooting network connectivity to an Azure virtual machine. The VM is behind a network security group (NSG) that has a deny-all inbound rule as the default. The administrator wants to quickly verify whether a specific TCP packet on port 3389 from their client IP (203.0.113.50) would be allowed or blocked by the NSG. Which Azure Network Watcher tool should they use?

Trap 1: Network Performance Monitor.

Network Performance Monitor (NPM) is an Azure Monitor-based solution that measures network latency, packet loss, and topology across virtual machines, ExpressRoute, and VPN connections. It relies on agents installed on monitored endpoints to gather performance telemetry and cannot simulate a specific packet against a network security group (NSG). Therefore, while NPM helps identify degraded or failing network paths, it is not designed to validate whether a particular NSG rule permits or denies a given traffic flow, making it incorrect for this troubleshooting scenario.

Trap 2: Next hop.

The Next hop capability in Network Watcher identifies the next hop type and IP address for a packet based on the effective route table associated with a VM—for example, Internet, VirtualNetworkGateway, or a virtual appliance—but it does not inspect NSG rules. A route may correctly point to a valid next hop, yet an NSG rule can still block the traffic before it leaves the VM. Consequently, Next hop is designed for diagnosing routing issues and cannot validate the allow/deny decisions made by network security groups.

Trap 3: NSG diagnostics (flow logs).

NSG diagnostics (flow logs) continuously capture information about IP traffic flowing through an NSG, recording allow/deny outcomes, source/destination addresses, ports, and packet counts into a storage account or Log Analytics workspace for historical analysis. These logs are not interactive: they do not let you simulate an arbitrary test packet on demand and are instead analyzed after the fact using queries or network monitoring tools. Because flow logs require enabling diagnostics and waiting for data to accumulate, they are unsuitable for immediate, packet-specific NSG rule validation, unlike IP flow verify.

A
Network Performance Monitor.
Why it fails: Network Performance Monitor (NPM) is an Azure Monitor-based solution that measures network latency, packet loss, and topology across virtual machines, ExpressRoute, and VPN connections. It relies on agents installed on monitored endpoints to gather performance telemetry and cannot simulate a specific packet against a network security group (NSG). Therefore, while NPM helps identify degraded or failing network paths, it is not designed to validate whether a particular NSG rule permits or denies a given traffic flow, making it incorrect for this troubleshooting scenario.
B
IP flow verify.
IP flow verify, part of Azure Network Watcher, takes a specified protocol, source IP/port, destination IP/port, and the target virtual machine’s network interface to simulate an actual packet. The tool then evaluates the effective security rules applied at both the subnet and network interface levels and returns an allow or deny decision along with the exact rule that allowed or blocked the traffic. This makes it the correct choice for validating NSG rules because it directly answers whether a specific packet is permitted in real time.
C
Next hop.
Why it fails: The Next hop capability in Network Watcher identifies the next hop type and IP address for a packet based on the effective route table associated with a VM—for example, Internet, VirtualNetworkGateway, or a virtual appliance—but it does not inspect NSG rules. A route may correctly point to a valid next hop, yet an NSG rule can still block the traffic before it leaves the VM. Consequently, Next hop is designed for diagnosing routing issues and cannot validate the allow/deny decisions made by network security groups.
D
NSG diagnostics (flow logs).
Why it fails: NSG diagnostics (flow logs) continuously capture information about IP traffic flowing through an NSG, recording allow/deny outcomes, source/destination addresses, ports, and packet counts into a storage account or Log Analytics workspace for historical analysis. These logs are not interactive: they do not let you simulate an arbitrary test packet on demand and are instead analyzed after the fact using queries or network monitoring tools. Because flow logs require enabling diagnostics and waiting for data to accumulate, they are unsuitable for immediate, packet-specific NSG rule validation, unlike IP flow verify.

Question 5mediummultiple choice

You are troubleshooting a sign-in issue. A user reports that they are repeatedly prompted for authentication when accessing a cloud app, even though they already authenticated earlier in the day. You check the Conditional Access policy and see that 'Session control - Sign-in frequency' is set to 1 hour. What is the most likely cause?

Trap 1: The browser is blocking persistent cookies

This is incorrect because while blocking persistent cookies can affect how long a user stays signed in across browser restarts, it does not control periodic reauthentication while the session is active. Sign-in frequency is enforced by Microsoft Entra Conditional Access through token claims and policy evaluation, not by cookie storage. Even if persistent cookies are blocked, Microsoft Entra ID would still allow the session to continue until the sign-in frequency interval expires; it would not trigger a reauthentication precisely at the 1-hour mark.

Trap 2: Token lifetime policy overrides the sign-in frequency

This is incorrect because token lifetime policies determine the maximum validity of access or refresh tokens, but they do not override the Conditional Access sign-in frequency control. Sign-in frequency can force a reauthentication earlier than the token lifetime, because it is evaluated separately during each token request against the configured time window. In this scenario, the 1-hour reauthentication is the direct result of the sign-in frequency setting, not an artifact of token expiration or policy precedence.

Trap 3: The user is considered high risk by Identity Protection

This is incorrect because Identity Protection risk-based Conditional Access policies trigger only when a user's risk level is elevated, and they typically respond by requiring MFA, blocking sign-in, or requiring a password change—not by simply demanding reauthentication at a fixed interval. There is no mention of a risk detection, so attributing the prompt to risk would be unfounded. The fixed 1-hour cadence is a hallmark of sign-in frequency, not a risk-based policy.

A
The sign-in frequency setting forces reauthentication after 1 hour
This is correct because in Microsoft Entra Conditional Access, the sign-in frequency session control is configured to require the user to reauthenticate after a specified time period, here 1 hour. When that interval elapses, Microsoft Entra ID forces a fresh authentication prompt even if the user's browser session and tokens are still technically valid, so the user experiences a sign-in interruption. The setting is evaluated independently of the underlying session, which explains why the user is prompted again exactly after 1 hour.
B
The browser is blocking persistent cookies
Why it fails: This is incorrect because while blocking persistent cookies can affect how long a user stays signed in across browser restarts, it does not control periodic reauthentication while the session is active. Sign-in frequency is enforced by Microsoft Entra Conditional Access through token claims and policy evaluation, not by cookie storage. Even if persistent cookies are blocked, Microsoft Entra ID would still allow the session to continue until the sign-in frequency interval expires; it would not trigger a reauthentication precisely at the 1-hour mark.
C
Token lifetime policy overrides the sign-in frequency
Why it fails: This is incorrect because token lifetime policies determine the maximum validity of access or refresh tokens, but they do not override the Conditional Access sign-in frequency control. Sign-in frequency can force a reauthentication earlier than the token lifetime, because it is evaluated separately during each token request against the configured time window. In this scenario, the 1-hour reauthentication is the direct result of the sign-in frequency setting, not an artifact of token expiration or policy precedence.
D
The user is considered high risk by Identity Protection
Why it fails: This is incorrect because Identity Protection risk-based Conditional Access policies trigger only when a user's risk level is elevated, and they typically respond by requiring MFA, blocking sign-in, or requiring a password change—not by simply demanding reauthentication at a fixed interval. There is no mention of a risk detection, so attributing the prompt to risk would be unfounded. The fixed 1-hour cadence is a hallmark of sign-in frequency, not a risk-based policy.

Question 6easymultiple choice

You are troubleshooting why a user cannot sign in to a custom line-of-business application that is federated with Microsoft Entra ID. The user reports that they are repeatedly prompted for credentials and then receive an error. The application is configured for SAML-based SSO. What is the most likely cause?

Trap 1: The user's browser cookies are disabled

SAML SSO relies on the browser to relay messages and maintain the authentication session via cookies after redirects, so disabled cookies can interrupt the sign-in flow. However, if the certificate or metadata is invalid, the application will not accept the SAML assertion regardless of cookie state. This is a client-side condition, not the primary cause of a certificate validation or configuration error.

Trap 2: The application is not registered in the app gallery

Being absent from the Microsoft Entra ID application gallery has no bearing on sign-in, because you can register an application as a custom or non-gallery enterprise app and manually configure SAML endpoints and certificates. The gallery simply provides pre-built templates to simplify configuration. The app could still be fully functional without being listed.

Trap 3: The user does not have a license for Microsoft Entra ID

Microsoft Entra ID Free tier supports SAML-based SSO for enterprise applications, so a user does not require a Premium license to sign in. The user merely needs an active directory account that is assigned to the application. If the user lacks any Entra ID license, they may not have an identity at all, but that is different from not holding a paid license; the free tier covers this scenario.

A
The user's browser cookies are disabled
Why it fails: SAML SSO relies on the browser to relay messages and maintain the authentication session via cookies after redirects, so disabled cookies can interrupt the sign-in flow. However, if the certificate or metadata is invalid, the application will not accept the SAML assertion regardless of cookie state. This is a client-side condition, not the primary cause of a certificate validation or configuration error.
B
The application is not registered in the app gallery
Why it fails: Being absent from the Microsoft Entra ID application gallery has no bearing on sign-in, because you can register an application as a custom or non-gallery enterprise app and manually configure SAML endpoints and certificates. The gallery simply provides pre-built templates to simplify configuration. The app could still be fully functional without being listed.
C
The SAML certificate has expired or the configuration has a mismatch
SAML certificates are used to sign the SAML response; the service provider uses the certificate's public key to validate the signature. If the certificate has expired or the configured certificate doesn't match the one trusted by the application, the SP will discard the assertion and deny sign-in. Likewise, a mismatch in the SAML configuration (e.g., Entity ID, Reply URL, or signing algorithm) will cause authentication failures even when the certificate is valid.
D
The user does not have a license for Microsoft Entra ID
Why it fails: Microsoft Entra ID Free tier supports SAML-based SSO for enterprise applications, so a user does not require a Premium license to sign in. The user merely needs an active directory account that is assigned to the application. If the user lacks any Entra ID license, they may not have an identity at all, but that is different from not holding a paid license; the free tier covers this scenario.