Migrate a Linux CMS site to Elastic Beanstalk with EFS and a separate Aurora MySQL

Select existing workloads and processes for potential migration. Design a strategy to meet reliability requirements.

Answer Correct answer: A — Use EFS mounted through .ebextensions on Elastic Beanstalk behind an ALB and Auto Scaling group, with a separate Aurora MySQL database.

A company needs to migrate its website from an on-premises data center to AWS. The website consists of a load balancer, a content management system (CMS) that runs on a Linux operating system, and a MySQL database. The CMS requires persistent NFS-compatible storage for a file system. The new solution on AWS must be able to scale from 2 Amazon EC2 instances to 30 EC2 instances in response to unpredictable traffic increases. The new solution also must require no changes to the website and must prevent data loss. Which solution will meet these requirements?

Create an Amazon Elastic File System (Amazon EFS) file system. Deploy the CMS to AWS Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group. Use .ebextensions to mount the EFS file system to the EC2 instances. Create an Amazon Aurora MySQL database that is separate from the Elastic Beanstalk environment. Correct Answer
Create an Amazon Elastic Block Store (Amazon EBS) Multi-Attach volume. Deploy the CMS to AWS Elastic Beanstalk with a Network Load Balancer and an Auto Scaling group. Use .ebextensions to mount the EBS volume to the EC2 instances. Create an Amazon RDS for MySQL database in the Elastic Beanstalk environment.
Create an Amazon Elastic File System (Amazon EFS) file system. Create a launch template and an Auto Scaling group to launch EC2 instances to support the CMS. Create a Network Load Balancer to distribute traffic. Create an Amazon Aurora MySQL database. Use an EC2 Auto Scaling scale-in lifecycle hook to mount the EFS file system to the EC2 instances.
Create an Amazon Elastic Block Store (Amazon EBS) Multi-Attach volume. Create a launch template and an Auto Scaling group to launch EC2 instances to support the CMS. Create an Application Load Balancer to distribute traffic. Create an Amazon ElastiCache for Redis cluster to support the MySQL database. Use EC2 user data to attach the EBS volume to the EC2 instances.

Community Votes

100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Only EFS provides the NFS shared mount the CMS requires across an Auto Scaling group, and .ebextensions mounts it at instance launch so scaling out automatically attaches the file system to every new instance.

An on-premises load balancer, Linux CMS, and MySQL database must move to AWS. The CMS needs persistent NFS-compatible shared storage, the site must scale from two to thirty instances without changes, and the solution must prevent data loss.

Trying to attach shared storage with an Auto Scaling scale-in lifecycle hook. Mounting EFS is a startup action, so it belongs in the launch process via .ebextensions, not in a lifecycle hook that fires when an instance is being removed.

Community Discussion (10 comments)

AzureDP900 👍 1

Option A involves creating an Amazon Elastic File System (Amazon EFS) file system, which provides a highly available and scalable file system that can be accessed by multiple EC2 instances. Deploying the CMS to AWS Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group will allow the website to scale from 2 EC2 instances to 30 EC2 instances in response to unpredictable traffic increases, meeting the first requirement. The use of EFS ensures that the file system is preserved across instance replacements or terminations during scale-in operations, preventing data loss.

spencer_sharp 👍 4 Selected: A

C is wrong because lifehook cannot mount EFS

VerRi 👍 2 Selected: A

B and D are out because NFS->EFS C scale-in lifecycle hook to mount the EFS?????

yog927 👍 1 Selected: A

A is correct

pangchn 👍 3 Selected: A

A EBS is out first. For C, the NLB is weired but couldn't say its wrong. The scale-in policy to mount EFS is wrong, since mounting task should happens during scale-out process.

lasithasilva709 👍 2 Selected: A

B and D are out because Amazon EBS is not NFS-compatible C is out because scale-in lifecycle hook triggers when the instance is about to terminate - no point of mounting the EFS file system here References: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html

ahmadraufsyahputra 👍 2

A because I think Network Load Balancer is not the answer for this case

Dgix 👍 1 Selected: A

B and D are out because of EBS Multi-Attach volumes not working across AZs and have a max number of 16 instances in one zone. A is the correct answer because of no code changes (yes!). C is not optimal because of the NLB which isn't optimal as it doesn't support HTTP/HTTPS as such, working on the TCP level and doesn't do path-based routing. Also, having to set up autoscaling explicitly adds overhead. Therefore, A.

CMMC 👍 1 Selected: C

Change to #C since #A could involve website changes

CMMC 👍 1 Selected: A

EFS for persistent storage, Beanstalk for deploying with ALB and auto-scaling

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Amazon EFS is an NFS file system that many instances can mount at once, which satisfies the CMS requirement and eliminates the data loss risk of instance-local storage. Deploying the CMS to Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group provides the required scaling, and.ebextensions commands run on every instance launch to mount the EFS file system. The Aurora MySQL database is created outside the Elastic Beanstalk environment so that it survives environment replacements and swapouts.

Why the Other Options Are Wrong

B: The CMS requires NFS-compatible storage and EBS is not NFS-compatible, so an EBS Multi-Attach volume cannot be mounted as the CMS file system. C: A scale-in lifecycle hook fires when an instance is being terminated, so using it to mount EFS is logically inverted, mounting must happen when the instance starts. D: ElastiCache for Redis is an in-memory cache and cannot support a MySQL database, and EBS Multi-Attach is again not NFS.

Community Comment Notes

The community voted 93 to 3 for A. The main pushback on C was that a lifecycle hook cannot mount a file system, since mounting belongs to the scale-out path rather than the scale-in path.

Official Reference

https://docs.aws.amazon.com/efs/latest/ug/what-is-efs.html

Related Analysis

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide