4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Design migrations
Silverbeck Architects has 20 TB of project files on a Windows Server file server at its head office. Staff at the head office must continue to open files from the same server with LAN performance, branch offices need the same share served locally, and the full data set must live in Azure Files as the authoritative copy with Azure Backup protecting it. Only recently used files should occupy local disk, because the head-office server has 4 TB of storage.
Which solution should you recommend?
- AAzure File Sync with the head-office server and each branch server as endpoints in one sync group, with cloud tiering enabledFile Sync keeps Azure Files as the authoritative copy, caches the share on each Windows Server endpoint for LAN performance, and cloud tiering keeps only hot files local so a 4 TB server can serve a 20 TB namespace.
- BAzure Storage Mover to copy the share to Azure Files, then map the Azure Files share directly from each officeStorage Mover is a one-way migration tool; after the copy, users would access the share over the WAN with no local cache, which fails the LAN-performance requirement.
- CAzure Data Box to seed Azure Files, then point users to the cloud shareData Box seeds data but provides no ongoing synchronization or local cache, so head-office performance would drop and the server would no longer be used.
- DA scheduled AzCopy sync job from the file server to Azure Files every nightA one-way nightly copy does not make Azure Files authoritative, does not distribute the share to branches, and cannot tier cold files off the 4 TB server.
Why: The requirements for a continued on-premises cache, multi-site access to one share, Azure Files as the source of truth, and local disk smaller than the data set describe Azure File Sync with cloud tiering. The other tools are migration or seeding mechanisms: Storage Mover and Data Box move data once, and AzCopy copies on a schedule, but none of them keeps a local cache in sync. On the exam, keep local performance plus tiering is the clue that separates File Sync from one-time transfer tools.
Design migrations
Cobalt Dental operates 350 virtual machines on VMware vSphere. Before migrating, the company must inventory the VMs, collect four weeks of CPU, memory, and disk performance data to right-size Azure VM SKUs, and map which servers talk to each other so that application groups can move together. Security policy forbids installing agents on the production VMs, and the company wants a single tool for discovery and assessment.
What should you recommend?
- ADeploy the Azure Migrate appliance on vSphere, run agentless discovery and dependency analysis, and create a performance-based assessmentThe Azure Migrate appliance discovers VMware VMs through vCenter without guest agents, collects performance history for performance-based sizing, and agentless dependency analysis maps server connections from VMware tools data.
- BInstall the Azure Monitor Agent on every VM and use the Service Map solution in Log Analytics to build dependenciesThis requires installing an agent on each VM, which the security policy forbids, and it does not produce Azure sizing assessments.
- CExport the vCenter inventory to CSV and import it into Azure Migrate for an as-on-premises assessmentCSV import gives an inventory-based assessment with no performance history or dependency mapping, so it cannot right-size or group servers.
- DEnable Azure Site Recovery replication for all VMs and use its sizing recommendationsSite Recovery is a replication and disaster recovery service that provides neither dependency visualization nor performance-based VM assessment.
Why: Azure Migrate is the discovery and assessment hub, and for VMware the appliance performs everything agentlessly by talking to vCenter: inventory, performance collection, and dependency analysis. The agent-free constraint rules out the Log Analytics approach, and the need for four weeks of utilization rules out an import-only assessment. Site Recovery is a plausible distractor because it was historically used for migration, but it is not an assessment tool.
Design migrations
Wexley Pharmaceuticals runs a 4 TB SQL Server 2019 Enterprise database on-premises that uses transparent data encryption, linked servers, and the SQL Server Agent. The company wants to move to a PaaS service with near-100-percent compatibility, keep the source database online during the initial data copy, and cut over in minutes. A 1 Gbps ExpressRoute circuit is in place. Minimizing changes to the application is the deciding factor.
Which database migration solution should you recommend?
- AMigrate to Azure SQL Database Hyperscale using a transactional replication publicationAzure SQL Database does not support linked servers or SQL Server Agent, so the application would need changes that the scenario wants to avoid.
- BMigrate to Azure SQL Managed Instance using the Managed Instance link, then fail over to complete the cutoverManaged Instance link uses distributed availability group technology to replicate online from SQL Server 2019 to a Managed Instance that supports TDE, linked servers, and Agent, giving a cutover of minutes with no application changes.
- CMigrate to SQL Server on an Azure virtual machine by shipping a full backup on Azure Data BoxSQL on a VM is IaaS rather than PaaS, and a shipped backup means a cutover that includes applying days of log backups rather than minutes of delta.
- DMigrate to Azure Database for PostgreSQL flexible server using the Azure Database Migration Service schema conversionChanging the database engine forces application rewrites, which directly contradicts the minimize-changes requirement.
Why: Azure SQL Managed Instance is the PaaS target with near-complete SQL Server surface-area compatibility, including instance-level features such as Agent, linked servers, and TDE. For an online migration with minimal downtime from SQL Server 2016 and later, the Managed Instance link streams changes continuously so that cutover is a planned failover of minutes. Hyperscale is a tempting choice because of the 4 TB size, but Azure SQL Database lacks the instance-scoped features, and VM or engine-change options break the PaaS or minimal-change constraints.
Design migrations
Northgate Imaging must move a 600 TB archive of medical images from an on-premises NAS to Azure Blob Storage. The site has a 200 Mbps internet connection that is shared with daily operations, the archive is static and no longer written to, and the transfer must complete within six weeks. The data must be encrypted while in transit to Azure.
Which data transfer solution should you recommend?
- AAzCopy running on a server at the site, copying directly to the storage accountAt 200 Mbps shared with production, 600 TB would take many months to transfer over the network, which misses the six-week deadline.
- BAzure Data Box devices shipped to the site, loaded locally, and returned to Microsoft for uploadData Box provides offline, AES-256-encrypted physical transfer that is sized for hundreds of terabytes, so a static archive can be loaded over the LAN and shipped within the deadline regardless of internet bandwidth.
- CAzure File Sync with cloud tiering on the NASFile Sync requires a Windows Server endpoint, targets Azure Files rather than Blob Storage, and still moves all data over the same slow internet link.
- DAzure Storage Mover with an agent at the siteStorage Mover is an online migration service and would be constrained by the same 200 Mbps link, so it cannot meet the deadline.
Why: The rule of thumb for unstructured data migration is to compare data size against available bandwidth. When the volume is in the hundreds of terabytes and the link is slow or shared, offline transfer with Azure Data Box is the only way to meet a fixed deadline, and the device encrypts data at rest while in transit. AzCopy and Storage Mover are excellent online tools, and File Sync is for ongoing hybrid file shares, but all three depend on the network that the scenario identifies as the bottleneck.