Free Microsoft AZ-104 Practice Exam with Questions & Answers | Set: 3

To migrate virtual machines from VMware vSphere to Azure, you need to use Azure Migrate, which is a service that helps you assess and migrate your on-premises workloads to Azure. Azure Migrate uses an appliance that you deploy as an Open Virtualization Application (OVA) template to vSphere. The appliance discovers the virtual machines and sends metadata and performance data to Azure Migrate. You can then use Azure Migrate to assess the readiness, cost, and sizing of the virtual machines for migration. You can also use Azure Migrate to replicate and migrate the virtual machines to Azure. References:

About Azure Migrate

Prepare VMware servers for assessment and migration to Azure with Azure Migrate Server Migration

The correct username is ContReg1 . In Azure Container Registry, each registry includes an admin user account that is disabled by default. When the admin user is enabled, Azure generates admin credentials for the registry. The admin account is tied to the registry itself and has full permissions to the registry, so Microsoft recommends enabling it only when necessary. Microsoft’s documentation also shows that registry credentials are retrieved for a specific registry name by using commands such as az acr credential show -n < registry-name > , where the credential set belongs to that registry.

For exam purposes, the important behavior is that the admin username is the container registry name , not a generic account such as root , admin , or administrator . Therefore, for a registry named ContReg1 , the sign-in username is ContReg1 . This is commonly tested because the admin account resembles a local administrative login but is implemented as registry-scoped credentials. This topic maps to the AZ-104 study guide area Deploy and manage Azure compute resources , specifically Provision and manage containers in the Azure portal , including Azure Container Registry authentication and image access.

The correct approach is to create a parent ARM template that references Template1 and Template2 as linked templates . Microsoft’s ARM guidance states that complex solutions can be broken into related templates and deployed together through a main template; linked templates remain separate files referenced from the main template, which preserves modularity and reusability.

This also solves the cross-template dependency issue. Microsoft states that dependencies can be set between nested or linked templates, and if resources in one linked template must exist before resources in another, the second linked deployment can depend on the first. A simple dependsOn on the VM extension inside Template1 is insufficient because ARM dependencies are evaluated for resources deployed in the same template context; the documented dependency behavior is that Resource Manager deploys resources in dependency order and otherwise deploys them in parallel.

Adding Template2’s resources into Template1 would violate the requirement that both templates remain separate and reusable. This aligns with AZ-104 Deploy and manage Azure compute resources , specifically Automate deployment of resources by using Azure Resource Manager templates or Bicep files .

In the provided NSG configuration for VM2, the effective inbound security rules show the following priorities:

Priority

Name

Port

Protocol

Source

Action

100

Allow_131.107.100.50

443

TCP

131.107.100.50

Allow

200

BlockAllOther443

443

TCP

Any

Deny

65000+

Default rules

Various

Any

Allow/Deny

The problem states that connections from 131.107.100.50 to port 443 fail, even though the Load Balancer rules are correct.

The proposed solution is to create a new inbound rule that denies all traffic from 131.107.100.50 with a priority of 64999.

However, this does not solve the problem — it makes it worse, because:

The rule with priority 64999 has a higher number, meaning it is evaluated later than existing rules.

Since NSG rules are processed in ascending order of priority, the first matching rule applies.

The rule at priority 200 (BlockAllOther443) already denies the connection before the new rule is even evaluated.

To fix the issue, the correct solution would be to modify or remove the “BlockAllOther443” rule, or adjust priorities so that the allow rule for 131.107.100.50 is evaluated first.

Simply adding another deny rule with a lower priority number (higher numeric value) will not override existing denies.

✅ Final Verified Answer: B. No

In Azure App Service, autoscale rules automatically adjust the number of running instances based on performance metrics such as CPU, memory, or custom metrics. The configuration shown uses the Memory Percentage metric with a threshold of 70%, meaning that if average memory utilization exceeds 70% for 15 minutes, Azure will trigger a scale-out action.

From the exhibit, the rule specifies:

Metric threshold: Greater than 70%

Duration: 15 minutes

Action: Increase count by 1 instance

Cool down: 5 minutes

Maximum instance limit: 5

App1 currently has 2 running instances.

If App1 maintains 80% memory utilization for 30 minutes, the autoscale mechanism will trigger the scale-out action after each qualifying 15-minute window, adding 1 instance every 5-minute cooldown period until the maximum instance limit (5) is reached.

Therefore, the progression would be:

Start: 2 instances

After first 15 minutes: +1 instance → 3 total

After next 5-minute cooldown and continuing high memory → +1 instance → 4 total

After another cycle → +1 instance → 5 total

Since the rule continues to trigger until the maximum (5) is reached, and the memory usage remains above the threshold, the maximum number of instances that App1 will scale to during the 30-minute period is 5.

In this scenario, you need to inspect all network traffic between VM1 and VM2 in VNet1 for a period of time. The proposed solution uses Azure Network Watcher – Connection Monitor. However, this solution does not meet the goal, because Connection Monitor is designed to test connectivity and monitor latency, packet loss, and reachability between two endpoints—not to capture or inspect the actual contents or packets of the traffic.

According to Microsoft Azure Administrator Study Guide and Azure Network Watcher official documentation, Azure provides different tools for different purposes:

Connection Monitor: Verifies that a connection exists between two VMs or endpoints and monitors metrics such as latency, availability, and packet loss. It does not capture network packets or provide detailed traffic inspection.

Network Watcher Packet Capture: Captures actual network packets entering or leaving a virtual machine. It is the correct tool to use when you need to inspect all network traffic between VMs. Packet capture can be configured to run for a specific time (for example, three hours) and stored in Azure Storage for later analysis.

From the Microsoft Learn: " Implement and Manage Network Watcher " documentation, the correct approach is:

“Use Network Watcher Packet Capture to capture network traffic to and from a virtual machine. Packet capture helps in diagnostics by collecting network traffic over a specified time frame or under certain conditions.”

Therefore, to meet the goal of inspecting all traffic between VM1 and VM2, you must use Packet Capture, not Connection Monitor.

Box 1: Create a virtual network gateway and a local network gateway.

Azure VPN gateway. The VPN gateway service enables you to connect the VNet to the on-premises network through a VPN appliance. For more information, see Connect an on-premises network to a Microsoft Azure virtual network. The VPN gateway includes the following elements:

Virtual network gateway. A resource that provides a virtual VPN appliance for the VNet. It is responsible for routing traffic from the on-premises network to the VNet.

Local network gateway. An abstraction of the on-premises VPN appliance. Network traffic from the cloud application to the on-premises network is routed through this gateway.

Connection. The connection has properties that specify the connection type (IPSec) and the key shared with the on-premises VPN appliance to encrypt traffic.

Gateway subnet. The virtual network gateway is held in its own subnet, which is subject to various requirements, described in the Recommendations section below.

Box 2: Configure a site-to-site VPN connection

On premises create a site-to-site connection for the virtual network gateway and the local network gateway.

Scenario: Connect the New York office to VNet1 over the Internet by using an encrypted connection.