The Microsoft Azure Administrator (AZ-104)

Azure App Service (which hosts web apps) can securely connect to resources inside an Azure Virtual Network (VNet) by enabling VNet Integration.

In this scenario:

VM1 hosts a MySQL database inside VNET1.

webapp1 (the Azure Web App) needs to access that data privately.

To allow webapp1 to communicate with VM1, you should enable VNet Integration on webapp1, connecting it to VNET1.

This ensures:

Private, secure communication between the App Service and the virtual machine.

No need to expose public IPs or deploy extra load balancers.

Incorrect options:

B. Internal Load Balancer → Used to balance internal traffic among VMs, not for connecting web apps.

C. Application Gateway → Provides HTTP load balancing, not private connectivity.

D. VNet Peering → Used to connect different VNets, not to connect an App Service to a VNet.

✅ Final Verified Answer: A. Connect webapp1 to VNET1

Azure App Service Plans determine the scaling behavior of web apps hosted on them. Scaling can be done manually or automatically depending on the pricing tier.

From the Microsoft Azure Administrator Study Guide and official documentation (“Scale instance count manually or automatically” — Microsoft Learn):

“To enable automatic scaling based on metrics such as CPU usage, memory percentage, or HTTP queue length, your App Service Plan must be in the Standard, Premium, PremiumV2, or higher tier. You can then configure Scale Out (App Service plan) to use a Rules-Based method with performance thresholds.”

Available Scaling Options:

Manual: Fixed number of instances; no automatic scaling.

Automatic (Rules-Based): Create scaling rules based on metrics such as CPU > 80%, memory, or HTTP requests.

Scale Up (App Service Plan): Change pricing tier or hardware resources — does not provide auto-scaling.

In this scenario:

You already have a Standard plan (Plan1).

The requirement is to automatically scale out when CPU > 80%.

This behavior is achieved via Rules-Based scale-out, where you define a rule:

Metric: CPU Percentage

Condition: Greater than 80%

Action: Increase instance count

✅ Therefore, you must choose Rules Based in the Scale out method settings for Plan1.

To ensure that the members of Group1 can upload files by using the Azure portal, they need to have both data access and management access to the storage account. Data access refers to the ability to read, write, or delete blob data in the storage account. Management access refers to the ability to view the storage account resources in the Azure portal, but not modify them. The Azure role-based access control (Azure RBAC) system provides built-in roles that encompass common sets of permissions for data access and management access. The Storage Blob Data Contributor role grants read, write, and delete access to blob data in the storage account. The Reader role grants view access to the storage account resources in the Azure portal. Therefore, by assigning both roles to Group1, the members of the group can upload files by using the Azure portal. This solution also follows the principle of least privilege, as the group members are only granted the minimum permissions required to perform the task. References:

Assign an Azure role for access to blob data

Data access from the Azure portal

To create a load balancing rule that will load balance HTTPS traffic between VM1 and VM2, you need to create two additional load balance resources: a frontend IP address and a health probe.

A frontend IP address is the IP address that the clients use to access the load balancer. It can be either public or private, depending on the type of load balancer. A frontend IP address is required for any load balancing rule1.

A health probe is used to monitor the health and availability of the backend instances. It can be either TCP, HTTP, or HTTPS, depending on the protocol of the load balancing rule. A health probe is required for any load balancing rule1.

A backend pool is a group of backend instances that receive the traffic from the load balancer. You already have a backend pool that contains VM1 and VM2, so you don’t need to create another one.

An inbound NAT rule is used to forward traffic from a specific port on the frontend IP address to a specific port on a backend instance. It’s not required for a load balancing rule, but it can be used to access individual instances for troubleshooting or maintenance purposes1.

A virtual network is a logical isolation of Azure resources within a region. It’s not a load balance resource, but it’s required for creating an internal load balancer or connecting virtual machines to a load balancer2.

This question focuses on how to monitor network connectivity and latency between Azure virtual machines and on-premises resources using Azure Network Watcher – Connection Monitor (v2).

???? Scenario Breakdown

VM1: Azure virtual machine (in your subscription)

DC1: On-premises domain controller (in your datacenter)

Connectivity: Via ExpressRoute

Goal: Use Connection Monitor to track network latency between VM1 (Azure) and DC1 (on-premises)

To achieve this, both endpoints (VM1 and DC1) must have agents capable of collecting and sending network telemetry data to Azure Monitor.

???? Understanding Azure Connection Monitor (v2)

According to Microsoft Learn (“Monitor network connectivity with Connection Monitor”):

“Connection Monitor (v2) enables you to monitor network connectivity between Azure and on-premises resources. You can monitor connections between Azure VMs, Azure Arc-enabled servers, and any endpoint reachable over TCP or ICMP.”

To participate in a hybrid connection, the on-premises machine must be onboarded to Azure Arc.

Azure Arc connects your non-Azure servers to Azure Resource Manager and allows management and monitoring using Azure services, including Network Watcher’s Connection Monitor.

???? Required Agent for On-Premises Monitoring

For on-premises servers (like DC1), Azure Arc uses the Azure Connected Machine agent (formerly known as the Azure Arc agent).

This agent:

Registers the on-premises machine as an Azure Arc-enabled server in Azure.

Enables the use of Azure Monitor, Defender for Cloud, Update Management, and Connection Monitor on that server.

Once the Azure Connected Machine agent is installed and the server is connected through Azure Arc, you can add it as a source or destination endpoint in Connection Monitor to measure latency and packet loss.

???? Why Other Options Are Incorrect

Option

Description

Why Incorrect

A. Log Analytics agent

Used for data collection (logs and metrics) for Azure Monitor.

❌ Does not support Connection Monitor (v2) endpoint monitoring. Deprecated in favor of Azure Monitor Agent.

B. Azure Network Watcher Agent extension

Used only on Azure VMs, not on on-premises servers.

❌ Cannot be installed on DC1 (non-Azure).

C. Azure Monitor agent extension

Used for telemetry/log ingestion into Azure Monitor.

❌ Does not support connectivity monitoring for hybrid endpoints.

✅ D. Azure Connected Machine agent

Connects on-premises servers to Azure Arc, enabling Connection Monitor and other Azure services.

✅ Correct and required.

???? Verification (Microsoft Documentation Extract)

From Microsoft Learn – “Monitor hybrid connectivity using Connection Monitor”:

“To monitor on-premises resources, onboard the servers to Azure Arc and install the Azure Connected Machine agent. This agent enables Connection Monitor to collect network connectivity data from on-premises endpoints.”

✅ Final Verified Answer:

D. the Azure Connected Machine agent for Azure Arc-enabled servers

Summary of Key Points

Connection Monitor (v2) can track network latency between Azure and on-premises systems.

On-premises servers must be Azure Arc-enabled using the Azure Connected Machine agent.

Azure VMs use the Network Watcher extension, while non-Azure machines require Azure Arc for integration.

✅ Correct Answer: D. the Azure Connected Machine agent for Azure Arc-enabled servers

When Microsoft schedules maintenance for an Azure virtual machine (VM), the affected VM may experience a short downtime or host migration. In some cases, administrators can proactively move the VM to a new physical host before maintenance begins to minimize disruption.

According to the Microsoft Azure Administrator documentation, the only supported method to proactively move a VM to a new host is to use the Redeploy feature available under VM → Redeploy + reapply in the Azure portal or through PowerShell (Set-AzVM -Redeploy).

The Redeploy operation stops the VM, moves it to a new physical host within the same region, and then restarts it automatically. This ensures the VM is placed on healthy hardware immediately, mitigating any pending maintenance impact.

In contrast, moving a VM to a different subscription:

Is a metadata-level operation, not a host-level migration.

Requires the VM to be in a deallocated state before the move.

Does not cause the VM to change its underlying physical host.

Is typically used for billing or management reorganization, not to mitigate maintenance events.

Therefore, moving the VM to another subscription does not achieve the goal of moving VM1 to a different physical host. The VM remains on the same compute node until redeployed or maintenance is automatically performed by Azure.

The correct solution in this scenario is to use “Redeploy” from the VM blade, which explicitly triggers host relocation.

In Azure, a storage account access key provides full access to all data within the account. To reduce risk and follow security best practices, these keys should be rotated (regenerated) periodically.

According to the Microsoft Azure Storage and Security documentation, Azure Key Vault can be used to automate access key rotation for storage accounts.

Azure Key Vault allows you to:

Store and manage secrets, keys, and certificates securely.

Integrate directly with Azure Storage to manage account keys and Shared Access Signatures (SAS).

Enable automated key rotation when using Azure Key Vault managed storage account keys.

Here’s how it works:

In Azure Key Vault, add the storage account (storage1) as a managed storage account.

Key Vault periodically regenerates (rotates) the storage access keys automatically.

Applications can retrieve updated keys via Key Vault APIs or managed identities without manual key updates.

This process ensures consistent security and reduces the administrative effort required for key rotation.

Other options such as backup vaults, redundancy, or lifecycle management do not handle access key rotation—they serve data protection or retention purposes, not key management.

✅ Final Verified Answer: D. an Azure key vault

1. View template from deployment history

Go to the resource group for your new resource group. Notice that the portal shows the result of the last deployment. Select this link.

2. You see a history of deployments for the group. In your case, the portal probably lists only one deployment. Select this deployment.

The portal displays a summary of the deployment. The summary includes the status of the deployment and its operations and the values that you provided for parameters. To see the template that you used for the deployment, select View template.

Azure Storage provides a built-in security setting that warns users when creating a SAS token with an expiry exceeding seven days.

When Allow recommended upper limit for SAS expiry interval is enabled:

Users receive a warning message

SAS creation is not blocked

Enforces Microsoft’s security best practice

Lifecycle rules manage blob data, not access. Alerts cannot intercept SAS creation. Resource locks do not affect SAS behavior.

Microsoft documentation states:

“Enabling the recommended SAS expiry interval warns users when the expiry exceeds seven days.”