Free Preparation Discussions
MENU
Microsoft AZ-104 Exam Questions
Free Microsoft AZ-104 Exam Actual Questions
Note: Premium Questions for AZ-104 were last updated On Aug. 02, 2026 (see below)
You have an Azure subscription that contains two virtual machines named VM1 and VM2
You create an Azure load balancer.
You plan to create a load balancing rule that will load balance HTTPS traffic between VM1 and VM2.
Which two additional load balance resources should you create before you can create the load balancing rule? Each correct answer presents part of the solution
MOTL Each correct selection 5 worth one point.
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.
You have an Azure subscription that contains an Azure virtual machine named VM1. VM1 runs a financial
reporting app named App1 that does not support multiple active instances.
At the end of each month, CPU usage for VM1 peaks when App1 runs.
You need to create a scheduled runbook to increase the processor performance of VM1 at the end of each month.
What task should you include in the runbook?
To create a scheduled runbook to increase the processor performance of VM1 at the end of each month, you need to modify the VM size property of VM1. This will allow you to scale up the VM to a larger size that has more CPU cores and memory. You can use Azure Automation to create a PowerShell runbook that changes the VM size using the Set-AzVM cmdlet. You can then schedule the runbook to run at the end of each month using the Azure portal or Azure PowerShell.For more information, seeHow to resize a virtual machine in Azure using Azure Automation1.
You need to identify which storage account to use for the flow logging of IP traffic from VM5. The solution must meet the retention requirements.
Which storage account should you identify?
You must identify the correct storage account for flow logging of IP traffic from VM5 that satisfies the retention requirement of eight months.
Step 1 --- Review the Requirements
Flow logs are stored in a StorageV2 (general purpose v2) account.
The selected storage account must support Network Watcher flow logs.
Data must be retained for eight months ( 240 days).
Step 2 --- Evaluate Each Storage Account
Storage Account
Kind
Region
Remarks
storage1
Storage (general purpose v1)
West US
Does not support flow logs (deprecated type).
storage2
StorageV2 (general purpose v2)
East US
Fully supports flow logs and lifecycle management.
storage3
BlobStorage
East US 2
Not suitable --- supports blobs only, not log structure or lifecycle retention.
storage4
FileStorage
Central US
File-only --- cannot store flow logs.
Step 3 --- Compliance with Flow Log Retention
Flow logs for Network Watcher NSG flow logging are supported only by StorageV2 accounts. You can use Azure Storage lifecycle management to automatically delete logs after a set period --- such as 240 days (8 months) --- to comply with retention requirements.
Official Microsoft Note: ''Network security group (NSG) flow logs are stored in Azure StorageV2 (General Purpose v2) accounts, which support lifecycle management for log retention.'' --- Azure Network Watcher documentation.
Conclusion
storage2 is the only StorageV2 account.
It's located in East US, matching VM5's region (East US) --- this satisfies performance and compliance requirements.
You have an Azure Subscription that contains the virtual networks Shown in the following table.
All the virtual networks are peered. Each virtual network contains nine virtual machines.
You need to configure secure RDP corrections to the virtual machines by using Azure Boston.
Whit is the minimum number of Bastion nests required?
According to theMicrosoft documentation, Azure Bastion is a service that provides more secure and seamless RDP and SSH access to virtual machines without any exposure through public IP addresses. You can provision the service directly in your local or peered virtual network to get support for all the VMs within it.
In your scenario, you have three virtual networks that are peered with each other. This means that they can communicate with each other as if they were in the same virtual network. Therefore, you can deploy one Bastion host in any of the virtual networks and use it to connect to all the virtual machines in the peered virtual networks. You don't need to deploy a separate Bastion host for each virtual network or each virtual machine.
For more information about how to deploy and use Azure Bastion, seeTutorial: Deploy Bastion using specified settings: Azure portal.
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
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?
This question tests understanding of Azure Load Balancer SKU compatibility and backend pool configuration requirements.
Scenario Summary
You have:
VM1 and VM2 in the same VNet (VNET1)
A Load Balancer (LB1) configured as:
Type: Internal
SKU: Standard
You need to ensure that VM1 and VM2 can be added to LB1's backend pool.
The proposed solution:
'You create two Standard public IP addresses and associate a Standard SKU public IP address to the network interface of each virtual machine.'
Understanding Azure Load Balancer Requirements
1. Backend pool requirements for a Standard Load Balancer:
All VMs must be in the same virtual network as the load balancer.
Each VM's NIC must be configured with a Standard SKU IP configuration (private or public).
The Load Balancer SKU must match the SKU of the IP addresses associated with the VM network interfaces.
2. Internal Load Balancer behavior:
An Internal Load Balancer (ILB) distributes traffic within a virtual network using private IP addresses, not public IPs.
Therefore, the backend VMs do not need public IPs --- and adding them does not affect backend pool membership.
3. SKU alignment rule (Microsoft Docs):
''You can only attach virtual machines or instances that use Standard IP configurations to a Standard Load Balancer. Basic and Standard SKUs are not interchangeable.''
However:
A public IP is only required for inbound Internet access or outbound NAT, not for internal load balancing.
For an Internal Standard Load Balancer, backend pool members require Standard SKU NIC configurations, not public IPs.
Why the Proposed Solution Fails
The solution suggests creating two Standard public IPs and assigning them to the VMs' NICs.
This does not enable VM1 and VM2 to join the backend pool of an internal load balancer, because:
The load balancer type is internal, meaning it routes private traffic within the virtual network, not via public IPs.
Backend pool membership depends on the NIC's private IP configuration, not its public IP.
Adding public IPs only exposes VMs to the Internet and does not influence load balancer backend eligibility.
Thus, this action is unnecessary and does not meet the goal.
Correct Solution (for reference)
To meet the goal:
Ensure VM1 and VM2 have NICs configured with Standard SKU private IPs.
Ensure both VMs are in VNet1, the same virtual network as LB1.
No need to assign public IPs to internal backend VMs.
You could also ensure:
az network nic ip-config update \
--name ipconfig1 \
--nic-name VM1-nic \
--resource-group RG1 \
--private-ip-address-version IPv4 \
--sku Standard
Final Verified Answe r:
- Select Question Types you want
- Set your Desired Pass Percentage
- Allocate Time (Hours : Minutes)
- Create Multiple Practice tests with Limited Questions
- Customer Support
Patricia Adams
12 days agoCrystal Green
26 days agoAdam Rivera
1 month agoEric Mitchell
2 months agoDonald King
2 months agoCarol Turner
3 months agoBrenda Wilson
3 months agoCrystal Hall
3 months agoMichael Nguyen
3 months agoGerald Allen
3 months agoLinda Baker
3 months agoDennis Flores
3 months agoDaniel
4 months agoLashandra
4 months agoJulio
5 months agoJolene
5 months agoOzell
5 months agoLaurena
5 months agoEric
6 months agoCarole
6 months agoKimbery
6 months agoGeoffrey
6 months agoCarman
7 months agoElza
7 months agoCristy
7 months agoStevie
7 months agoMagdalene
8 months agoNadine
8 months agoJustine
8 months agoDerrick
8 months agoStephen
9 months agoPolly
9 months agoLizbeth
9 months agoNobuko
9 months agoJannette
10 months agoNicolette
10 months agoGaynell
10 months agoStefania
10 months agoHuey
11 months agoRanee
11 months agoOmega
11 months agoLuis
11 months agoSonia
11 months agoJanna
1 year agoAlyce
1 year agoMauricio
1 year agoLaine
1 year agoJohnna
1 year agoMicaela
1 year agoBettina
1 year agoDorsey
1 year agoStephanie
1 year agoHoward
1 year agoDonette
1 year agoBritt
2 years agoMicaela
2 years agoMireya
2 years agoDeandrea
2 years agoKenneth
2 years agoLashon
2 years agoCecil
2 years agoIola
2 years agoRebecka
2 years agoRhea
2 years agoDesiree
2 years agoChuck
2 years agoGail
2 years agoTerry
2 years agoCorrinne
2 years agoGwenn
2 years agoGianna
2 years agoEmogene
2 years agoJuliana
2 years agoAja
2 years agoLindsey
2 years agoDevorah
2 years agoFelix
2 years agoCiara
2 years agoRessie
2 years agoOretha
2 years agoAdelaide
2 years agoMari
2 years agoLetha
2 years agoalizabeth
2 years agoMark james
2 years agoJAZZY
2 years agolivingston
2 years agohamim
2 years agopelvis
2 years agosijag
2 years agogarey
2 years ago