Skip to main content

Technical Lab: Create and configure a file share in Azure Files

Questions​

Question 1 — Multiple Choice​

A team of administrators needs to mount an Azure Files share on local Windows Server 2019 servers using the SMB protocol. Port 445 is blocked in the corporate firewall and cannot be opened.

Which approach allows the share to be mounted without changing existing firewall rules?

A) Use the NFS 4.1 protocol, which operates on a different port and is natively supported on Windows Server 2019.

B) Configure Azure Files with a private endpoint and route traffic via VPN or ExpressRoute, encapsulating SMB within the tunnel.

C) Enable Azure File Sync on the local server, which replaces direct share mounting and doesn't depend on port 445.

D) Migrate the storage account to the Premium tier (FileStorage), which offers SMB over HTTPS support on port 443.

Question 2 — Technical Scenario​

An administrator creates an Azure Files share with the following configurations:

Storage Account: storprod01
Tier: Transaction optimized (GPv2)
Quota: 100 GiB
Authentication: Storage Account Key

After mounting the share on a Windows VM in Azure, the administrator notices they cannot set granular NTFS permissions on files and folders. Directories and files inheriting from the share ignore ACLs configured via Windows Explorer.

What is the root cause of this behavior?

A) The GPv2 storage account doesn't support NTFS attributes; it's necessary to migrate to the Premium (FileStorage) tier.

B) Authentication via storage account key doesn't provide a security identity to apply user-based ACLs; it's necessary to enable authentication via Microsoft Entra ID or Active Directory Domain Services.

C) The 100 GiB quota is below the minimum required to activate NTFS permissions support in Azure Files.

D) SMB 2.1 protocol is being negotiated between the VM and the share; it's necessary to force SMB 3.0 for NTFS ACLs to be respected.

Question 3 — True or False​

An Azure Files share created in a storage account with soft delete enabled can have its data recovered even after the share is explicitly deleted, as long as the configured retention period hasn't expired yet.

True or False?

Question 4 — Technical Scenario​

An organization uses Azure File Sync to synchronize an Azure Files share with local file servers. After a few months, administrators notice that rarely accessed files appear as offline on local servers, but remain accessible to users without error.

What explains this behavior and which Azure File Sync feature is in operation?

A) Files were corrupted and Windows marked them as offline; Azure File Sync automatically rehydrates them from Azure Files when users try to open them.

B) The cloud tiering feature is active, moving rarely accessed files to Azure Files and leaving only a reparse point locally; the file is rehydrated on demand when accessed.

C) The Azure File Sync agent has synchronization issues and offline files represent version conflicts pending manual resolution.

D) The local server is out of disk space and Azure File Sync paused synchronization, displaying files as offline until space is freed.

Question 5 — Multiple Choice​

An administrator needs to choose the correct Azure Files share tier for a database application that requires single-digit millisecond latency and operates with high volume of I/O operations per second (IOPS).

Which combination of storage account tier and share tier meets this requirement?

A) General Purpose v2 (GPv2) with Hot tier.

B) General Purpose v2 (GPv2) with Transaction Optimized tier.

C) FileStorage (Premium) with Premium file shares type.

D) General Purpose v1 (GPv1) with Cool tier.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Blocking port 445 is a classic obstacle for direct SMB mounting. The correct solution is to combine a private endpoint with private connectivity (Site-to-Site VPN or ExpressRoute): SMB traffic travels encapsulated within the tunnel, without needing port 445 to be open on the internet or corporate firewall.

The main misconceptions in the distractors:

  • Option A is false because NFS 4.1 in Azure Files doesn't have native support on Windows Server, and besides doesn't directly solve the blocked port problem for SMB.
  • Option C confuses Azure File Sync with share mounting: File Sync synchronizes content but doesn't replace direct share access and still uses SMB internally.
  • Option D is a serious technical misconception: SMB over HTTPS on port 443 doesn't exist in Azure Files; SMB operates exclusively on port 445.

Answer Key — Question 2​

Answer: B

NTFS permissions in Azure Files depend on a recognizable security identity to be associated with ACLs. When authentication is done exclusively via storage account key, access occurs as an anonymous and privileged identity, without linking to a security principal (user or group). For NTFS ACLs to work, identity-based authentication must be enabled: Active Directory Domain Services (local AD DS) or Microsoft Entra Domain Services.

The other distractors represent common confusions:

  • Tier (A) and quota (C) have no relation to NTFS ACL support.
  • SMB version (D) affects encryption and performance features, not NTFS permission application.

Answer Key — Question 3​

Answer: True

Soft delete for Azure Files works as a protection layer against accidental deletion. When enabled on the storage account, a deleted share enters retention state for the configured period (between 1 and 365 days) and can be restored via portal, CLI, or API before the deadline expires. This behavior is analogous to blob soft delete, but applied at the share level.

The non-obvious point here is that explicit deletion by the administrator doesn't bypass protection: soft delete acts independently of how deletion was triggered, whether by graphical interface, CLI, or SDK.

Answer Key — Question 4​

Answer: B

Cloud tiering is an Azure File Sync feature that monitors file access frequency and, when the local volume reaches the configured free space threshold, moves less-accessed files to Azure Files, replacing them locally with a reparse point (a symbolic pointer). The file appears as offline in file explorer, but when opened, the File Sync agent transparently rehydrates it from the cloud, without error for the user.

The other distractors represent real situations, but different ones:

  • Option A describes corruption, which would generate errors, not transparent access.
  • Option C describes synchronization conflicts, which would result in duplicate files with conflict suffix, not silent offline files.
  • Option D describes a pause due to lack of space, which would prevent bidirectional synchronization, not displaying files as offline with functional access.

Answer Key — Question 5​

Answer: C

The Premium file shares tier, available exclusively on FileStorage account types, is the only one that guarantees single-digit millisecond latency with consistent IOPS. This tier uses SSDs as backend and is dimensioned based on the provisioned share size, not actual consumption.

The tiers available on GPv2 accounts (Hot, Cool, Transaction Optimized) use HDDs and are optimized for cost and transaction volume, not for low latency and high IOPS. The GPv1 account (option D) is considered legacy and offers no advantage over GPv2 for this scenario.

The most common confusion is associating "Transaction Optimized" with high I/O performance, when in reality this tier minimizes cost per transaction in workloads with many small operations, without latency guarantees.