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

In this scenario, the Azure subscription contains a storage account (storage1) with three resources:

container1 (Blob container)

folder1 (File share)

Table1 (Table storage)

User1’s assigned roles:

Storage Blob Data Reader → Read-only access to Blob data (cannot write).

Storage Table Data Contributor → Read, write, and delete access to Table data.

Storage File Data SMB Share Contributor → Read and write access to Azure File shares.

Now, let ' s analyze access using key1 and SAS1.

1️⃣ Access via key1

When using an account key, access is granted to all services within the storage account—Blob, File, Queue, and Table, because the key authenticates at the account level.

However, the question specifically asks:

“To which resources can User1 write by using SAS1 and key1?”

While account keys grant access to all resources, write permissions depend on the assigned roles of User1 for that account.

User1 can:

Write to the File share (folder1) because they are a Storage File Data SMB Share Contributor.

Write to the Table (Table1) because they are a Storage Table Data Contributor.

Cannot write to the Blob container (container1) because they only have the Storage Blob Data Reader role, which is read-only.

✅ Therefore, using key1, User1 can write to folder1 and Table1 only.

2️⃣ Access via SAS1

The Shared Access Signature (SAS) shown in the exhibit specifies:

Allowed services: Blob, File, and Table (Queue not selected).

Allowed permissions: Read, Write, Delete, List, Add, Create, and Update.

Start and expiry: Valid from 2022 to 2030.

Protocols: HTTPS only.

SAS defines data plane access, allowing specific operations within the defined services, regardless of the user’s assigned Azure roles.

Therefore, the SAS allows:

Access to Blob service → affects container1

Access to File service → affects folder1

Access to Table service → affects Table1

However, the question specifically distinguishes SAS1 and key1. Because SAS1 defines services explicitly, the question’s options match how Azure limits SAS to only those selected services.

Hence, SAS1 allows write access to:

Table1 (Table service)

container1 (Blob service)

✅ Therefore, using SAS1, User1 can write to Table1 and container1 only.

✅ Final Verified Answer:

Access Method

Write Access To

key1

folder1 and Table1 only

SAS1

Table1 and container1 only

Reference Extract (Azure Documentation):

“A shared access signature (SAS) grants limited access rights to Azure Storage resources for a specified time and set of permissions. The permissions are defined per service selected (Blob, File, Queue, Table).”

“Using an account key provides full access to all data objects in the storage account, but effective access may still be limited by assigned RBAC roles if role-based access control is enforced.”

To bulk invite external users (guests) into an Azure Active Directory (Azure AD) or Microsoft Entra ID tenant, administrators can automate the invitation process using PowerShell. The correct cmdlet for this task is New-AzureADMSInvitation or New-MgInvitation (in the Microsoft Graph PowerShell module).

This cmdlet sends an invitation email to each external user, enabling them to collaborate within the tenant as a B2B guest user. The invitation automatically provisions a guest user account (user_type = Guest) in the directory.

The question specifies using a PowerShell script with the New-MgInvitation cmdlet for each external user listed in a CSV file. This is the exact and supported method described in Microsoft Entra ID documentation for automating bulk guest user creation.

The process involves:

Importing the CSV file containing user data.

Iterating through each record.

Running the New-MgInvitation cmdlet with parameters like InvitedUserEmailAddress, InviteRedirectUrl, and SendInvitationMessage.

This method meets all administrative and functional requirements for creating guest users at scale while maintaining compliance with Azure AD B2B collaboration standards.

Incorrect alternatives include New-AzureADUser, which only creates internal users, and manual portal bulk upload, which does not handle guest invitations with automatic external access configuration.

Therefore, running a PowerShell script that executes New-MgInvitation for each user meets the goal perfectly as per Azure AD and AZ-104 Administrator documentation.

In Microsoft Azure Storage, maintaining high availability and durability of data is achieved through replication. There are multiple redundancy options — LRS (Locally Redundant Storage), ZRS (Zone-Redundant Storage), GRS (Geo-Redundant Storage), and RA-GRS (Read-Access Geo-Redundant Storage) — each serving different scenarios.

However, when the requirement is to create a secondary copy of blob data in a specific region (for example, when blob data is added in North Europe, a copy must be created in East US), geo-redundant storage (GRS) cannot be used directly because GRS replicates data automatically to a paired region, not to a region of your choice. In this case, North Europe’s paired region is West Europe, not East US. Therefore, GRS does not meet the goal.

The Microsoft Azure Administrator documentation specifies that the correct method for replicating data between user-defined regions is Object Replication for Block Blobs (OR).

Object replication allows you to:

Automatically replicate new and updated block blobs between two storage accounts in different Azure regions.

Use replication policies to define source and destination containers.

Minimize administrative effort, as once configured, replication occurs automatically and asynchronously.

Retain independent storage accounts, ensuring flexibility and control over access and lifecycle management.

Unlike lifecycle management rules (which only move or delete blobs within the same storage account) or operational backup (which protects data for restore purposes, not replication), object replication precisely meets the requirement of maintaining a secondary copy in another chosen region.

Therefore, per Azure’s official Storage replication and Object replication documentation, the correct configuration is Object replication between storage1 (North Europe) and another storage account in East US.

n this scenario, User1 has two role assignments:

Reader (Inherited from Resource Group scope)

Scope: Resource Group (inherited)

Permission type: Read-only access

Allows User1 to view the configuration and properties of Azure resources within the resource group (including the storage account).

However, it does not allow data operations, such as reading or writing blob contents.

Storage Blob Data Contributor (Assigned at “This resource” level)

Scope: storageacct1234 (this resource)

Permission type: Data access for blob content

Allows read, write, and delete operations on blob data in the storage account.

According to Microsoft Azure built-in roles documentation:

Reader role: “View Azure resources but cannot make any changes.”

Storage Blob Data Contributor role: “Grants read, write, and delete permissions to Azure Storage blob containers and data.”

This means:

User1 can upload blobs because the Storage Blob Data Contributor role provides write permissions.

User1 can view blob data because the same role provides read access to blob content.

User1 cannot assign roles (no RBAC management rights, as the role doesn’t include Microsoft.Authorization/* actions).

User1 cannot modify the firewall or network settings of the storage account — those actions require Contributor or Owner roles at the management plane level.

User1 can view file shares under the storage account metadata due to Reader access but cannot access data within them because that requires Storage File Data SMB Share Reader/Contributor permissions (different data plane).

✅ Final Verified Answers:

B. Upload blob data to storageacct1234

D. View blob data in storageacct1234

Summary (from Microsoft Role Documentation Extracts):

Storage Blob Data Contributor = Can read/write/delete blob data (Data Plane)

Reader = Can view Azure resource configuration (Management Plane)

No permission to assign roles or modify security/firewall settings.

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.

When deploying an Azure Container Instance (ACI) using an image from an Azure Container Registry (ACR), the deployment must authenticate to the registry to pull the image. By default, ACR is secured, and you cannot pull images anonymously unless they are public.

According to the Azure Administrator study guide, enabling the Admin user option in ACR generates two access credentials (username and password) that can be used for authentication when pulling container images. When the Admin user setting is disabled, you cannot authenticate directly using those credentials, and automated deployments may fail with authentication errors.

By enabling the Admin user setting, Azure creates a service-level user account for the registry with permissions to push and pull images. These credentials can then be referenced securely in your container instance configuration — either through the Azure portal, ARM template, or CLI parameters such as --registry-username and --registry-password.

This configuration allows ACI to authenticate successfully against the ACR and pull the required image (image1) for deployment.

Therefore, enabling the Admin user for the container registry meets the goal of allowing the deployment of the container instance using image1.

The correct service is Azure Load Balancer , specifically an internal load balancer . Microsoft defines the load balancer frontend IP as either public or private, and states that selecting a private IP address creates an internal load balancer. Microsoft also states that an internal load balancer distributes traffic to resources inside a virtual network and that the frontend IPs are not directly exposed to an internet endpoint. This directly satisfies the requirement to distribute inbound traffic from VNet2 to VM1 and VM2 while preventing internet exposure.

Azure Front Door and Azure Traffic Manager are global edge or DNS-based traffic distribution services and are not the correct choice for private, VNet-to-VNet load balancing. Azure Application Gateway can be private, but it is a Layer 7 HTTP/HTTPS application delivery controller; the question asks generically for even distribution of inbound traffic to two VMs through the internal network. The AZ-104 study guide maps this scenario to Implement and manage virtual networking , especially Configure name resolution and load balancing and Configure an internal or public load balancer .

" A resource can only be created in a virtual network that exists in the same region and subscription as the resource. " https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-vnet-plan-design-arm#regions

Box 1: Yes

User1 is a Cloud Device Administrator.

Device2 is Azure AD joined.

Group1 has the assigned to join type. User1 is the owner of Group1.

Note: Assigned groups - Manually add users or devices into a static group.

Azure AD joined or hybrid Azure AD joined devices utilize an organizational account in Azure AD

Box 2: No

User2 is a User Administrator.

Device1 is Azure AD registered.

Group1 has the assigned join type, and the owner is User1.

Note: Azure AD registered devices utilize an account managed by the end user, this account is either a Microsoft account or another locally managed credential.

Box 3: Yes

User2 is a User Administrator.

Device2 is Azure AD joined.

Group2 has the Dynamic Device join type, and the owner is User2.

An Availability Set in Azure is a logical grouping of two or more virtual machines that helps ensure your application remains available during planned maintenance events and hardware failures within Azure datacenters.

According to the Microsoft Azure Administrator (AZ-104) study guide and Azure official documentation, Availability Sets protect your VMs from both:

Hardware failures (through fault domains)

Planned maintenance events (through update domains)

A Fault Domain (FD) represents a group of virtual machines that share a common power source and physical network switch. By default, Azure assigns up to three fault domains per region to distribute resources across different racks or hardware clusters.

An Update Domain (UD) represents a group of virtual machines that can be rebooted together during planned maintenance by Microsoft. Azure never updates or reboots two update domains at the same time, ensuring high availability during maintenance operations.

When you have two VMs (VM1 and VM2) running the same application (App1), you should place them in an Availability Set with at least two update domains. This ensures that when Azure performs planned maintenance (updates to host OS or hypervisor), only one update domain is taken offline, while the other remains operational — maintaining service continuity for App1.

By default, an Availability Set provides 5 update domains and 3 fault domains, but the key requirement here is at least two update domains to ensure that maintenance on one host does not impact the entire application.

Therefore, to keep App1 available during planned maintenance of the hardware hosting VM1 and VM2, the Availability Set must include two update domains so that each VM resides in a separate update domain.