A company hosts a Windows-based file server on a fleet of Amazon EC2 instances across multiple Availability Zones. The current setup does not allow application servers to access files simultaneously…

Question

Options

• ACreate an Amazon Elastic File System (Amazon EFS) Multi-AZ file system. Copy the files to the
• BCreate an Amazon FSx for Windows File Server Multi-AZ file system. Copy the files to the
• CCreate an Amazon Elastic Block Store (Amazon EBS) volume that has EBS Multi-Attach enabled.
• DCreate two Amazon FSx for Windows File Server file systems. Configure Distributed File System

• A
  3% (1)
• B
  84% (32)
• C
  5% (2)
• D
  8% (3)

Explanation

Option B is correct because Amazon FSx for Windows File Server is purpose-built for Windows workloads, supports the SMB protocol that Windows applications require, and its Multi-AZ configuration provides shared, simultaneous access from multiple EC2 instances across Availability Zones - all in a fully managed service with minimal operational overhead.

Option A (EFS) is wrong because Amazon EFS uses NFS protocol and is designed for Linux-based workloads; it does not natively support Windows SMB access, making it incompatible with a Windows file server fleet.

Option C (EBS Multi-Attach) is wrong because EBS Multi-Attach only works within a single Availability Zone and is limited to io1/io2 volume types - it cannot span multiple AZs as the question requires.

Option D (two FSx + DFS) is wrong because while DFS Replication can work, manually configuring and managing two separate file systems with DFS namespaces and replication is significantly more complex - the question asks for the most operationally efficient solution, and a single native Multi-AZ FSx deployment beats it.

Memory tip: "Windows needs Windows" - whenever you see Windows + shared access + multi-AZ, reach for FSx for Windows File Server. Think of EFS as the Linux equivalent of FSx, and EBS as a per-instance disk that can't truly span AZs.

No community discussion yet for this question.