Java / Azure Files Interview questions

Azure Files is a fully managed cloud file share service. You create a share in a storage account and access it over SMB, NFS or the REST API, much like a share on a traditional file server.

The same share can be mounted at the same time by Windows, Linux and macOS clients, whether they run in Azure or on-premises. That makes it a common landing spot for lift-and-shift of file servers.

Microsoft runs the underlying servers, so there is no OS to patch, no disks to replace and no cluster to build. You manage the share, its size, its permissions and its network access.

Azure Files supports SMB (2.1, 3.0 and 3.1.1), NFS 4.1 and the FileREST API over HTTPS.

SMB is the usual choice for Windows workloads and identity-based access. NFS targets Linux and Unix workloads that need POSIX semantics. REST is handy for tools such as AzCopy, Storage Explorer and your own code.

A single share is created for either SMB or NFS, never both. REST data-plane operations such as AzCopy transfers apply to SMB shares, while NFS shares are mounted by Linux clients and managed through the management plane, so check the current feature matrix before you rely on REST for NFS.

Azure Files has four tiers. Three are standard (HDD-backed): transaction optimized, hot and cool. One is premium (SSD-backed).

Cooler tiers charge less for storage but more for transactions and access. You can move a standard share between standard tiers without recreating it.

Standard shares can use LRS, ZRS, GRS or GZRS. Premium shares are limited to LRS and ZRS.

• LRS keeps three copies inside one datacenter.
• ZRS spreads three copies across availability zones in one region.
• GRS is LRS plus asynchronous copy to a paired region.
• GZRS is ZRS in the primary region plus asynchronous copy to the paired region.

Pick the level from your recovery goals. If you need geo protection on a premium share, you have to replicate it yourself, for example with AzCopy or Azure File Sync.

The storage account is the management and namespace boundary for your shares. Every share lives inside one, and the account decides the endpoint, the redundancy, the network rules and the authentication settings.

The file endpoint looks like <account>.file.core.windows.net. Settings such as firewall rules, private endpoints, secure transfer, encryption keys and identity-based authentication are applied at the account level and affect every share in it.

Some settings stay per share, for example the quota, the access tier and the protocol (SMB or NFS).

Two account kinds host file shares: FileStorage for premium shares and general-purpose v2 (StorageV2) for standard shares.

A FileStorage account is dedicated to files on SSD media. A general-purpose v2 account can hold file shares next to blobs, queues and tables, which is convenient but means those services share the account's limits and network rules.

You cannot put a premium share in a general-purpose v2 account, and you cannot create standard shares in a FileStorage account.

A standard share defaults to 5 TiB. If you enable large file shares on the account, a share can grow to 100 TiB. Premium shares can also reach 100 TiB.

Limits for IOPS, throughput and file counts change over time, so confirm them in the current Azure Files scalability targets before you size a design.

Use the UNC path \\<account>.file.core.windows.net\<share> and authenticate with the storage account key or an identity-based method. The portal's Connect blade generates the exact script.

cmdkey /add:myacct.file.core.windows.net /user:localhost\myacct /pass:<storage-key>
net use Z: \\myacct.file.core.windows.net\docs /persistent:Yes

The client needs outbound TCP 445 to the account. If your ISP or firewall blocks it, use a VPN, ExpressRoute or a private endpoint.

Install cifs-utils, create a mount point, and mount with the CIFS driver using SMB 3.x. Keep the key in a root-only credentials file instead of on the command line.

1. Install the helper: sudo apt install cifs-utils.
2. Create the folder: sudo mkdir -p /mnt/docs.
3. Store username and password in /etc/smbcredentials/myacct.cred with chmod 600.
4. Mount the share with the command below.

sudo mount -t cifs //myacct.file.core.windows.net/docs /mnt/docs -o credentials=/etc/smbcredentials/myacct.cred,vers=3.1.1,dir_mode=0770,file_mode=0660,serverino

Add the same options to /etc/fstab with _netdev for a persistent mount.

Azure File Sync keeps a Windows Server file share in sync with an Azure file share. The server keeps hot files locally while the full dataset lives in Azure.

It lets you turn a file server into a fast local cache of Azure Files, with optional cloud tiering to save disk space. Several servers in different offices can sync to the same cloud share, so each site sees the same files.

An agent installed on Windows Server does the work, and it talks to Azure over HTTPS.

Azure File Sync has five moving parts: the Storage Sync Service, sync groups, cloud endpoints, server endpoints and the agent on registered servers.

A sync group has exactly one cloud endpoint and can have many server endpoints.

Cloud tiering replaces rarely used files on the server with small pointers while the real content stays in the Azure file share. This frees local disk space without removing anything from the namespace.

Users still see every file. When someone opens a tiered file, the agent recalls the data from Azure on demand. Two policies control tiering: volume free space (keep at least X% free) and date (tier files not accessed for N days).

A share snapshot is a read-only, point-in-time copy of an entire file share. It is incremental, so only changes since the previous snapshot take extra space.

You can have up to 200 snapshots per share. Users can browse them through the Previous Versions tab on Windows, or you can restore single files from the portal, PowerShell or AzCopy. Snapshots live in the same storage account as the share, so they do not replace a separate backup.

Soft delete keeps a deleted file share recoverable for a retention period instead of removing it right away. It protects against accidental deletion of the whole share, not individual files.

It is on by default for new accounts with a 7-day retention, which you can set between 1 and 365 days. During that window you can undelete the share, along with its snapshots, from the portal or CLI.

Azure Files supports storage account keys, shared access signatures (REST only) and identity-based access over SMB using Kerberos.

• Account key: full access to every share in the account. Treat it like a root password.
• SAS token: scoped and time-limited access through REST.
• Identity-based: on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for hybrid identities.

Identity-based access is preferred because it gives per-user permissions and an audit trail.

SMB runs over TCP port 445. A client cannot mount an Azure file share over SMB unless it can reach the storage account on that port.

Many home ISPs, hotels and corporate firewalls block outbound 445 because of old SMB worms. The usual symptom on Windows is System error 53 or 1231. Test it with Test-NetConnection -ComputerName myacct.file.core.windows.net -Port 445.

If it fails, route traffic through a VPN, ExpressRoute or a private endpoint, or use Azure File Sync, which uses HTTPS.

Use Azure Backup. It schedules share snapshots through a backup policy and tracks them in a Recovery Services vault.

1. Create or choose a Recovery Services vault in the same region.
2. Create a backup policy with frequency and retention.
3. Select the storage account and file shares to protect.
4. Run an on-demand backup to verify, then test a restore.

You can restore a full share or individual files, to the original or an alternate location.

SMB Multichannel lets one SMB session use several network connections at once. That raises throughput and keeps the session alive if one connection fails.

It is supported on premium SMB shares with SMB 3.x clients and is enabled by default on FileStorage accounts. The client needs a NIC that supports Receive Side Scaling (RSS) to benefit, which most modern Azure VM sizes do.

It does not apply to NFS shares.

Azure Files is used wherever you need a shared folder without running a file server.

• Lift and shift of on-premises file servers and mapped drives.
• Shared configuration and tools mounted on many VMs.
• FSLogix profile containers for Azure Virtual Desktop.
• Persistent volumes for containers in AKS and Azure Container Instances.
• Hybrid caching with Azure File Sync for branch offices.

It is not a good fit for hosting a relational database engine that expects raw block storage.

Create the storage account first, then the share. The share-rm group uses the Azure Resource Manager API, so no account key is needed.

az storage account create -n myacct -g rg-files -l eastus --sku Standard_LRS --kind StorageV2
az storage share-rm create --storage-account myacct -g rg-files --name docs --quota 1024 --access-tier Hot

--quota is the maximum size in GiB. For a premium share, create a FileStorage account with --sku Premium_LRS and the quota becomes the provisioned size you pay for.

Azure Files exposes a real file system (folders, locks, ACLs) over SMB and NFS. Blob Storage is an object store accessed mainly over HTTPS, with a flat namespace unless you enable hierarchical namespace.

If an application expects a drive letter or a mount path with normal file semantics, pick Files. If it stores huge volumes of unstructured data and talks HTTP, pick Blob.

Standard shares run on HDD and bill mostly on what you use. Premium shares run on SSD, bill on what you provision and give low, consistent latency.

Choose premium when latency or IOPS matter, such as for FSLogix, build agents or databases. Choose standard for general shares and archives.

The model depends on the share type. Standard pay-as-you-go charges for data stored (including snapshots), for transactions in blocks, and for outbound data. Premium charges for provisioned GiB, which also sets your IOPS and throughput.

Within standard, the tier moves the balance: transaction optimized has the lowest transaction price but a higher storage price, while cool is the reverse.

Azure also offers a provisioned v2 billing model, where you set storage, IOPS and throughput independently. Confirm availability and regions in the current pricing page before choosing it.

You enable an identity source on the storage account, assign share-level permissions with Azure RBAC, then set file and folder permissions with Windows ACLs.

1. Pick the source: AD DS, Microsoft Entra Domain Services or Microsoft Entra Kerberos for hybrid identities.
2. Enable it on the account. For AD DS, run Join-AzStorageAccount (AzFilesHybrid module) to create the account object in the domain.
3. Assign an RBAC role such as Storage File Data SMB Share Contributor to a user or group.
4. Mount once with the account key and set NTFS permissions using Explorer or icacls.
5. Mount again using the user's own identity.

Users also need network line-of-sight to a domain controller when the source is AD DS.

Access is checked in two layers, and a user needs both to allow the action. The most restrictive result wins.

Three built-in roles cover most cases: SMB Share Reader, SMB Share Contributor and SMB Share Elevated Contributor. Only the elevated role can change ACLs. A common pattern is to give a group Contributor at share level and then let ACLs narrow access per folder.

Data at rest is always encrypted with 256-bit AES through Storage Service Encryption. You can use Microsoft-managed keys or customer-managed keys held in Azure Key Vault.

In transit, SMB 3.x clients use SMB encryption (AES-128-GCM, and AES-256-GCM with 3.1.1), and REST calls use HTTPS. The account setting Secure transfer required rejects unencrypted connections.

Because SMB 2.1 cannot encrypt, an SMB 2.1 client can only mount from the same Azure region when secure transfer is disabled. Older Windows 7 or Server 2008 R2 clients are the usual cases.

A private endpoint gives the storage account a private IP address inside your virtual network. Traffic to the file service stays on the Microsoft backbone and never crosses the public internet.

You also need DNS to resolve <account>.file.core.windows.net to that private IP, normally through the privatelink.file.core.windows.net private DNS zone. Once it works, you can disable public network access on the account.

Compared with service endpoints, a private endpoint is reachable from on-premises over VPN or ExpressRoute and gets a dedicated address, so it is the preferred choice for hybrid access.

You either avoid SMB over the open internet or use a path that does not depend on port 445.

• VPN or ExpressRoute: reach a private endpoint over a private link, where 445 is not filtered.
• Azure File Sync: the server talks to Azure over HTTPS (443), and users hit the local server.
• REST tools: AzCopy and Storage Explorer use HTTPS.
• Azure VMs: run the workload in Azure so SMB stays inside the network.

Asking the ISP to unblock 445 rarely works, so a VPN is the quickest fix for remote users.

Choose NFS for Linux or Unix workloads that need POSIX permissions, symbolic links and hard links. Choose SMB for Windows clients, identity-based permissions and in-transit encryption.

NFS shares require locking the network down, because access control relies on the VNet rather than a user identity.

Both are managed file services, but they target different tiers of workload. Azure Files is the broad, cost-effective option. Azure NetApp Files is a high-performance service built on NetApp technology for demanding enterprise workloads.

Pick Azure Files first. Move to NetApp Files when you need its sub-millisecond latency, dual-protocol access or specific application certifications.

Choose Azure File Sync when users or apps need local-speed access to files and the link to Azure is slow, shared or unreliable. Choose a direct mount when the clients run in Azure or have a fast, stable connection.

• Branch offices that currently have their own file servers.
• Large datasets where only a small hot subset is used often.
• Several sites that need the same files kept consistent.
• Gradual migration, where the server stays online while data moves to Azure.

File Sync adds a Windows Server to manage, so do not use it if a plain mount over VPN or ExpressRoute meets the latency target.

The agent tracks a heat value per file, based on last access (reads and writes). The coldest files are tiered first.

• Volume free space policy: when free space falls below the target percentage, the agent tiers the least recently accessed files until it reaches the target.
• Date policy: files not accessed within N days are tiered, even if there is plenty of space.
• Both together: a file is tiered when either condition requires it.

Very small files, roughly under 64 KiB, are not tiered, and files must be fully synced to Azure before they are eligible. After setup, the initial download mode decides whether new servers get only the namespace or also file contents.

Pick a copy method based on size and downtime, then move data, permissions and users in that order.

1. Assess: data size, file count, open files, ACL complexity, and bandwidth.
2. Prepare: create the storage account, share and identity configuration.
3. Copy: use Robocopy over SMB, AzCopy over HTTPS, Azure Storage Mover, or Azure File Sync to seed and sync. Use Data Box for very large offline transfers.
4. Cut over: run a final delta pass, then repoint drive mappings or DFS namespaces.

robocopy D:\Data Z:\ /MIR /COPYALL /DCOPY:DAT /MT:16 /R:2 /W:1 /LOG:C:\mig.log

/MIR deletes files in the target that do not exist in the source, so use it carefully.

FSLogix stores each user's profile as a VHD(X) file on an Azure file share. At sign-in, the file is mounted over SMB so the profile looks local to the session host.

Logon time depends on IOPS and latency, especially during a morning logon storm. That is why premium shares in the same region as the session hosts are the usual choice, with identity-based authentication so each user only reaches their own profile.

Set share-level RBAC for the host pool users group, then use NTFS ACLs so each profile folder is private to its owner. Add Cloud Cache only if you need multiple storage locations.

AKS ships with the Azure Files CSI driver. You request a volume with a PersistentVolumeClaim that references a storage class, and AKS creates the share and mounts it into the pod.

Built-in classes include azurefile-csi (standard) and azurefile-csi-premium. Use ReadWriteMany so many pods can use the same volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-data
spec:
  accessModes: [ReadWriteMany]
  storageClassName: azurefile-csi-premium
  resources:
    requests:
      storage: 100Gi

A snapshot is a single point-in-time copy. Azure Backup is the management layer that creates snapshots on a schedule, keeps them according to a policy and records them in a vault.

For anything beyond ad hoc safety copies, use Azure Backup.

With GRS or GZRS, the platform asynchronously copies your data to the paired region, where it is kept in LRS. Writes are acknowledged after they reach the primary, so a recent change can be lost in a disaster.

Unlike blobs, file shares do not offer a read-access secondary endpoint. The secondary is used only after failover. Microsoft can trigger it for a regional outage, and you can start a customer-managed failover on the account.

Check the Last Sync Time property before failing over to understand the possible data loss. After failover the account becomes LRS in the new primary region, and you must reconfigure geo-redundancy.

Use Azure Monitor metrics for quick health checks and diagnostic logs for per-request detail.

• Metrics: Transactions, Ingress, Egress, SuccessE2ELatency, SuccessServerLatency, FileCapacity, Availability. Split by the FileShare and ResponseType dimensions.
• Logs: enable diagnostic settings for the file service and send StorageRead, StorageWrite and StorageDelete to Log Analytics.
• Alerts: notify on throttling responses or when latency or capacity thresholds are crossed.
• Storage insights: a ready-made workbook with trends across accounts.

StorageFileLogs
| where TimeGenerated > ago(1h)
| summarize count() by OperationName, StatusText
| order by count_ desc

When requests exceed the share's IOPS or throughput limit, the service slows or rejects them. Clients see higher latency, and SMB operations may succeed but take longer.

In metrics, filter Transactions by ResponseType. SuccessWithThrottling shows SMB requests that were delayed, and ClientThrottlingError shows REST requests that were rejected.

1. Confirm throttling in metrics.
2. Increase the provisioned size, or move up a tier.
3. Spread load over several shares or accounts.
4. Add retry with backoff and more parallelism in the client.

Small files are dominated by metadata operations: create, open, set attributes and close. Each is a network round trip, so latency matters far more than bandwidth, and a standard HDD share is slowest at this.

• Use premium SSD shares and enable metadata caching where available.
• Copy in parallel with robocopy /MT or AzCopy instead of a single thread.
• Use SMB Multichannel and keep clients in the same region.
• Pack many tiny files into an archive when moving them and extract on the other side.

Measure with a small-file workload, because large-file throughput numbers will not predict this behaviour.

A recall happens when a user or app opens a tiered file. The file looks normal in Explorer, but its content is in the Azure file share, so the agent has to fetch it first.

sequenceDiagram
    participant U as User App
    participant F as Sync Filter Driver
    participant A as Sync Agent
    participant S as Azure File Share
    U->>F: Open tiered file
    F->>A: Request file data
    A->>S: Download over HTTPS
    S-->>A: File content
    A-->>F: Write data to local disk
    F-->>U: Return data to the app

1. The app opens the file and the file system filter driver sees that it is a reparse point.
2. The driver asks the agent to recall the content.
3. The agent downloads it from the cloud endpoint over HTTPS and writes it back to the local volume.
4. The data is returned to the app, and the file is now fully present again.

The file is tiered again later only if the policies select it. Large files can start streaming back before the whole download finishes, and the first-access delay depends on file size and bandwidth.

Azure File Sync detects changes differently on the server and in the cloud, and then reconciles both through sync sessions that upload and download only the changed data.

• Server side: the agent reads the Windows USN change journal on the volume, so local changes are noticed almost immediately and queued for upload.
• Cloud side: changes made directly in the Azure file share are found by a scheduled change detection job, which scans the share about once every 24 hours.
• Sync session: the server uploads its detected changes and downloads changes from the cloud, working through each server endpoint.

Because of the cloud scan interval, a file added straight to the share may not appear on the server for up to a day. You can trigger it sooner with Invoke-AzStorageSyncChangeDetection for a given path.

Start from the portal, then the server, then the network. Work through the layers rather than guessing.

1. In the Storage Sync Service, open the sync group and check the server endpoint health: last sync result, files not syncing and error codes.
2. On the server, open Event Viewer under Applications and Services Logs > Microsoft > FileSync > Agent > Telemetry. Event 9102 summarises each sync session and 9121 reports per-item errors.
3. Run Debug-StorageSyncServer -Diagnose on recent agent versions to check connectivity and registration.
4. Confirm outbound HTTPS 443 access and any proxy settings.
5. Check free disk space, agent version, server time and unsupported file names or open handles.

Fix the cause, then wait for the next session or trigger one. Per-item errors usually clear automatically after a successful retry.

Match the error to its layer: name resolution, network path, authentication or authorization.

Test-NetConnection -ComputerName myacct.file.core.windows.net -Port 445
nslookup myacct.file.core.windows.net

Microsoft also provides the AzFileDiagnostics script for Windows clients. Also check that Secure transfer required matches what the client can do, since SMB 2.1 cannot mount an encrypted-only account.

Remove the storage ceiling first, then remove client and network bottlenecks.

1. Use premium SSD shares and provision enough capacity, because IOPS and throughput scale with provisioned size (a baseline plus a rate per GiB).
2. Increase queue depth and parallelism on the client, since one thread cannot saturate a share.
3. Enable SMB Multichannel and use VM sizes with enough network bandwidth and RSS-capable NICs.
4. Keep the VM and the share in the same region and, if you use ZRS, in a matching zone where possible.
5. Turn on metadata caching for metadata-heavy workloads.
6. Split independent datasets across multiple shares so each has its own limits.

Validate with a tool such as fio or DiskSpd and compare against the Transactions and latency metrics. If the metrics show throttling, increase provisioning rather than tuning the client further.

Start from RPO and RTO, then layer protections, because each one covers a different failure.

Premium shares cannot use geo-redundancy, so cross-region copies must be scheduled by you. Document the runbook: failover, then validate DNS and mounts, reapply private endpoints and firewall rules in the recovery region, and confirm identity configuration works there.

Test the plan with a real restore at least once a year, since an untested backup is only an assumption.

Azure File Sync does not lock files across endpoints. If the same file is changed in two places before a sync, one version wins and the other is kept as a conflict file.

The first change that reaches the sync service keeps the original name. The other is renamed with the endpoint name and a counter, such as Budget-Server02.xlsx or Budget-Server02-1.xlsx, and then synced so that every endpoint ends up with both copies.

Nothing is overwritten silently, but users must merge the content manually. To reduce conflicts, route teams to one endpoint per project, avoid editing the same documents from the cloud share and a server at once, and use a collaboration tool for co-authoring.

Layer controls so that no single setting is the only barrier. For a regulated workload, a solid baseline looks like this.

1. Network: create a private endpoint, add the private DNS zone and set public network access to disabled.
2. Identity: use identity-based SMB access through AD DS or Entra Kerberos, and assign RBAC to groups, not individuals.
3. Keys: disable shared key access where your clients support identity-based access, and rotate keys otherwise.
4. Protocol: require secure transfer and SMB 3.1.1 with AES-256-GCM, and block older SMB versions.
5. Encryption: use customer-managed keys in Key Vault if policy demands key control.
6. Protection: enable soft delete and Azure Backup, and consider Microsoft Defender for Storage for threat detection.
7. Audit: send diagnostic logs to Log Analytics and alert on unusual access.

Document each control against the regulation's requirements so an auditor can trace it.

With AD DS, the storage account is represented by an account object in the domain that holds a service principal name such as cifs/myacct.file.core.windows.net. Clients use that SPN to get a Kerberos service ticket.

sequenceDiagram
    participant C as Domain Joined Client
    participant D as Domain Controller
    participant S as Azure Files
    C->>D: Request ticket for cifs SPN
    D-->>C: Service ticket
    C->>S: SMB session setup with ticket
    S->>S: Validate ticket with account key
    S->>S: Check share-level RBAC
    S->>S: Check NTFS ACLs on access
    S-->>C: Session granted

1. The user signs in and gets a TGT from the domain controller.
2. The client asks for a service ticket for the storage account SPN.
3. The client presents the ticket during SMB session setup.
4. Azure Files validates the ticket, evaluates the RBAC role, then the ACL on each file operation.

The client needs a line of sight to a domain controller, which is why remote users often need a VPN, or Entra Kerberos for hybrid identities.

For most organisations, Azure Files with Azure File Sync is the better default. It removes the clustered storage you have to build and patch, and gives you cloud-based capacity, backup and DR, while the local server still gives LAN speed.

A cluster still makes sense when you must keep all data on-premises for compliance, have no usable internet link, or run apps that need features Azure Files does not offer. Even then, check whether Azure File Sync with a small cache could replace it.