AZ-104: Microsoft Azure Administrator
You have an Azure subscription that contains the following resources:
- A virtual network that has a subnet named Subnet1
- Two network security groups (NSGs) named NSG-VM1 and NSG-Subnet1
- A virtual machine named VM1 that has the required Windows Server configurations to allow Remote Desktop connections
NSG-Subnet1 has the default inbound security rules only.
NSG-VM1 has the default inbound security rules and the following custom inbound security rule:
- Priority: 100
- Source: Any
- Source port range: *
- Destination: *
- Destination port range: 3389
- Protocol: UDP
- Action: Allow
VM1 has a public IP address and is connected to Subnet1. NSG-VM1 is associated to the network interface of VM1. NSG-Subnet1 is associated to Subnet1.
You need to be able to establish Remote Desktop connections from the internet to VM1.
Solution: You add an inbound security rule to NSG-Subnet1 that allows connections from the Any source to the *destination for port range 3389 and uses the TCP protocol. You remove NSG-VM1 from the network interface of VM1.
Does this meet the goal?
Yes
No
Answer is Yes
By adding the rule to NSG-Subnet1 you are allowing RDP on Subnet level. Then you delete NSG-VM1, so you are able to RDP.
Note: A rule to permit RDP traffic may not be created automatically when you create your VM.
Reference:
https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/troubleshoot-rdp-connection
You have an Azure subscription that contains the following resources:
- A virtual network that has a subnet named Subnet1
- Two network security groups (NSGs) named NSG-VM1 and NSG-Subnet1
- A virtual machine named VM1 that has the required Windows Server configurations to allow Remote Desktop connections
NSG-Subnet1 has the default inbound security rules only.
NSG-VM1 has the default inbound security rules and the following custom inbound security rule:
- Priority: 100
- Source: Any
- Source port range: *
- Destination: *
- Destination port range: 3389
- Protocol: UDP
- Action: Allow
VM1 has a public IP address and is connected to Subnet1. NSG-VM1 is associated to the network interface of VM1. NSG-Subnet1 is associated to Subnet1.
You need to be able to establish Remote Desktop connections from the internet to VM1.
Solution: You add an inbound security rule to NSG-Subnet1 that allows connections from the internet source to the VirtualNetwork destination for port range 3389 and uses the UDP protocol.
Does this meet the goal?
Answer is No
The default port for RDP is TCP port 3389. A rule to permit RDP traffic must be created automatically when you create your VM.
Note on NSG-Subnet1: Azure routes network traffic between all subnets in a virtual network, by default.
Reference:
https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/troubleshoot-rdp-connection
You have an Azure subscription that contains the following resources:
- A virtual network that has a subnet named Subnet1
- Two network security groups (NSGs) named NSG-VM1 and NSG-Subnet1
- A virtual machine named VM1 that has the required Windows Server configurations to allow Remote Desktop connections
NSG-Subnet1 has the default inbound security rules only.
NSG-VM1 has the default inbound security rules and the following custom inbound security rule:
- Priority: 100
- Source: Any
- Source port range: *
- Destination: *
- Destination port range: 3389
- Protocol: UDP
- Action: Allow
VM1 has a public IP address and is connected to Subnet1. NSG-VM1 is associated to the network interface of VM1. NSG-Subnet1 is associated to Subnet1.
You need to be able to establish Remote Desktop connections from the internet to VM1.
Solution: You add an inbound security rule to NSG-Subnet1 and NSG-VM1 that allows connections from the internet source to the VirtualNetwork destination for port range 3389 and uses the TCP protocol.
Does this meet the goal?
Yes
No
Answer is Yes
RDP TCP is allowed at Subnet and on VM level NSGs.
The default port for RDP is TCP port 3389.
To enable RDP, you need to add "Allow" rule for 3389 port on TCP protocol.
Reference:
https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/troubleshoot-rdp-connection
You have a computer named Computer1 that has a point-to-site VPN connection to an Azure virtual network named VNet1. The point-to-site connection uses a self-signed certificate.
From Azure, you download and install the VPN client configuration package on a computer named Computer2.
You need to ensure that you can establish a point-to-site VPN connection to VNet1 from Computer2.
Solution: You modify the Azure Active Directory (Azure AD) authentication policies.
Does this meet the goal?
Yes
No
Answer is No
Instead export the client certificate from Computer1 and install the certificate on Computer2.
A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer. This solution is useful for telecommuters who want to connect to Azure VNets from a remote location, such as from home or a conference. P2S VPN is also a useful solution to use instead of S2S VPN when you have only a few clients that need to connect to a VNet. This article applies to the Resource Manager deployment model.
Reference:
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
You have a computer named Computer1 that has a point-to-site VPN connection to an Azure virtual network named VNet1. The point-to-site connection uses a self-signed certificate.
From Azure, you download and install the VPN client configuration package on a computer named Computer2.
You need to ensure that you can establish a point-to-site VPN connection to VNet1 from Computer2.
Solution: You join Computer2 to Azure Active Directory (Azure AD)
Does this meet the goal?
Yes
No
Answer is No
A client computer that connects to a VNet using Point-to-Site must have a client certificate installed. Instead export the client certificate from Computer1 and install the certificate on Computer2.
A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer. This solution is useful for telecommuters who want to connect to Azure VNets from a remote location, such as from home or a conference. P2S VPN is also a useful solution to use instead of S2S VPN when you have only a few clients that need to connect to a VNet. This article applies to the Resource Manager deployment model.
Reference:
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
You have an Azure subscription that contains 10 virtual networks. The virtual networks are hosted in separate resource groups.
Another administrator plans to create several network security groups (NSGs) in the subscription.
You need to ensure that when an NSG is created, it automatically blocks TCP port 8080 between the virtual networks.
Solution: You create a resource lock, and then you assign the lock to the subscription.
Does this meet the goal?
Yes
No
Answer is No
You need to use a custom policy definition, because there is not a built-in policy and Resource Lock is an irrelevant solution.
Reference:
https://docs.microsoft.com/en-us/azure/azure-policy/policy-definition
https://docs.microsoft.com/en-us/azure/governance/policy/samples/built-in-policies
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json
You have an Azure subscription that contains the virtual machines shown in the following table.
You deploy a load balancer that has the following configurations:
- Name: LB1
- Type: Internal
- SKU: Standard
- Virtual network: VNET1
You need to ensure that you can add VM1 and VM2 to the backend pool of LB1.
Solution: You create a Basic SKU public IP address, associate the address to the network interface of VM1, and then start VM1.
Does this meet the goal?
Yes
No
Answer is No
You can only attach virtual machines that are in the same location and on the same virtual network as the LB. Virtual machines must have a standard SKU public IP or no public IP.
The LB needs to be a standard SKU to accept individual VMs outside an availability set or vmss. VMs do not need to have public IPs but if they do have them they have to be standard SKU. Vms can only be from a single network. When they don’t have a public IP they are assigned an ephemeral IP.
Also, when adding them to a backend pool, it doesn’t matter in which status are the VMs.
Note: Load balancer and the public IP address SKU must match when you use them with public IP addresses.
Reference:
https://docs.microsoft.com/en-us/azure/load-balancer/backend-pool-management
You have an Azure subscription that contains the virtual machines shown in the following table.
You deploy a load balancer that has the following configurations:
- Name: LB1
- Type: Internal
- SKU: Standard
- Virtual network: VNET1
You need to ensure that you can add VM1 and VM2 to the backend pool of LB1.
Solution: You create a Standard SKU public IP address, associate the address to the network interface of VM1, and then stop VM2.
Does this meet the goal?
Yes
No
Answer is No
You can only attach virtual machines that are in the same location and on the same virtual network as the LB. Virtual machines must have a standard SKU public IP or no public IP.
The LB needs to be a standard SKU to accept individual VMs outside an availability set or vmss. VMs do not need to have public IPs but if they do have them they have to be standard SKU. Vms can only be from a single network. When they don’t have a public IP they are assigned an ephemeral IP.
Also, when adding them to a backend pool, it doesn’t matter in which status are the VMs.
Note: Load balancer and the public IP address SKU must match when you use them with public IP addresses.
Reference:
https://docs.microsoft.com/en-us/azure/load-balancer/backend-pool-management
You have an Azure subscription that contains the virtual machines shown in the following table.
You deploy a load balancer that has the following configurations:
- Name: LB1
- Type: Internal
- SKU: Standard
- Virtual network: VNET1
You need to ensure that you can add VM1 and VM2 to the backend pool of LB1.
Solution: You create two Standard public IP addresses and associate a Standard SKU public IP address to the network interface of each virtual machine.
Does this meet the goal?
Answer is Yes
You can only attach virtual machines that are in the same location and on the same virtual network as the LB. Virtual machines must have a standard SKU public IP or no public IP.
The LB needs to be a standard SKU to accept individual VMs outside an availability set or vmss. VMs do not need to have public IPs but if they do have them they have to be standard SKU. Vms can only be from a single network. When they don’t have a public IP they are assigned an ephemeral IP.
Also, when adding them to a backend pool, it doesn’t matter in which status are the VMs.
Note: Load balancer and the public IP address SKU must match when you use them with public IP addresses.
Reference:
https://docs.microsoft.com/en-us/azure/load-balancer/backend-pool-management
You have a computer named Computer1 that has a point-to-site VPN connection to an Azure virtual network named VNet1. The point-to-site connection uses a self-signed certificate.
From Azure, you download and install the VPN client configuration package on a computer named Computer2.
You need to ensure that you can establish a point-to-site VPN connection to VNet1 from Computer2.
Solution: You export the client certificate from Computer1 and install the certificate on Computer2.
Does this meet the goal?
Yes
No
Answer is Yes
Export the client certificate from Computer1 and install the certificate on Computer2.
Each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. You generate a client certificate from the self-signed root certificate, and then export and install the client certificate. If the client certificate is not installed, authentication fails.
Reference:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site