Microsoft AZ-720 Practice Test - Questions Answers, Page 3

Location in Azure: B. Get-AzVirtualNetworkGateway

Location on Client Computer: D. ipconfig /all

Explanation:

To troubleshoot the issues reported by User1, you need to use the Get-AzVirtualNetworkGateway PowerShell cmdlet in Azure and the ipconfig /all command on the client computer. The GetAzVirtualNetworkGateway

cmdlet returns information about the virtual network gateways in a subscription or a resource group. You can use this cmdlet to verify the status and configuration of the VNetGW virtual network gateway, which provides point-to-site VPN connectivity for User1. The ipconfig /all command displays the IP configuration information for all network adapters on the client computer. You can use this command to check the IP address, subnet mask, default gateway, and

DNS servers assigned to User1 when connected to the point-to-site VPN. This can help you identify any misconfiguration or connectivity issues that affect User1’s access to Azure resources.

Audit Logs

Azure AD connect logs

To resolve the problem reported by User2, you need to assign an Azure AD Premium P1 license to User2. User2 is a member of the warehouse group, which is enabled for the self-service password reset (SSPR) feature. However, User2 cannot register for SSPR because they do not have a valid license that supports SSPR. To use SSPR, a user must have one of the following licenses: Azure AD Premium P1, Azure AD Premium P2, Enterprise Mobility + Security (EMS) E3 or EMS E5. By assigning an Azure AD Premium P1 license to User2, you can enable them to use the SSPR feature and reset their password without contacting the helpdesk

The proposed solution of configuring a route table with route propagation disabled will not meet the goal of making the new subnet unreachable from the on-premises network. Route tables in Azure are used to control traffic flow within a virtual network and between virtual networks. By default, each subnet in an Azure virtual network is associated with a system-generated route table, which contains a default route that enables traffic to flow to and from all the subnets within the virtual network.

Disabling route propagation in a custom route table would prevent any new routes from being propagated to the associated subnets. However, it would not prevent traffic from the on-premises network from reaching the new subnet since traffic between the virtual network and the onpremises network would still use the default route in the system-generated route table. To meet the goal of making the new subnet unreachable from the on-premises network, you would need to create a new route table with a route that sends traffic destined for the new subnet to a null interface. This would cause the traffic to be dropped and the subnet to be effectively unreachable from the on-premises network.

Reference:

Microsoft documentation on how to create a custom route table and associate it with a subnet:

https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table#create-a-customroute-table. Microsoft documentation on how to configure a route to a null interface:

https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal#toroute-to-a-null-interface.

Disabling peering on the virtual network will not prevent the on-premises network from reaching the new subnet. Virtual network peering is a way to connect virtual networks and allows resources in both virtual networks to communicate with each other securely. It does not affect connectivity between on-premises and virtual network resources. A better solution would be to create a network security group (NSG) and associate it with the new subnet. The NSG can be configured to deny traffic from the on-premises network to the new subnet. This way, the new subnet will be isolated from the on-premises network.

Reference:

Azure Virtual Network peering: https://docs.microsoft.com/en-us/azure/virtual-network/virtualnetwork-peering-overviewAzure Network Security Groups: https://docs.microsoft.com/en-us/azure/virtual-network/networksecurity-groups-overview

Scaling the gateway to Generation2 will not prevent the on-premises network from reaching the new subnet. Scaling the gateway changes the hardware configuration of the VPN gateway, but it does not affect the routing or connectivity between the on-premises network and the virtual network.

A better solution would be to create a network security group (NSG) and associate it with the new subnet. The NSG can be configured to deny traffic from the on-premises network to the new subnet. This way, the new subnet will be isolated from the on-premises network.

Reference:

VPN Gateway Generation 2: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gatewayabout-vpngateways#gwgen2

The proposed solution, which is to configure subnet delegation, does not meet the goal of making the new subnet unreachable from the on-premises network. Subnet delegation is a mechanism to delegate management of a subnet to another resource such as a Network Virtual Appliance or a Service Endpoint. It does not provide any means to restrict or isolate a subnet from the rest of the network. To meet the goal, you can use Network Security Groups (NSGs) to restrict traffic to and from the new subnet. NSGs allow you to define inbound and outbound security rules that specify the type of traffic that is allowed or denied based on different criteria such as source or destination IP address, protocol, port number, etc. By creating a custom NSG and defining rules that deny traffic to and from the new subnet, you can effectively make that subnet unreachable from the on-premises network.

Therefore, the correct answer is option B, "No".

Reference:

https://docs.microsoft.com/en-us/azure/virtual-network/security-overview

https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview

No, restarting the Azure AD Connect service would not resolve the issue described in the scenario.

The error message "Error getting auth token" indicates there is a problem with authentication , which is preventing password writeback from being enabled during the Azure AD Connect configuration. To resolve this issue, you should first confirm that the Azure AD Connect server can authenticate to the Azure AD tenant by using a valid set of credentials. If authentication is successful, then you can investigate other possible causes such as network connectivity issues, misconfigured firewall rules, expired certificates, etc.

Therefore, the correct answer is option B, "No".

Reference:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-authentication

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-passwordwriteback#troubleshooting-steps