Microsoft AZ-104 - Microsoft Azure Administrator

\

\

NO

YES

YES

1️⃣ VM1 is in the same availability set as VM2 → Yes

In Azure, for a Basic SKU Load Balancer, the backend virtual machines must be in the same availability set (or in the same virtual machine scale set).

Basic Load Balancers cannot span across multiple availability sets or availability zones.

The screenshot shows that LB1 uses the Basic SKU, so by requirement, VM1 and VM2 must be in the same availability set.

Therefore, this statement is true.

2️⃣ If Probe1.htm is present on VM1 and VM2, LB1 will balance traffic for TCP port 80 between VM1 and VM2 → Yes

A load balancing rule defines how traffic is distributed to the backend pool.

The rule “Rule1” uses TCP port 80 for both frontend and backend.

A health probe (Probe1.htm) monitors the health of backend VMs.

When both VMs respond successfully to Probe1.htm, the load balancer distributes TCP traffic on port 80 evenly between the two healthy VMs.

Therefore, when Probe1.htm is available and healthy on both VMs, LB1 distributes HTTP traffic (port 80) between VM1 and VM2.

This statement is true.

3️⃣ If you delete Rule1, LB1 will balance all the requests between VM1 and VM2 for all ports → No

Load balancers in Azure do not automatically balance traffic unless a load-balancing rule exists.

Each load balancing rule explicitly defines which ports and protocols are balanced.

If you delete Rule1, there will be no configuration telling the load balancer which ports to listen to or where to send traffic.

The load balancer will not distribute any traffic automatically for other ports.

Therefore, deleting the rule disables traffic distribution entirely, and this statement is false.

Microsoft Azure Administrator Official Documentation Extract (AZ-104 Reference):

“Basic Load Balancer can only balance traffic among VMs within a single availability set or virtual machine scale set.”

“A load-balancing rule defines how traffic is distributed to the backend pool. Deleting a rule stops load balancing for that port.”

“Health probes determine which backend pool instances receive new flows.”

(Source: Microsoft Learn — Azure Load Balancer Overview, Create and Manage Load Balancer Rules, Health Probes in Azure Load Balancer)

When Microsoft schedules maintenance that may affect a virtual machine (VM), administrators have two options:

Wait for Azure to perform the maintenance automatically.

Move the VM to a new host proactively to minimize or avoid downtime.

According to the Microsoft Azure Administrator documentation, using the “Redeploy + reapply” option in the Azure portal forces the VM to migrate to a new Azure host within the same region and availability set.

Here’s what happens when you click Redeploy:

Azure shuts down the existing VM.

The VM is moved to a new physical host within the same region.

The operating system disk and data disks are retained, and network configuration (NICs, public IP, etc.) is preserved.

Once redeployed, Azure reassigns the VM to the same virtual network and reattaches disks and configurations.

This method is explicitly recommended by Microsoft to proactively address maintenance events or host-related issues like “unresponsive VM” or “performance degradation.”

Therefore, using the Redeploy operation from the “Redeploy + reapply” blade effectively achieves the goal of moving the VM to a different host immediately.

You can ' t delete a vault that contains backup data. So in this case at first you have to delete the backup of  ' SQLD01 ' before you attempt to delete the vault.

In this scenario, the problem involves a Network Security Group (NSG) configuration that determines inbound traffic rules for a virtual machine. The NSG rules for VM2 are evaluated in order of priority, from the lowest number (highest priority) to the highest number (lowest priority).

According to the exhibit, the effective NSG inbound rules for VM2 are:

Priority

Name

Port

Protocol

Source

Destination

Action

100

Allow_131.107.100.50

443

TCP

131.107.100.50

VirtualNetwork

Allow

200

Block_All_Other_443

443

TCP

Any

Any

Deny

65000

AllowVNetInBound

Any

Any

VirtualNetwork

VirtualNetwork

Allow

65001

AllowAzureLoadBalancerInBound

Any

Any

AzureLoadBalancer

Any

Allow

65500

DenyAllInBound

Any

Any

Any

Any

Deny

Root Cause Analysis:

You discovered that connections to App1 from 131.107.100.50 over TCP port 443 fail, even though the Load Balancer and backend pool are configured correctly.

From the rules shown, rule 100 (Allow_131.107.100.50) should theoretically allow that specific IP to connect on port 443. However, note that the Destination for the rule is VirtualNetwork, meaning that the traffic from 131.107.100.50 must be within the same virtual network address space to be permitted.

Since 131.107.100.50 is a public IP address (external source) and not part of the Virtual Network (VNet) address space, the rule does not apply, and the connection fails.

Additionally, the next rule (200 - Block_All_Other_443) explicitly denies any other inbound traffic on TCP 443 from any source. Therefore, the inbound traffic from 131.107.100.50 is blocked.

Evaluation of the Proposed Solution:

The proposed solution suggests creating an inbound security rule:

“Allow any traffic from the AzureLoadBalancer source and set priority to 150.”

However, the existing NSG already includes a built-in rule (65001 - AllowAzureLoadBalancerInBound) that allows inbound traffic from the Azure Load Balancer. That means traffic originating from the Azure Load Balancer front-end is already allowed by default.

Since the failed connection is coming from an external client (131.107.100.50) — not from the Load Balancer source itself — adding another rule allowing AzureLoadBalancer traffic does not resolve the issue. The correct action would be to modify or create a new rule that:

Allows inbound traffic on port 443

From source 131.107.100.50

With destination = Any

Priority lower than 200 (i.e., higher precedence than the deny rule)

Verified Microsoft Azure Administrator Reference:

From Microsoft Docs – Network security group overview and priority order:

“Azure processes the security rules in priority order, starting from the lowest number. Once a rule matches the traffic, processing stops. Lower-numbered priority rules override higher-numbered ones.”

“The built-in rule AllowAzureLoadBalancerInBound allows traffic from Azure Load Balancer but not from external public IPs directly accessing the virtual machine.”

Correct Resolution:

You need to create a new inbound rule allowing TCP 443 from 131.107.100.50 with Destination: Any, Priority: < 200, for example:

Priority: 150

Source: IP address (131.107.100.50)

Destination: Any

Protocol: TCP

Port: 443

Action: Allow

This will ensure the traffic is allowed before the deny rule at 200 takes effect.

✅ Final Verified Answer:

B. No

The proposed rule allowing traffic from AzureLoadBalancer does not help, because traffic from 131.107.100.50 originates externally, not from the Load Balancer. You must instead create a rule that explicitly allows that IP on port 443 with a higher priority than the existing deny rule.

Microsoft Entra ID provides External collaboration settings to control which external domains users can invite as guests. To restrict invitations so that only users from fabrikam.com can be invited, you must configure Collaboration restrictions.

Within the External collaboration settings, administrators can:

Allow invitations only to users from specific domains

Block invitations to all other external domains

Microsoft Entra documentation specifies that Collaboration restrictions are the control used to define allowed or blocked external domains for B2B guest invitations.

The other options do not meet the requirement:

Guest user access restrictions control what guests can do after they are invited.

Cross-tenant access – Tenant restrictions control inbound/outbound access behavior, not invitation eligibility.

Microsoft cloud settings apply to cloud instances, not domain-based invitations.

Final Verified Answer:

✅ C. From External collaboration settings, configure the Collaboration restrictions settings.

Azure provides two different vault types for backup, each designed for specific workloads: Azure Backup vaults and Recovery Services vaults. Selecting the correct vault depends on the resource type being protected.

An Azure Backup vault is the newer vault type introduced to support Azure Disk Backup. According to the Azure Administrator documentation, Backup vaults are specifically designed for Azure managed disks and use a simplified policy model. They do not support backing up full virtual machines, Azure App Service apps, or Azure SQL Database (PaaS). Therefore, from the listed resources, Disk1 (Disk) is the only supported resource that can be backed up to Backup1.

A Recovery Services vault is the traditional and more feature-rich vault used to back up Azure Virtual Machines, as well as workloads such as SQL Server running inside Azure VMs. The documentation clearly states that Azure VMs must be backed up using a Recovery Services vault, not a Backup vault. As a result, VM1 (Virtual machine) must be backed up to Recovery1.

The remaining resources are not supported in either vault for this scenario:

App1 (Azure App Service web app) uses App Service backup, not Azure Backup.

DB1 (Azure SQL Database) uses built-in Azure SQL backup, not Recovery Services or Backup vaults.

Final Verified Answers:

Backup1 → Disk1

Recovery1 → VM1

In Azure Storage, to ensure that newly added content cannot be modified or deleted for a fixed retention period, you must configure a container-level immutable storage policy, also known as a time-based retention policy or immutability policy. This feature is implemented through a stored access policy in Azure Blob Storage using the WORM (Write Once, Read Many) capability.

According to Microsoft’s Azure Storage documentation, immutability policies can be configured in two ways:

Time-based retention policy – prevents data from being modified or deleted for a fixed duration (e.g., 1 year).

Legal hold – preserves data until the hold is explicitly cleared.

To implement the time-based retention policy, you configure a container-level access policy under Immutable blob storage settings. Once configured, any new blobs written to the container will be locked for the specified retention period and cannot be modified or deleted, ensuring compliance with retention regulations like SEC 17a-4(f) or GDPR.

The access level, access tier, or IAM settings do not provide this immutability. They control access permissions, performance, and user roles but do not enforce write-once protection.

Thus, the correct approach is to configure an access policy that enforces immutability for one year.

The Logic App Operator role only grants the ability to read, enable, disable, and run logic apps. It does not grant the ability to create logic apps. To create logic apps, you need to assign the Logic App Contributor role or a higher-level role such as Owner or Contributor. Then, References: [Built-in roles for Azure resources] [Azure Logic Apps permissions and access control]

Box 1: 2

There are 10 update domains. The 14 VMs are shared across the 10 update domains so four update domains will have two VMs and six update domains will have one VM. Only one update domain is rebooted at a time.

Therefore, a maximum of two VMs will be offline.

Box 2: 7

There are 2 fault domains. The 14 VMs are shared across the 2 fault domains, so 7 VMs in each fault domain.

A rack failure will affect one fault domain so 7 VMs will be offline.