The Microsoft Azure Administrator (AZ-104)

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.

When Azure schedules maintenance for a virtual machine, you can proactively move it to a new physical host by performing a self-service redeploy.

The Redeploy feature in the Azure portal allows you to:

Move the VM to a new host node.

Keep the same network interface, disks, and configuration.

Resolve underlying host-level or platform issues proactively.

This action satisfies the requirement to move VM1 to a different host immediately and minimizes downtime.

This is explicitly documented in the Microsoft Learn - Redeploy Windows virtual machine to new Azure node guide.

✅ Final Verified Answer: A. Yes

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.

The requirement is for Group1 to manage role assignments (Azure RBAC) across existing subscriptions and future subscriptions, while applying least privilege and minimizing ongoing administration. In Azure RBAC, the permission to create, update, and delete role assignments is governed by management-plane actions under Microsoft.Authorization/roleAssignments. Microsoft’s Azure Administrator documentation identifies two common roles that can manage access: Owner and User Access Administrator. Of these, User Access Administrator is the least-privileged role intended specifically to manage user access without granting full resource management permissions like Owner does.

To minimize administrative effort for both current and newly purchased subscriptions, you should assign the role at the highest scope that will automatically cover all subscriptions through inheritance. The root management group is the top of the management group hierarchy; all management groups and subscriptions roll up to it. Assigning User Access Administrator to Group1 at the root management group ensures Group1 can manage role assignments across the entire hierarchy, including subscriptions added later, without repeatedly applying role assignments per subscription or per management group. This meets both requirements: least privilege (User Access Administrator instead of Owner) and minimal administrative effort (one assignment at the root scope).

To enable a web app hosted in Azure App Service to connect securely to an on-premises SMB share (Share1), you must create hybrid network connectivity between your Azure environment and your on-premises network.

According to the Microsoft Azure Administrator Study Guide and Microsoft Learn documentation, Azure Web Apps running in an App Service Plan cannot directly access on-premises file shares over the public internet for security reasons. You must extend your on-premises network to Azure through a Virtual Network (VNet) and then integrate the web app with that network.

The Virtual Network Gateway is the component that enables this hybrid connectivity. It establishes a Site-to-Site VPN or ExpressRoute connection between the Azure VNet and the on-premises network, allowing the web app (after VNet integration) to access internal resources such as SMB shares, SQL Servers, or file servers.

Once the VPN gateway is configured and the web app is integrated with the VNet (Regional VNet Integration), the web app can securely access Share1 over the private network channel.

Official Microsoft Documentation Extract (Summary):

“To access on-premises resources from Azure App Service, configure VNet Integration and establish a Site-to-Site VPN or ExpressRoute connection using a Virtual Network Gateway. This allows Azure resources to securely communicate with on-premises systems such as SMB file shares or databases.”

(Source: Microsoft Learn — Connect an App Service app to an on-premises network using Azure VPN Gateway.)

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups Multi-container groups currently support only Linux containers. For Windows containers, Azure Container Instances only supports deployment of a single container instance. While we are working to bring all features to Windows containers, you can find current platform differences in the service

According to the Microsoft Azure Administrator (AZ-104) official documentation and study guides, when a virtual machine (VM) in Azure is scheduled for maintenance, you can proactively move the VM to another host to minimize downtime. This process is called a self-service maintenance move.

When Azure schedules maintenance events that could affect the underlying host hardware, customers have the option to move their virtual machines within the same region and subscription to a healthy host by using either the Azure portal, PowerShell, or the Azure CLI. The operation that performs this action is called Redeploy or Maintenance Redeploy.

In this scenario, the proposed action — moving the VM to another subscription from the resource group blade — does not satisfy the requirement. Moving a VM between subscriptions involves deallocation and redeployment, which does not guarantee that the VM will move to a new host to avoid maintenance. In fact, the VM will remain unavailable during the move process and may need to be reconfigured.

The correct solution to move a VM to another host immediately is to perform a self-service maintenance operation or redeploy the VM. This can be done by selecting the VM in the Azure portal, navigating to Help + support → Maintenance, and choosing “Move to a different host”, or by using the Redeploy button under the VM settings.

Thus, moving the VM to another subscription does not meet the maintenance mitigation goal.

https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-new-alert-rule

You create an alert rule by combining:

- The resources to be monitored.

- The signal or telemetry from the resource.

- Conditions.

Then you define these elements for the resulting alert actions by using:

- Alert processing rules

- Action groups

You can change the location in resources. Parameters used to define the value of some variables to be able to use in different places in the template resources. Resources are used only for complicated expressions. In any case, RM will only deploy from resources. In case the value is not mentioned directly, then it will check parameters if it is specified in the resources. Based on this question, the value of location is defined directly in resources. so you change the resources location value.

Use location parameter. To allow flexibility when deploying your template, use a parameter to specify the location for resources. Set the default value of the parameter to resourceGroup().location.