Microsoft Certified: Azure Administrator AssociateImplement and manage storageMedium
A manufacturing company uses Azure File Sync to synchronize files between an on-premises Windows Server and an Azure file share. They report that changes made to files directly in the Azure file share are not immediately synchronizing back to the on-premises server. Changes made on-premises synchronize quickly. What is the most likely reason for this behavior?
- AThe Azure file share's change detection mechanism is not real-time.
- BAzure File Sync doesn't support bidirectional synchronization.
- CCloud tiering is enabled on the server endpoint.
- DThe Azure File Sync agent on the on-premises server is offline.
Show answer & explanationAnswer & explanation
Correct answer: A. The Azure file share's change detection mechanism is not real-time.
Changes made directly to the Azure file share are not immediately detected by Azure File Sync. The Azure file share's change detection mechanism relies on a scheduled scan (up to 24 hours), which can cause delays in synchronization from the cloud to on-premises.
Why the other options are wrong
- B. Azure File Sync supports bidirectional synchronization; this statement is incorrect.
- C. Cloud tiering manages local cache but does not directly prevent changes from Azure from synchronizing, though it can affect *when* a tiered file is recalled.
- D. If the agent was offline, no synchronization (on-premises to cloud) would occur, which contradicts the scenario.
Azure File Sync Cloud Change Detection
Azure File Sync detects changes made directly to an Azure file share by polling the share on a scheduled basis, which can result in a delay (up to 24 hours) for these changes to synchronize down to on-premises servers.
- Changes on-premises are detected by the File Sync agent in real-time.
- Changes in the cloud are detected by a scheduled polling process.
- This polling can introduce a delay of up to 24 hours for cloud-originating changes.
Memory trick: Cloud Watches, On-Prem Whispers, Sync Happens.