SAA-C03 Design Resilient Architectures Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Amazon EFS with mount targets in multiple Availability Zones

  Why this is correct

  Amazon EFS is a fully managed, regional file storage service that provides a standard POSIX file system interface (NFSv4.1) for EC2 instances. By configuring mount targets in multiple Availability Zones, instances across the VPC can concurrently read and write to the same file system with shared file locking and metadata guarantees. This architecture delivers both high availability and elastic scalability, making it the appropriate shared storage layer for a warehouse integration service that must be accessed by multiple compute resources simultaneously.

• ✗

  S3 mounted as a POSIX file system without a file gateway

  Why it's wrong here

  Amazon S3 is an object storage service, not a file system, and it does not expose the POSIX file operations (e.g., open, read/write with byte-range locks, rename, append) that an NFS or SMB mount provides. While utilities like s3fs can attach S3 buckets as a 'file system' via FUSE, this is a non-native user-space shim that lacks true file-locking semantics and often suffers from latency and caching complexity. Without AWS Storage Gateway File Gateway to bridge the NFS/SMB protocol, S3 does not offer a dependable POSIX shared-file experience, so this option falls short.

• ✗

  Instance store volumes

  Why it's wrong here

  Instance store volumes are temporary, block-level storage physically attached to the host server that runs the EC2 instance. They are ephemeral by design: data is lost when the instance is stopped, terminated, or if the underlying disk fails. Furthermore, each instance store volume is dedicated to a single instance and cannot be mounted or shared across multiple instances, so it cannot serve as a common, durable repository for a warehouse integration service that requires concurrent shared access.

• ✗

  An EBS volume attached to all instances

  Why it's wrong here

  A standard Amazon EBS volume is created in one Availability Zone and can be attached to only one EC2 instance at a time, so it cannot be accessed as shared file storage by a fleet of instances. Even using EBS Multi-Attach (available only for certain io1/io2 volumes on Nitro instances) merely exposes raw block devices to multiple instances, requiring a cluster-aware file system like OCFS2 or GFS2 and still lacks the managed file-level locking and POSIX semantics of EFS. For general shared file workloads, EBS is designed for single-instance use, making this option invalid.

Go deeper

Related to this question