AWS Certified Solutions Architect – Associate (SAA-C03) — Question 659

A company is deploying a new application to Amazon Elastic Kubernetes Service (Amazon EKS) with an AWS Fargate cluster. The application needs a storage solution for data persistence. The solution must be highly available and fault tolerant. The solution also must be shared between multiple application containers.

Which solution will meet these requirements with the LEAST operational overhead?

Answer options

• A. Create Amazon Elastic Block Store (Amazon EBS) volumes in the same Availability Zones where EKS worker nodes are placed. Register the volumes in a StorageClass object on an EKS cluster. Use EBS Multi-Attach to share the data between containers.
• B. Create an Amazon Elastic File System (Amazon EFS) file system. Register the file system in a StorageClass object on an EKS cluster. Use the same file system for all containers.
• C. Create an Amazon Elastic Block Store (Amazon EBS) volume. Register the volume in a StorageClass object on an EKS cluster. Use the same volume for all containers.
• D. Create Amazon Elastic File System (Amazon EFS) file systems in the same Availability Zones where EKS worker nodes are placed. Register the file systems in a StorageClass object on an EKS cluster. Create an AWS Lambda function to synchronize the data between file systems.

Correct answer: B

Explanation

Amazon EFS is a fully managed, highly available, and fault-tolerant network file system that natively supports ReadWriteMany (RWX) access, allowing multiple Amazon EKS pods to share the same storage volume concurrently with minimal setup. Amazon EBS volumes are typically restricted to ReadWriteOnce (RWO) and cannot be easily shared across multiple pods on EKS Fargate, as EBS Multi-Attach has strict limitations and is not supported in this architecture. Using multiple EFS file systems with AWS Lambda synchronization adds excessive and unnecessary operational overhead compared to a single EFS file system.