SAP-C02 Design for New Solutions Practice Question

A company runs a stateless REST API on six Amazon EC2 instances in a single Availability Zone behind a Network Load Balancer (NLB). The API writes uploaded files to a shared POSIX file system that must remain accessible from every instance. The company wants to make the architecture resilient to an Availability Zone failure with the least operational effort. Which solution should a solutions architect recommend?

⚠ Common exam trap

The trap here is assuming that EBS Multi-Attach provides a cross-Availability-Zone shared file system, when it is limited to a single zone and to block-level access.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Deploy an Amazon EFS file system with mount targets in at least two Availability Zones, and launch EC2 instances in an Auto Scaling group across those same Availability Zones.

A shared POSIX file system that survives an Availability Zone loss is delivered by Amazon EFS with mount targets in multiple zones, combined with an Auto Scaling group that spans those zones. This is fully managed, requires no replication logic, and keeps the existing Linux application unchanged, which satisfies the resilience goal with the least operational effort.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Deploy an Amazon EFS file system with mount targets in at least two Availability Zones, and launch EC2 instances in an Auto Scaling group across those same Availability Zones.
Why this is correct
Amazon EFS is a fully managed, multi-AZ POSIX file system that mounts concurrently on Linux EC2 instances in every Availability Zone where a mount target exists. Spreading the Auto Scaling group across the same zones removes the single-AZ failure domain without requiring the company to build or replicate any file-system layer, which matches the least-operational-effort requirement.
✗
Store the files in an Amazon S3 bucket in the same Region and use the AWS CLI to synchronize the bucket to local instance store volumes on each EC2 instance.
Why it's wrong here
S3 is object storage and does not expose a POSIX interface, so an application expecting file-system semantics would need code changes. Instance store volumes are ephemeral and tied to the physical host, so a stopped or replaced instance loses its synchronized copy, and the company must build and operate the sync tooling itself.
✗
Create an Amazon FSx for Windows File Server file system in one Availability Zone and configure AWS DataSync to copy files to a second file system hourly.
Why it's wrong here
FSx for Windows File Server speaks SMB, not POSIX, so Linux instances mounting it natively is not supported. An hourly DataSync copy also leaves up to an hour of uploaded files missing after a failover, and the company would have to manage failover and remount logic itself, adding operational effort instead of removing it.
✗
Attach an Amazon EBS io2 Block Express volume to all six EC2 instances and enable EBS Multi-Attach so every instance reads and writes the same volume.
Why it's wrong here
EBS Multi-Attach permits a single io1 or io2 volume to attach to multiple Nitro instances in one Availability Zone only, so it cannot survive an AZ failure. It also provides a raw block device rather than a shared POSIX file system, so concurrent writes from six instances would corrupt data unless a cluster file system is layered on top.

Go deeper

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question