SAA-C03 Design Resilient Architectures Practice Question

A patient portal must use shared file storage across Linux EC2 instances in multiple Availability Zones. The storage must remain available during an AZ failure. Which service should be used? The architecture review board prefers a managed AWS-native control.

⚠ Common exam trap

Watch out — candidates often confuse EBS multi-attach (which is limited to a single AZ and specific volume types) with the cross-AZ shared file system capability of EFS, or incorrectly assume that mounting S3 as a POSIX file system is a reliable, managed solution for shared storage.

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

✓

Amazon EFS with mount targets in multiple Availability Zones

Amazon EFS provides a fully managed, shared POSIX-compliant file system that can be mounted concurrently across multiple Linux EC2 instances. By creating mount targets in multiple Availability Zones, the file system remains accessible even if one AZ fails, meeting the high-availability requirement. This aligns with the architecture review board's preference for a managed AWS-native control.

Answer analysis

Option-by-option breakdown

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

✗
Instance store volumes
Why it's wrong here
Instance store volumes are ephemeral block storage physically attached to a single EC2 host. Their data persists only as long as the instance is running; stopping, terminating, or a host failure permanently erases the data. Because instance store is exclusive to one instance and tied to a specific Availability Zone, it cannot serve as shared file storage for multiple Linux EC2 instances across AZs.
✓
Amazon EFS with mount targets in multiple Availability Zones
Why this is correct
Amazon EFS is a fully managed, regional NFS file system that provides shared, elastic file storage for Linux EC2 instances. By creating mount targets in each Availability Zone where instances reside, every instance can mount the same file system and read/write concurrently with POSIX semantics, automatic failover, and scalable throughput. This directly satisfies the requirement for shared file storage across multiple Linux EC2 instances in a patient portal.
✗
An EBS volume attached to all instances
Why it's wrong here
A standard EBS volume is a zonal block storage device designed for single-instance attachment; it cannot be attached to all instances simultaneously. Even with EBS Multi-Attach (supported on certain io1/io2 volumes on Nitro instances), the volume stays within one Availability Zone and requires a cluster-aware file system to avoid corruption. Simply attaching one EBS volume to every instance would cause attachment failures and data inconsistency, making it an invalid choice for shared file storage.
✗
S3 mounted as a POSIX file system without a file gateway
Why it's wrong here
S3 is object storage with a flat key-value namespace, not a POSIX file system, and natively lacks features like file locking, directory semantics, and consistent concurrent modification. Tools that mount S3 via FUSE (e.g., s3fs) are not production-safe for shared POSIX workloads because they introduce caching inconsistencies, latency, and limited metadata support. Without a file gateway to translate POSIX operations to S3 API calls, S3 cannot provide the required shared file storage semantics for Linux EC2 instances.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question