AZ-720: Troubleshooting Microsoft Azure Connectivity

Explanation:

To resolve the issue with VM10, you need to remove the inbound security rule that has a priority of 100 in NSG10, which is blocking ICMP traffic from ASG1 to ASG10. The rule has a source of Any, a destination of VirtualNetwork, a protocol of ICMP, and an action of Deny. This means that any ICMP traffic from outside the VNet4 address space will be denied by NSG10, which is attached to subnet4.

This prevents VM1 from pinging VM10 by using ICMP, as VM1 is in VNet1 and not in VNet4. By removing this rule, you can allow ICMP traffic from ASG1 to ASG10, as there is no other rule in NSG10 that explicitly denies it. Alternatively, you could also modify the rule to change the source to VirtualNetwork or the action to Allow, but removing the rule is simpler and more effective.

To resolve the certificate mismatch error, you should reissue the client certificate with client authentication enabled. According to 1, when you use Azure certificate for authentication type on point-to-site VPN connections, you need to ensure that your client certificates have client authentication as one of their enhanced key usage attributes. Otherwise, you will receive a certificate mismatch error when connecting by using a VPN client.

It is unlikely that configuring the retention range for the current VM backup policy would resolve the issue of the Azure VM backup job failing after enabling backups for the VM through the Azure portal. To troubleshoot the issue, the administrator should first check the Azure VM backup job logs and identify the specific error message or code provided. This can help identify the underlying issue and the appropriate solution. Therefore, the solution mentioned in the question is incorrect and the answer is B. No.

Reference:

Troubleshoot Azure VM backup failures (Microsoft documentation)

To resolve the issue reported by Admin2, you need to disassociate NSG5 from NIC4, which is the network interface of VM4. NSG5 is a network security group that has an inbound security rule that denies traffic from ASG2 to ASG5 over port 80. This rule prevents Admin2 from connecting to the web server public IP address on VM4 from VM2, as VM2 is in ASG2 and VM4 is in ASG5. By disassociating NSG5 from NIC4, you can remove the rule that blocks the traffic and allow Admin2 to access the web server on VM4. Alternatively, you could also modify or remove the rule in NSG5, but disassociating NSG5 from NIC4 is simpler and more effective.

To resolve the VM2 routing issue, you should modify the IP configuration setting of the Azure network interface resource of VM2. This will ensure that VM2 can communicate with other resources in the virtual network. Troubleshooting connectivity problems between Azure VMs involves several steps such as checking whether NIC is misconfigured, whether network traffic is blocked by NSG or UDR, whether network traffic is blocked by VM firewall, whether VM app or service is listening on the port and whether the problem is caused by SNAT1.

Topic 2, Misc. Questions Set

This will ensure that the route table RT12, which has a route to direct internet traffic to the virtual network gateway VNG1, is applied to the subnet where VM1 is located. This will override the default route that sends internet traffic to the internet gateway.

Box 1: Assign the Contributor role to the team members.

In the given scenario, the team members are unable to create or manage resources in the Azure portal. To allow them to do so, you should assign the Contributor role to the team members. The Contributor role allows users to create and manage resources within the scope of their access, but they cannot grant access to others. The Reader role only provides read access to resources and does not allow creation or management of resources. The Reader and Data Access role is not a valid combined role in Azure. Reference: - Azure built-in roles: https://docs.microsoft.com/enus/ azure/role-based-access-control/built-in-roles As mentioned in the scenario, the team members are unable to create resources in Azure Portal. This indicates that they do not have sufficient permissions to perform this operation. To grant them permissions, you need to assign them an Azure role that allows creating and managing Azure resources. Azure roles are roles that can be assigned to users, groups, or applications to manage access to Azure resources1. Azure roles are based on Azure role-based access control (Azure RBAC), which is an authorization system that provides fine-grained access management of Azure resources2. With Azure RBAC, you can control access to resources by creating role assignments, which consist of three elements2:

The security principal: The user, group, or application that you want to grant or deny access to the resource. The role definition: The predefined or custom set of permissions that you want to grant or deny on the resource. For example, read, write, delete, backup, restore, etc. The scope: The level at which you want to apply the role assignment. For example, at the management group, subscription, resource group, or individual resource level. To assign an Azure role that allows creating and managing Azure resources, you can use the Contributor role. The Contributor role is a built-in role that has full access to all resources except granting access to others1. This means that users who are assigned the Contributor role can create and manage any type of Azure resource, such as virtual machines, storage accounts, web apps, etc. To assign the Contributor role using the Azure portal, follow these steps3:

In the Azure portal, navigate to the scope where you want to assign the role. For example, a subscription or a resource group. Select Access control (IAM), then select Add > Add role assignment.

Under Role, select Contributor from the drop-down list.

Under Assign access to, select User, group, or service principal.

Under Select, find and select the users or groups that you want to assign the role to. You can type in the Select box to search the directory for display name or email address. Select Save to create the role assignment.

To assign the Contributor role using the Azure CLI or PowerShell, see Assign Azure roles using CLI or PowerShell.

Box 2: Assign the Storage Blob Data Contributor role to the team members.

A detailed explanation with references is as follows:

As mentioned in the scenario, the team members are unable to perform backups and restores of blob dat a. This indicates that they do not have sufficient permissions to access blob storage resources. To grant them permissions, you need to assign them an Azure role that allows read/write/delete permissions to blob storage resources.

Azure roles are roles that can be assigned to users, groups, or applications to manage access to Azure resources2. Azure roles are based on Azure role-based access control (Azure RBAC), which is an authorization system that provides fine-grained access management of Azure resources3. With Azure RBAC, you can control access to resources by creating role assignments, which consist of three elements3:

The security principal: The user, group, or application that you want to grant or deny access to the resource. The role definition: The predefined or custom set of permissions that you want to grant or deny on the resource. For example, read, write, delete, backup, restore, etc. The scope: The level at which you want to apply the role assignment. For example, at the management group, subscription, resource group, or individual resource level. To assign an Azure role that allows read/write/delete permissions to blob storage resources, you can use the Storage Blob Data Contributor role. The Storage Blob Data Contributor role is a built-in role that has full access to blob storage resources except granting access to others1. This means that users who are assigned the Storage Blob Data Contributor role can perform backups and restores of blob data. To assign the Storage Blob Data Contributor role using the Azure portal, follow these steps4:

In the Azure portal, navigate to the scope where you want to assign the role. For example, a storage account or a container. Select Access control (IAM), then select Add > Add role assignment.

Under Role, select Storage Blob Data Contributor from the drop-down list.

Under Assign access to, select User, group, or service principal.

Under Select, find and select the users or groups that you want to assign the role to. You can type in the Select box to search the directory for display name or email address. Select Save to create the role assignment.

To assign the Storage Blob Data Contributor role using the Azure CLI or PowerShell, see Assign Azure roles using CLI or PowerShell.

Box 1: Configure service endpoint for subnet on VNet2 and VNet3.

This is what you should do to resolve issues accessing contosostorage1 from VNet2 and VNet3. A service endpoint is a feature that enables you to secure your Azure Storage account to a specific virtual network subnet1. As mentioned in the scenario, contosostorage1 is a storage account that has firewall and virtual network settings enabled. This means that only requests from allowed networks can access the storage account2. By default, storage accounts accept connections from clients on any network, but you can configure firewall rules to allow or deny access based on the source IP address or virtual network subnet2. In this scenario, you want to allow access to contosostorage1 from VNet2 and VNet3, which are peered with VNet1. To do this, you need to configure service endpoints for the subnets on VNet2 and VNet3 that need to access the storage account1. A service endpoint is a feature that enables you to secure your Azure Storage account to a specific virtual network subnet1. When you enable a service endpoint for a subnet, you can then grant access to the storage account only from that subnet1. This way, you can restrict access to your storage account and improve network performance by routing traffic through an optimal path. To configure service endpoints for a subnet using the Azure portal, follow these steps1:

In the Azure portal, navigate to the Virtual Network resource.

Select Subnets, then select the subnet that needs to access the storage account.

Under Service endpoints, select Microsoft.Storage from the drop-down list.

Select Save to apply the changes.

To configure service endpoints for a subnet using the Azure CLI or PowerShell, see Enable a service endpoint. After configuring service endpoints for the subnets on VNet2 and VNet3, you also need to grant access to contosostorage1 from those subnets. To do this, you need to modify the firewall rules on the storage account2. To modify the firewall rules on the storage account using the Azure portal, follow these steps2:

In the Azure portal, navigate to the Storage Account resource.

Select Firewalls and virtual networks under Settings.

Under Allow access from selected networks, select Add existing virtual network.

Select the virtual network and subnet that have service endpoints enabled for Microsoft.Storage.

Select Add to save the changes.

To modify the firewall rules on the storage account using the Azure CLI or PowerShell, see Configure Azure Storage firewalls and virtual networks.

Box 2: Configure the firewall settings on contosostorage1.

The issue reported is that on-premises connections to contosostorage1 are unsuccessful. The main reason for this could be that the firewall settings on the storage account are blocking the connections. By configuring the firewall settings on contosostorage1 to allow the on-premises IP addresses, you can ensure that the on-premises connections are successful.

As mentioned in the scenario, contosostorage1 is a storage account that has firewall and virtual network settings enabled. This means that only requests from allowed networks can access the storage account1. By default, storage accounts accept connections from clients on any network, but you can configure firewall rules to allow or deny access based on the source IP address or virtual network subnet1. In this scenario, you want to allow access to contosostorage1 from the on-premises environment, which is connected to Azure using a Site-to-Site VPN connection. A Site-to-Site VPN connection lets you create a secure connection between your on-premises network and an Azure virtual network over an IPsec/IKE VPN tunnel2. To allow access to contosostorage1 from the on-premises environment, you need to configure the firewall settings on contosostorage1 to include the public IP address of your VPN device or gateway3.

To configure the firewall settings on contosostorage1 using the Azure portal, follow these steps1:

In the Azure portal, navigate to the Storage Account resource.

Select Firewalls and virtual networks under Settings.

Under Allow access from selected networks, select Add existing virtual network.

Select VNet1 and the subnet that has service endpoints enabled for Microsoft.Storage.

Under Firewall, enter the public IP address of your VPN device or gateway under Address Range.

Select Save to apply the changes.

To configure the firewall settings on contosostorage1 using the Azure CLI or PowerShell, see Configure Azure Storage firewalls and virtual networks.