Pass the Microsoft Azure Administrator Associate AZ-104 Questions and answers with Dumpstech

https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview#monitoring

The connection monitor capability monitors communication at a regular interval and informs you of reachability, latency, and network topology changes between the VM and the endpoint.

Connection monitor also provides the minimum, average, and maximum latency observed over time. After learning the latency for a connection, you may find that you can decrease the latency by moving your Azure resources to different Azure regions.

When deploying a virtual machine via an ARM template, dependencies must ensure resources are created in the proper order. A VM requires a network interface (NIC) at creation time; therefore, the VM resource must depend on the NIC.

The NIC itself depends on the virtual network, subnet, network security group, and public IP (if applicable). Microsoft ARM template guidance specifies that the VM’s dependsOn should reference the NIC, allowing Azure Resource Manager to implicitly handle the remaining network dependencies.

Box1 = To minimize the network costs of accessing adatum22, modify the Default routing tier setting. 

The default routing tier setting determines how network traffic is routed from the internet to the storage account. By default, the Microsoft global network routing option is selected, which means that traffic is routed over the Microsoft global network for the bulk of its path, maximizing network performance and reliability. However, this option also incurs network charges for data transfer between different Azure regions. The internet routing option, on the other hand, minimizes the traversal of traffic over the Microsoft global network, handing it off to the transit ISP at the earliest opportunity. This option lowers networking costs, but may compromise network performance and reliability. Therefore, to minimize the network costs of accessing adatum22, which is located in the East US region, from the West US region, you should modify the default routing tier setting to use internet routing instead of Microsoft global network routing. For more information, see Network routing preference for Azure Storage.

Box2 = Encryption Type

https://learn.microsoft.com/en-us/azure/storage/common/infrastructure-encryption-enable?tabs=portal

Azure Connection Monitor (a feature within Network Watcher) provides a unified, end-to-end monitoring experience across Azure, on-premises, and hybrid environments. It enables administrators to monitor connectivity between virtual machines, endpoints, and on-premises networks without needing separate monitors per region when all resources can be accessed through peering or connected networks.

According to the Microsoft Azure Network Watcher documentation,

“Connection Monitor enables you to monitor network communication between a virtual machine (VM) or virtual machine scale set and any endpoint. These endpoints can be in Azure, on-premises, or any external environment. A single Connection Monitor can track connectivity across peered VNets and hybrid connections.”

In this case:

VNET1, VNET2, and VNET3 are all peered and connected to the on-premises network.

Peered VNets provide full IP-level connectivity between all VMs as if they were on the same network, subject to NSG and routing rules.

The on-premises network connection allows visibility for hybrid monitoring.

Therefore, from any region or network where Network Watcher is enabled, you can create a single Connection Monitor that includes:

Source endpoints (VM1, VM2, VM3, and VM4) from any VNet (since they are peered and reachable).

Destination endpoint (the on-premises network or any IP/FQDN).

Connection Monitor can use Test Groups to define multiple source-destination pairs within a single monitor. This eliminates the need to deploy multiple Connection Monitors per region as long as the sources are discoverable through VNet peering or hybrid connections.

Microsoft Official Documentation Extract (Azure Network Watcher – Connection Monitor Overview):

“Connection Monitor provides unified end-to-end monitoring between Azure and on-premises resources. It supports monitoring across virtual networks, peered virtual networks, and hybrid environments using a single monitor instance.”

(Microsoft Learn: Azure Network Watcher - Connection Monitor Overview, “Unified Connection Monitoring” section)

When an Azure virtual machine is redeployed, Azure moves the VM to a new physical host. During this process, the OS disk and any attached data disks are preserved, but the temporary disk is not. On Windows VMs deployed with default settings, drive D: is the temporary disk, backed by local storage on the host. Microsoft documentation states that the temporary disk is non-persistent and data on it can be lost during maintenance, redeploy, or deallocation events.

Files created on drive C: reside on the OS disk, which is persistent and retained across redeployments. User profile and system settings such as screen saver timeout and desktop background are stored on the OS disk and therefore remain intact after redeploy. Consequently, the only change that will be lost is data written to drive D:.

When designing a network virtual appliance (NVA) solution in active-active high availability (HA) mode for traffic inspection between Azure subnets, the Microsoft Azure Load Balancer Standard SKU is the recommended option.

According to the Microsoft Azure Administrator Guide (Implement and Manage Load Balancing and Network Security) and official documentation (“Azure Load Balancer HA Ports Overview” and “Deploy highly available NVAs in Azure”), the following configurations are required:

Deploy a Standard Load Balancer (Option E):The Standard Load Balancer supports advanced high-availability features, including HA Ports, multiple front-end IPs, floating IP, and zone redundancy.The Basic SKU does not support HA Ports or multiple frontends, which are essential for this active-active scenario.

Add a Frontend IP Configuration, Backend Pool, and Health Probe (Option C):The load balancer requires:

A Frontend IP configuration that defines the incoming traffic address.

A Backend pool containing the two NVAs.

A Health probe to continuously check the operational state of each NVA, enabling automatic failover if one becomes unhealthy.This ensures uninterrupted traffic flow and compliance with the “automatic failover” requirement.

Add Two Load Balancing Rules with HA Ports and Floating IP Enabled (Option D):

HA Ports allow the load balancer to handle traffic on all ports for a specific frontend configuration, supporting multiple services (two in this case) without defining individual port rules.

Floating IP (Direct Server Return) must be enabled to allow the NVAs to participate in an active-active configuration. Floating IP ensures that the return traffic bypasses the load balancer, essential for symmetric routing and consistent session handling across multiple NVAs.Disabling Floating IP would result in asymmetric flows and failed connections during failover.

Together, these three configurations meet the requirements for automatic failover, active-active NVA operation, and load balancing across multiple services with distinct IP addresses.

Azure Documentation Reference Summary (Extracted from Microsoft Learn and AZ-104 Study Guides):

“Standard Load Balancer supports high availability using HA Ports, enabling all-port traffic load balancing.”

“For active-active NVAs, configure floating IP for both load balancing rules.”

“A frontend IP, backend pool, and health probe are mandatory for any load balancer deployment.”

“Basic Load Balancer does not support HA Ports or multiple frontend configurations.”

Final Verified Answer: ✅ C, D, and E

C. Add a frontend IP configuration, a backend pool, and a health probe.

D. Add two load balancing rules that have HA Ports and Floating IP enabled.

E. Deploy a Standard Load Balancer.

The provided ARM template creates a resource of type Microsoft.Resources/resourceGroups. Templates that create or manage resource groups must be deployed at the subscription scope, not at the resource group scope. Microsoft guidance on deployment scopes explains that resource group creation requires a subscription-level deployment.

Accordingly, the correct Azure PowerShell cmdlet to deploy such a template from Azure Cloud Shell is New-AzSubscriptionDeployment. The other options target tenant, management group, or resource group scopes and are not appropriate for creating a resource group.

If you define more than one action on the same blob, lifecycle management applies the least expensive action to the blob. For example, action delete is cheaper than action tierToArchive. Action tierToArchive is cheaper than action tierToCool. https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview