Courseiva
Design High-Performing ArchitecturesmediumMultiple ChoiceObjective-mapped

SAA-C03 Design High-Performing Architectures Practice Question

A media processing service runs ECS tasks in multiple Availability Zones. Each task must read and write the same shared filesystem with low latency because tasks stream intermediate artifacts to other tasks. The team currently mounts an EBS volume per task, and cross-AZ tasks frequently cannot see each other’s files. Which option best resolves the shared filesystem requirement while supporting high-performing access?

⚠ Common exam trap

Candidates often assume EBS multi-attach works across Availability Zones, but it is strictly limited to a single AZ and requires specific instance types, making it unsuitable for multi-AZ shared filesystem requirements.

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

Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.

Amazon EFS provides a fully managed, shared NFS filesystem that can be mounted concurrently by ECS tasks across multiple Availability Zones with low latency. It supports POSIX file operations, making it ideal for streaming intermediate artifacts between tasks. EFS mount targets in each AZ ensure local access, meeting the requirement for high-performing shared storage.

Answer analysis

Option-by-option breakdown

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

  • Keep using EBS, but attach the same EBS volume to tasks in multiple Availability Zones using EBS multi-attach so all tasks share the filesystem.

    Why it's wrong here

    EBS volumes are tied to a specific Availability Zone. Even though multi-attach can allow multiple EC2 instances to attach the same EBS volume concurrently (within constraints), it does not create a cross-AZ shared filesystem. Additionally, EBS multi-attach does not provide an NFS-like shared filesystem semantics for concurrent access from tasks as described.

    When this WOULD be correct

    If all ECS tasks are running in the same Availability Zone and require a shared block storage with low latency and consistent performance, EBS multi-attach would be the correct choice for a shared filesystem.

  • Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.

    Why this is correct

    EFS is designed for shared, NFS-like file storage that can be mounted concurrently from compute resources across multiple Availability Zones. By creating mount targets in each AZ used by the ECS tasks, you enable low-latency network access patterns so tasks can read and write the same shared filesystem reliably.

  • Use Amazon S3 for the intermediate artifacts and rely on S3 event notifications to emulate POSIX file operations.

    Why it's wrong here

    S3 is object storage, not a POSIX-style shared filesystem. Even with event notifications, S3 does not provide the same semantics as mounting a directory and performing frequent low-latency reads/writes as tasks stream artifacts to each other.

    When this WOULD be correct

    A question where the requirement is to store and process large volumes of static artifacts with event-driven workflows, and low-latency shared filesystem access is not needed. For example: 'A data pipeline processes uploaded images and triggers a Lambda function to generate thumbnails.'

  • Switch to instance store on each task and use SQS messages between tasks to copy intermediate artifacts.

    Why it's wrong here

    Instance store is ephemeral and not intended for shared, persistent intermediate artifacts across tasks. SQS is a messaging/coordination layer and does not provide filesystem access, so this approach adds copy/serialization overhead and does not meet the shared low-latency filesystem requirement.

    When this WOULD be correct

    A question where tasks need high-speed local scratch storage and can tolerate eventual consistency, such as a batch processing job that processes independent chunks and only needs to aggregate results via a queue.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.Correct answer

Why this is correct

EFS is designed for shared, NFS-like file storage that can be mounted concurrently from compute resources across multiple Availability Zones. By creating mount targets in each AZ used by the ECS tasks, you enable low-latency network access patterns so tasks can read and write the same shared filesystem reliably.

Keep using EBS, but attach the same EBS volume to tasks in multiple Availability Zones using EBS multi-attach so all tasks share the filesystem.Wrong answer — click to see why

Why this is wrong here

EBS multi-attach does not support attaching a single volume to instances across different Availability Zones; it only works within a single AZ. Therefore, cross-AZ tasks cannot share the same EBS volume.

★ When this WOULD be the correct answer

If all ECS tasks are running in the same Availability Zone and require a shared block storage with low latency and consistent performance, EBS multi-attach would be the correct choice for a shared filesystem.

Why candidates choose this

Candidates may think EBS multi-attach provides cross-AZ sharing similar to EFS, but they overlook the single-AZ limitation of EBS multi-attach.

Use Amazon S3 for the intermediate artifacts and rely on S3 event notifications to emulate POSIX file operations.Wrong answer — click to see why

Why this is wrong here

S3 does not provide a POSIX-compliant shared filesystem with low-latency file locking and immediate consistency needed for streaming intermediate artifacts between tasks; it is an object store, not a filesystem.

★ When this WOULD be the correct answer

A question where the requirement is to store and process large volumes of static artifacts with event-driven workflows, and low-latency shared filesystem access is not needed. For example: 'A data pipeline processes uploaded images and triggers a Lambda function to generate thumbnails.'

Why candidates choose this

Candidates may think S3 can serve as a shared filesystem due to its durability and event notifications, overlooking the need for low-latency POSIX semantics and concurrent file access.

Switch to instance store on each task and use SQS messages between tasks to copy intermediate artifacts.Wrong answer — click to see why

Why this is wrong here

Instance store is ephemeral and not shared across tasks, so tasks in different AZs cannot access a common filesystem. SQS message copying adds latency and complexity, failing the low-latency shared filesystem requirement.

★ When this WOULD be the correct answer

A question where tasks need high-speed local scratch storage and can tolerate eventual consistency, such as a batch processing job that processes independent chunks and only needs to aggregate results via a queue.

Why candidates choose this

Candidates may think instance store offers high performance and SQS can coordinate file transfers, overlooking that instance store is ephemeral and not shared, and that SQS cannot provide a POSIX filesystem.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.