Skip to main content

Technical Lab: Diagnose and Resolve Client-Side and Authentication Issues

Questions​

Question 1 — Multiple Choice​

A network team reports that users can resolve the FQDN of a private endpoint by public name, but the TCP connection fails when trying to reach the resource within the VNet. The network security group (NSG) of the subnet is configured correctly, and the Private Endpoint appears as Approved in the portal.

What is the most likely cause of the problem?

A) The private DNS is not linked to the VNet containing the client, returning the public IP instead of the private endpoint IP.

B) The A record in the Private DNS Zone points to the public IP of the service, overriding private resolution.

C) The destination service does not support Private Endpoint and is responding via Service Endpoint instead.

D) The Private Endpoint subnet NSG is blocking port 443 for the client IP.

Question 2 — Technical Scenario​

An administrator configured a Site-to-Site VPN connection between an on-premises network and an Azure VNet. The IPsec tunnel appears as Connected in the portal, but return traffic (on-premises to Azure) is not reaching the VMs. Consider the configuration below:

Local Network Gateway (on-premises):
  Address Space: 10.1.0.0/24

Azure VNet:
  Address Space: 10.2.0.0/16
  VM Subnet: 10.2.1.0/24

VM - Private IP: 10.2.1.5
VM subnet NSG: allows Any inbound from source 10.0.0.0/8

The on-premises client (IP 10.1.0.10) can ping the VM, but the VM cannot respond back. What is the most likely cause?

A) BGP is not enabled on the Virtual Network Gateway, preventing return route propagation.

B) The VM's return route is not being propagated because the subnet route table has a default route pointing to the Internet instead of the Virtual Network Gateway.

C) The subnet NSG blocks outbound traffic from the VM to prefix 10.1.0.0/24 because there is no explicit outbound rule.

D) The Local Network Gateway does not include prefix 10.2.1.0/24 in its address space, causing asymmetric drop on the Azure side.

Question 3 — True or False​

Statement: In a hub-and-spoke topology, when peering between the hub and a spoke has the Use Remote Gateways option enabled on the spoke, traffic originated from that spoke can reach on-premises networks via the hub's Virtual Network Gateway, even without any user-defined route (UDR) in the spoke subnet.

True or False?

Question 4 — Multiple Choice​

A web application hosted on an Azure VM authenticates users via Microsoft Entra ID using OAuth 2.0 flow (Authorization Code Flow). After a configuration change in the tenant, users begin receiving the AADSTS50011 error during login. The application registration in Microsoft Entra ID was not changed.

What does this error indicate and what is the correct action?

A) The access token expired; the application should implement refresh token flow to automatically renew the session.

B) The redirect URI sent in the authentication request does not match any URI registered in the application registration; the correct URI should be added to the registration.

C) The client certificate used in the confidential flow expired; a new certificate should be uploaded to the application registration.

D) The tenant was moved to a different region and the authorization endpoint should be updated to the new regional URL.

Question 5 — Technical Scenario​

A company uses Microsoft Entra Application Proxy to publish an internal application. External users report that they can successfully authenticate with Microsoft Entra ID, but receive a 502 Bad Gateway error when trying to access the application. The Application Proxy connector is installed on an on-premises server. See the environment status:

Connector: Status = Active (last heartbeat 2 minutes ago)
Internal application: URL = http://app-interno.corp.local
On-premises firewall rule: allows HTTPS outbound (443) to *.msappproxy.net
Internal application server: responding on port 80 internally

What is the most likely cause of the 502 error?

A) The connector cannot reach the Application Proxy service in the cloud because port 443 is blocked for the specific Microsoft Entra ID authentication endpoint.

B) The internal application URL is configured as HTTP, but the connector attempts to establish TLS connection with the internal server, resulting in handshake failure.

C) The connector is active but cannot reach the internal server app-interno.corp.local on the configured port, or the internal server is rejecting the connection.

D) The token issued by Microsoft Entra ID is valid only for the external domain and cannot be passed to the internal server via connector.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Explanation:

  • When the Private DNS Zone is not linked to the client's VNet, DNS resolution uses public servers and returns the service's public IP. The client establishes the TCP session toward the public IP, which is not routable within the VNet to the Private Endpoint. This is why resolution works (returns something) but the TCP connection fails.
  • Alternative B describes an impossible situation: A records in Private DNS Zones are automatically created with the private IP, not with the public IP.
  • Alternative D is ruled out because the statement affirms the NSG is correct; furthermore, NSGs do not block outbound traffic from the client subnet in this flow.
  • Key point: the "Approved" status of the Private Endpoint confirms the resource was provisioned correctly; the problem is exclusively in the DNS resolution plane, not in the endpoint data plane.

Answer Key — Question 2​

Answer: B

Explanation:

  • Inbound traffic (on-premises to Azure) arrives because the on-premises routing knows prefix 10.2.0.0/16. Return traffic from the VM (10.2.1.5 to 10.1.0.10) needs a route pointing to the Virtual Network Gateway. If a UDR with default route 0.0.0.0/0 pointing to the Internet is associated with the subnet, it takes precedence over system routes, and the return packet is sent to the Internet instead of the VPN tunnel, causing asymmetric drop.
  • Alternative A is incorrect: BGP is necessary for dynamic route propagation, but static routes configured in the Local Network Gateway are sufficient for the tunnel to work. The statement does not indicate BGP absence as a factor.
  • Alternative C is wrong: Azure NSGs allow all outbound traffic by default; the absence of explicit outbound rule does not cause blocking.
  • Alternative D would reverse the symptom: if the Local Network Gateway did not know the VM prefix, inbound traffic would also fail.

Answer Key — Question 3​

Answer: True

Explanation:

  • When Use Remote Gateways is enabled on the spoke and Allow Gateway Transit is enabled on the hub, Azure automatically injects routes learned by the gateway (including on-premises routes via BGP or static routes from the Local Network Gateway) into the effective route table of the spoke subnets.
  • This behavior is managed by the Azure control plane; no UDR is needed on the spoke for traffic to be forwarded through the hub gateway.
  • The common misconception is believing that UDRs are always necessary to force routing through the gateway. In this specific case, the gateway transit mechanism resolves routing automatically.
  • Important limitation: this only works if peering is direct between the spoke and the hub containing the gateway; transitive peerings (spoke-A to spoke-B via hub) do not propagate routes automatically.

Answer Key — Question 4​

Answer: B

Explanation:

  • Error AADSTS50011 is specific to Microsoft Entra ID and indicates that the Redirect URI sent in the authorization request is not registered in the application registration. This is a security measure: Microsoft Entra ID refuses tokens for unauthorized URIs, preventing open redirect attacks.
  • The statement mentions "tenant configuration change" without altering the application registration. This suggests something external changed the application access URL (for example, domain change, load balancer change, or new port), generating a callback URI different from the registered one.
  • Alternative A describes error AADSTS70008 (expired token), not AADSTS50011.
  • Alternative C would describe a client credential authentication error, with a different code.
  • Alternative D is technically invalid: Microsoft Entra ID does not use distinct regional endpoints for authentication.

Answer Key — Question 5​

Answer: C

Explanation:

  • The Application Proxy flow has two independent segments: (1) external user to Microsoft's cloud service, and (2) the on-premises connector to the internal server. The 502 Bad Gateway error occurs in the second segment: the connector is active and reaches the cloud (confirmed by heartbeat), but fails when trying to reach app-interno.corp.local. Typical causes are: internal DNS resolution failing for that FQDN, internal server down, or internal firewall blocking the connection from the connector server to the application server.
  • Alternative A is wrong: the firewall rule allows outbound on port 443 to *.msappproxy.net, and the active heartbeat confirms this communication is working.
  • Alternative B describes a real error scenario, but Application Proxy supports internal HTTP URLs without requiring TLS between connector and internal server; TLS is terminated at the cloud service.
  • Alternative D is incorrect: the connector does not pass the user token to the internal server in the default model without delegated authentication (Kerberos Constrained Delegation); authentication with the internal server is a separate process.