AZ-104: Microsoft Azure Administrator
You have an Azure subscription named Subscription1 that contains the quotas shown in the following table.
You deploy virtual machines to Subscription1 as shown in the following table.
You plan to deploy the virtual machines shown in the following table.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
The total regional vCPUs is 20 so that means a maximum total of 20 vCPUs across all the different VM sizes. The deallocated VM with 16 vCPUs counts towards the total. VM20 and VM1 are using 18 of the maximum 20 vCPUs leaving only two vCPUs available.
Total regional vCPUs = 20
2 vCPUs (VM1) + 16 vCPUs (VM20) = 18 vCPUs, which means that only 2 vCPUs left to exceed usage limit.
Box 1: Yes
We can add 1 vCPU. 2 vCPUs (VM1) + 16 vCPUs (VM20) + 1 vCPU (VM3) = 19 vCPUs
Box 2: No
We cannot add 4 vCPUs. 2 vCPUs (VM1) + 16 vCPUs (VM20) + 4 vCPU (VM4) = 22 vCPUs
Box 3: No
We cannot add 16 vCPU. 2 vCPUs (VM1) + 16 vCPUs (VM20) + 16 vCPU (VM5) = 34 vCPUs
Reference:
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/quota
You have Azure subscriptions named Subscription1 and Subscription2.
Subscription1 has following resource groups:
RG1 includes a web app named App1 in the West Europe location.
Subscription2 contains the following resource groups:
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: No
RG2 is read only. ReadOnly means authorized users can read a resource, but they cannot delete or update the resource.
Box 2: Yes
Box 3: Yes
Note:
App Service resources are region-specific and cannot be moved across regions. You must create a copy of your existing App Service resources in the target region, then move your content over to the new app. You can then delete the source app and App Service plan.
To make copying your app easier, you can clone an individual App Service app into an App Service plan in another region.
Reference:
https://docs.microsoft.com/en-us/azure/app-service/manage-move-across-regions
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/move-limitations/app-service-move-limitations
You have an Azure subscription that contains the virtual machines shown in the following table:
VM1 and VM2 use public IP addresses. From Windows Server 2019 on VM1 and VM2, you allow inbound Remote Desktop connections.
Subnet1 and Subnet2 are in a virtual network named VNET1.
The subscription contains two network security groups (NSGs) named NSG1 and NSG2. NSG1 uses only the default rules.
NSG2 uses the default rules and the following custom incoming rule:
- Priority: 100
- Name: Rule1
- Port: 3389
- Protocol: TCP
- Source: Any
- Destination: Any
- Action: Allow
NSG1 is associated to Subnet1. NSG2 is associated to the network interface of VM2.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: No
NSG1 has default rules, which denies any port open for inbound rules
Box 2: Yes
NSG2 has custom Rule1, allowing RDP port 3389 with TCP.
Box 3: Yes
VM1 and VM2 are in the same Vnet. By default, communication is allowed.
You have a virtual network named VNET1 that contains the subnets shown in the following table:
You have two Azure virtual machines that have the network configurations shown in the following table:
For NSG1, you create the inbound security rule shown in the following table:
For NSG2, you create the inbound security rule shown in the following table:
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: No
VM1 has the NSG1 on Subnet1, which allows traffic over port 1433 between Subnet2 and Subnet1. But NSG2 also applied on NIC level for VM1 blocks the traffic on port 1433. Hence, no traffic is allowed. There is no priority bypass between NSGs. Traffic is filtered independently between NSGs.
Box 2: Yes
For VM2 there are no NSGs applied neither on Subnet or NIC level, hence all traffic is allowed. Also, VM1 and VM2 are inside the same VNET1.
Box 3: Yes
For VM3 there are no NSGs applied neither on subnet or NIC level, hence all traffic is allowed. Also, VM2 and VM3 are inside the same Subnet2 and VNET1.
Reference:
https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
You have an Azure subscription named Subscription1.
Subscription1 contains the virtual machines in the following table:
Subscription1 contains a virtual network named VNet1 that has the subnets in the following table:
VM3 has multiple network adapters, including a network adapter named NIC3. IP forwarding is enabled on NIC3. Routing is enabled on VM3.
You create a route table named RT1 that contains the routes in the following table:
You apply RT1 to Subnet1 and Subnet2.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: Yes
The routing table allows connections from VM3 to VM1 and VM2. And as IP forwarding is enabled on VM3, VM3 can connect to VM1.
Box 2: No
VM3, which has IP forwarding, must be turned on, in order for VM2 to connect to VM1.
Box 3: Yes
The routing table allows connections from VM1 and VM2 to VM3. IP forwarding on VM3 allows VM1 to connect to VM2 via VM3.
IP forwarding enables the virtual machine a network interface is attached to:
- Receive network traffic not destined for one of the IP addresses assigned to any of the IP configurations assigned to the network interface.
- Send network traffic with a different source IP address than the one assigned to one of a network interface's IP configurations.
The setting must be enabled for every network interface that is attached to the virtual machine that receives traffic that the virtual machine needs to forward. A virtual machine can forward traffic whether it has multiple network interfaces or a single network interface attached to it.
Reference:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
https://www.quora.com/What-is-IP-forwarding
You have an Azure subscription. The subscription contains virtual machines that run Windows Server 2016 and are configured as shown in the following table.
You create a public Azure DNS zone named adatum.com and a private Azure DNS zone named contoso.com.
You create a virtual network link for contoso.com as shown in the following exhibit.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
All three VMs are in VNET2. Auto registration is enabled for private Azure DNS zone named contoso.com, which is linked to VNET2. So, VM1, VM2 and VM3 will auto-register their host records to contoso.com.
None of the VM will auto-register to the public Azure DNS zone named adatum.com. You cannot register private IPs on the internet (adatum.com)
Box 1: Yes
Auto registration is enabled for private Azure DNS zone named contoso.com.
Box 2: Yes
Auto registration is enabled for private Azure DNS zone named contoso.com.
Box 3: No
None of the VM will auto-register to the public Azure DNS zone named adatum.com
Reference:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
https://docs.microsoft.com/en-us/azure/dns/private-dns-autoregistration
https://docs.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links
You have an Azure subscription that contains the resource groups shown in the following table.
RG1 contains the resources shown in the following table.
VM1 is running and connects to NIC1 and Disk1. NIC1 connects to VNET1.
RG2 contains a public IP address named IP2 that is in the East US location. IP2 is not assigned to a virtual machine.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: Yes
You can move the Storage Account to RG2, however it stayed in the West US region. You cannot change the Region, you need to recreate the Storage Account.
Box 2: Yes
You can move move NIC1 to RG2 which was associated with VM1 and VNET1 subnet1, however it stayed in the West US region. You can move a NIC to a different RG or Subscription by selecting (change) next to the RG or Subscription name. If you move the NIC to a new Subscription, you must move all resources related to the NIC with it. If the network interface is attached to a virtual machine, for example, you must also move the virtual machine, and other virtual machine-related resources.
Box 3: No
You can move IP2 to RG1, as it isn't associated with any other resource, however it stayed in the East US region. The location will not change.
Note: Resources can be everywhere regardless of the resource group they belong to. The resource group is only a collection of metadata relative to the resources defined inside it. You can move a resource from one resource group to another group. The resources in a resource group can be located in different regions than the resource group.
Reference:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
You have an Azure subscription named Subscription1 that contains the virtual networks in the following table.
Subscription1 contains the virtual machines in the following table.
In Subscription1, you create a load balancer that has the following configurations:
- Name: LB1
- SKU: Basic
- Type: Internal
- Subnet: Subnet12
- Virtual network: VNET1
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Basic Load Balancer: Backend pool endpoints for Virtual machines in a single availability set or virtual machine scale set.
Subnet12 association will be used to assign an IP for the internal load balancer, not to load balance the VMs in the Subnet.
Box 1: Yes
VM1 and VM are in the Availability Set.
Box 2: No
Both VMs are not part of any Availability Set or Scale Set.
Box 3: No
Both VMs are not part of any Availability Set or Scale Set.
Reference:
https://docs.microsoft.com/en-us/azure/load-balancer/skus
You have an Azure subscription that contains the Azure virtual machines shown in the following table.
You add inbound security rules to a network security group (NSG) named NSG1 as shown in the following table.
You run Azure Network Watcher as shown in the following exhibit.
You run Network Watcher again as shown in the following exhibit.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: No
NSG1 limits the traffic that is flowing into 172.16.2.0/24 (Subnet2), which host VM2.
Box 2: Yes
Since Network Watcher is showing that traffic from VM1 to VM2 is not reaching on the TCP port, that means that NSG1 is applied to VM2. We can understand for sure, that it is not applied to VM1.
Box 3: Yes
In Network Watcher, you can see that the next hop is the destination VM2. This means that they are part of the same virtual network.
Reference:
https://docs.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works
You have an Azure subscription that contains the resources in the following table.
You install the Web Server server role (IIS) on VM1 and VM2, and then add VM1 and VM2 to LB1.
LB1 is configured as shown in the LB1 exhibit.
Rule1 is configured as shown in the Rule1 exhibit.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Box 1: Yes
A Basic Load Balancer supports virtual machines in a single availability set or virtual machine scale set.
Box 2: Yes
When using load-balancing rules with Azure Load Balancer, you need to specify health probes to allow Load Balancer to detect the backend endpoint status. The configuration of the health probe and probe responses determine which backend pool instances will receive new flows. You can use health probes to detect the failure of an application on a backend endpoint. You can also generate a custom response to a health probe and use the health probe for flow control to manage load or planned downtime. When a health probe fails, Load Balancer will stop sending new flows to the respective unhealthy instance. Outbound connectivity is not impacted, only inbound connectivity is impacted.
Box 3: No
There will be no loadbalancing between the VMs.
Basic Load Balancer: Virtual machines in a single availability set or virtual machine scale set.
Standard Load Balancer: Any virtual machines or virtual machine scale sets in a single virtual network.
Reference:
https://docs.microsoft.com/en-us/azure/load-balancer/skus
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview