Microsoft Updated AZ-104 Exam Questions and Answers by aayan

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.

The provided ARM template defines a storage account named storageaccount1 of kind StorageV2 and SKU Standard_LRS.

1️⃣ Public IP Access (Yes):

In the template, the networkAcls property sets " defaultAction " : " Allow " , meaning that access to the storage account is open to all public networks by default. Since no ipRules or virtualNetworkRules are defined, there are no restrictions based on IP addresses. Therefore, any server — including one with public IP 131.107.103.10 — can connect successfully.

(Reference: Azure Storage firewall and virtual network documentation — when defaultAction is Allow, storage accepts all incoming requests over the public endpoint.)

2️⃣ Archive Tier Availability (Yes):

Because the storage account is of kind StorageV2, it supports blob access tiers — Hot, Cool, and Archive — at both the account and individual blob levels. The ARM template specifies " accessTier " : " Hot " , which is the default access tier for the account. However, this does not restrict individual blobs from being set to a different tier (e.g., Archive) later. Azure Blob Storage in a StorageV2 account allows per-blob tiering, enabling you to optimize costs based on access patterns.

(Reference: Azure Storage documentation — " Blob storage lifecycle management " and " Blob access tiers overview. " )

3️⃣ Azure AD Authentication for File Shares (No):

The ARM template enables encryption and HTTPS but does not configure Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files. Global administrators in Azure AD cannot access SMB file shares using their Azure AD credentials unless Azure Files AD DS integration is explicitly configured. Since no such property (e.g., azureFilesIdentityBasedAuthentication) exists in this template, access would still require storage account keys or shared access signatures (SAS), not Azure AD credentials.

(Reference: Azure Files authentication overview — Azure AD DS authentication requires explicit configuration.)

✅ Final Verified Answers:

A server that has public IP 131.107.103.10 can access storageaccount1 → Yes

Individual blobs in storageaccount1 can be set to use the archive tier → Yes

Global administrators in Azure AD can access a file share hosted in storageaccount1 by using their Azure AD credentials → No

Never

Never