Nail Your AZ-104 Azure Administrator Exam on the First Try

In Microsoft Entra ID (Azure Active Directory), creating guest user accounts for external users involves the B2B collaboration invitation process, not the Bulk create user operation. The Bulk create user feature in the Azure portal is used exclusively for creating member users (internal accounts) within your tenant — users that belong directly to your organization.

The Microsoft Azure Administrator official study guide and documentation specify that to onboard external users (guests), you must invite them using the B2B invitation mechanism. This process creates user objects with userType = Guest in your directory. The correct method to achieve this in bulk is by using the PowerShell cmdlet New-AzureADMSInvitation or Microsoft Graph API to send invitations automatically to all external users listed in your CSV file.

Bulk create user operation does not support adding guest accounts because it doesn’t generate the B2B invitation link or email, which is required for the external user to accept and authenticate using their own identity provider (e.g., Microsoft account, Google, or another Entra tenant).

Therefore, the proposed solution fails to meet the requirement of creating guest accounts for the 500 external users in the contoso.com tenant. The correct solution would be to use PowerShell with the New-AzureADMSInvitation command or the Azure AD portal’s “Invite external users” bulk import option designed specifically for guest creation.

Azure VNet peering is the most common way to connect virtual networks, but in this scenario, VNet1 and VNet2 exist in different Azure AD tenants. Global or cross-tenant peering requires that both VNets be within the same Azure Active Directory tenant.

Because the question specifies that each subscription is associated with a different Azure AD tenant, VNet peering is not supported across tenants.

To establish connectivity between VNets in different tenants, the correct solution is to configure VPN gateways in both virtual networks and create a VNet-to-VNet VPN connection.

This type of connection uses the Azure VPN Gateway service to securely tunnel traffic between the VNets using IPsec/IKE protocols over the Internet.

Changing IP address spaces or moving VNets/subscriptions does not solve the cross-tenant issue securely or efficiently.

Hence, before connecting VNet1 and VNet2, you must provision virtual network gateways in both VNets.

In Azure Network Watcher, there are several diagnostic tools used to troubleshoot network connectivity and security issues.

IP Flow Verify – This feature allows you to test whether a packet is allowed or denied to or from a virtual machine based on Network Security Group (NSG) rules. It helps identify issues with network security configurations such as incorrect ports or blocked traffic.

Connection Troubleshoot – This tool validates whether a connection between a source and destination (such as between two VMs) can be established. It simulates network connectivity paths and identifies where the connection might be failing.

In the given scenario, a user cannot connect using port 33000 between virtual machines in different regions. The correct diagnostic steps would involve verifying whether the port is being blocked by an NSG (using IP Flow Verify) and testing end-to-end connectivity (using Connection Troubleshoot).

According to Azure Network Watcher documentation:

“Use IP Flow Verify to determine if a packet is allowed or denied by an NSG rule.”

“Use Connection Troubleshoot to check direct or peered network connectivity between virtual machines and analyze network path issues.”

Both tools provide complementary diagnostics to determine whether network traffic is correctly permitted or blocked.

In Azure Monitor, when an alert rule triggers, an alert instance is created. Each alert has a state and a user response status that helps track its lifecycle. The alert state (such as Fired or Resolved) reflects the current condition of the monitored resource, while the user response (such as New, Acknowledged, or Closed) indicates the operator’s handling of the alert.

According to the Microsoft Azure Administrator study guide and official Azure Monitor documentation, once an alert has been closed, it enters a terminal state where no further status modifications are permitted — this is by design to preserve operational tracking integrity. Therefore, Alert1, whose user response is “Closed,” cannot be changed.

For Alert2, which is in a “New” state, the response can be updated as part of the triage workflow. Administrators can manually change the alert’s user response to Acknowledged (indicating investigation is underway) or to Closed (indicating the issue is resolved).

This structure aligns with best practices outlined in the Azure Monitor alert lifecycle management documentation, ensuring consistent tracking, accountability, and auditability across alert operations.

Final Verified Answers:

Alert1 (User response): cannot be changed

Alert2 (User response): can be changed to Acknowledged or Closed ✅

https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/configure-public-ip-firewall Azure Firewall is a cloud-based network security service that protects your Azure Virtual Network resources. Azure Firewall requires at least one public static IP address to be configured. This IP or set of IPs are used as the external connection point to the firewall. Azure Firewall supports standard SKU public IP addresses. Basic SKU public IP address and public IP prefixes aren ' t supported.

✅ Yes, Yes, No

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.

Azure role-based access control (Azure RBAC) for Azure file shares requires identity-based authentication integration. According to the Microsoft Azure Administrator documentation, this feature is only supported for StorageV2 (general purpose v2) and FileStorage account types.

In this scenario:

You are required to grant Group4 read-only access using Azure RBAC on Azure file shares.

The technical requirement specifies:

“Whenever possible, grant Group4 Azure RBAC read-only permissions to the Azure file shares.”

From the case study data:

Storage Account

Kind

Identity-based Access

storage1

Storage (general purpose v1)

Azure AD DS

storage2

StorageV2

Disabled

storage3

BlobStorage

N/A

storage4

FileStorage

Azure AD DS

The Storage (general purpose v1) type (storage1) does not support Azure AD or Azure RBAC integration for file shares. Microsoft documentation clearly states that “StorageV1 accounts must be upgraded to StorageV2 to support Azure AD authentication and RBAC role assignments.”

Meanwhile, FileStorage (storage4) already supports Azure AD Domain Services (Azure AD DS) and RBAC role assignment; hence no further modification is required there. However, to make storage1 compatible, it must be converted from StorageV1 to StorageV2.

Once converted to StorageV2, you can then:

Enable identity-based access for Azure file shares.

Assign Azure RBAC roles (e.g., Storage File Data Reader) to Group4.

Microsoft-Documented Requirements Summary:

Supported Account Types: StorageV2 or FileStorage

Unsupported: StorageV1 and BlobStorage

Required RBAC Roles for Read-Only Access:

Storage File Data Reader (or custom read-only role)

Thus, to meet the organization’s requirement to provide Azure RBAC read-only permissions, you must change the account type of storage1 to StorageV2, ensuring both storage1 and storage4 can be managed with Azure RBAC.

1️⃣ Create a Log Analytics workspace.

2️⃣ Collect Windows performance counters from the Log Analytics agents.

3️⃣ Create an alert rule.

The question states:

“You need to configure the alerts for VM1 and VM2 to meet the technical requirements.”

The technical requirement from the case study specifies:

“Trigger an alert if VM1 or VM2 has less than 20 GB of free space on volume C.”

This requirement involves monitoring performance metrics (disk space) and generating alerts based on those metrics. According to Microsoft Azure monitoring and management documentation, the process to configure such alerts involves using Azure Monitor and Log Analytics.

Step-by-Step Verified Solution:

Step 1: Create a Log Analytics workspace

A Log Analytics workspace is required to store and analyze logs and performance data collected from virtual machines.

Azure Monitor uses this workspace as the central repository for performance counters, events, and logs from connected agents.

From the Microsoft Documentation:

“Before you can collect and query data from virtual machines, you must create a Log Analytics workspace in your subscription.”

(Source: Azure Monitor and Log Analytics Guide)

Step 2: Collect Windows performance counters from the Log Analytics agents

After creating the workspace, you must connect VM1 and VM2 to the workspace and configure the Windows performance counters that you want to monitor.

In this case, you would collect the LogicalDisk(%) Free Space counter for C: drive.

Azure Monitor agent or Log Analytics agent collects these metrics and sends them to the workspace for analysis.

“To monitor system performance, configure the agent to collect performance counters such as available memory or free disk space.”

(Source: Azure Monitor Performance Counters Documentation)

Step 3: Create an alert rule

Once performance data is being collected, you can create an alert rule in Azure Monitor based on a Kusto query or metric threshold.

You would define a condition such as:

LogicalDisk | where FreeSpaceMB < 20480

and configure it to trigger an alert when free space on volume C drops below 20 GB.

This alert can notify via email, action group, or automation runbook.

“Alerts in Azure Monitor proactively notify you when important conditions are found in your monitoring data. Alerts can trigger automated actions or notifications.”

(Source: Azure Monitor Alerts Overview)

Incorrect Options (Eliminated):

Configure the Diagnostic settings:

Used for collecting activity logs or resource logs, not performance counters from VMs.

Create an Azure SQL database:

Not relevant to the scenario of monitoring disk space.