Modernize a three-tier web application with S3 static hosting, Elastic Beanstalk, and Aurora

Determine the optimal migration approach for existing workloads. Determine a new architecture for existing workloads. Design a strategy to meet reliability requirements.

Answer Correct answers: A, C, E — Host static assets on S3 with CloudFront, run the Java tier in Elastic Beanstalk, and replatform to Aurora PostgreSQL with Auto Scaling read replicas.

A company is running a three-tier web application in an on-premises data center. The frontend is served by an Apache web server, the middle tier is a monolithic Java application, and the storage tier is a PostgreSQL database. During a recent marketing promotion, customers could not place orders through the application because the application crashed. An analysis showed that all three tiers were overloaded. The application became unresponsive, and the database reached its capacity limit because of read operations. The company already has several similar promotions scheduled in the near future. A solutions architect must develop a plan for migration to AWS to resolve these issues. The solution must maximize scalability and must minimize operational effort Which combination of steps will meet these requirements? (Choose three.)

Refactor the frontend so that static assets can be hosted on Amazon S3. Use Amazon CloudFront to serve the frontend to customers. Connect the frontend to the Java application. Correct Answer
Rehost the Apache web server of the frontend on Amazon EC2 instances that are in an Auto Scaling group. Use a load balancer in front of the Auto Scaling group. Use Amazon Elastic File System (Amazon EFS) to host the static assets that the Apache web server needs.
Rehost the Java application in an AWS Elastic Beanstalk environment that includes auto scaling. Correct Answer
Refactor the Java application, Develop a Docker container to run the Java application. Use AWS Fargate to host the container.
Use AWS Database Migration Service (AWS DMS) to replatform the PostgreSQL database to an Amazon Aurora PostgreSQL database. Use Aurora Auto Scaling for read replicas. Correct Answer

Community Votes

ACE

100%

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

Community Insight

Each selected option removes a scaling bottleneck without adding management: S3 plus CloudFront absorbs static asset load, Elastic Beanstalk adds auto scaling to the Java tier without cluster operations, and Aurora with Auto Scaling read replicas absorbs the read traffic that saturated the database.

A legacy three-tier stack with an Apache frontend, a monolithic Java middle tier, and a PostgreSQL database collapsed under promotional load. The migration plan must maximize scalability and minimize operational effort, with more promotions already scheduled.

Choosing the rehost options because the promotions are near term. Rehosting the Apache server on Auto Scaling EC2 instances keeps the instances to patch and manage and re-creates the same static asset bottleneck, while refactoring to containers on Fargate is a modernization step the schedule does not allow.

Community Discussion (13 comments)

chris_spencer 👍 3 Selected: ACE

I would preferred container over beanstalk but this are examen questions ACE

wbedair 👍 1

The question says they have incoming campaigns in NEAR future. Doesn't this means Rehost options are better?

backbencher2022 👍 1 Selected: ACE

A, C & E. For A - You can connect S3 with backend Java application. It is a known pattern and also published here - https://aws.amazon.com/blogs/storage/extending-java-applications-to-directly-access-files-in-amazon-s3-without-recompiling/

blackname 👍 4 Selected: ACE

A -> Correct. Frontend could be hosted on s3 so we don't need a EC2 B -> False. That's expensive, and requires operational effort (ex: patches, ...) C -> Correct. Elastic Beanstalk would reduce operational effort of patches and other stuff and also support native scaling D -> False. Would be a great answer if it mentioned "Service Autoscaling" for fargate. Since it does not mention, we have to assume that would be only 1 fargate task. E -> Correct. Aurora RDS would reduce operational effort and would also allow scaling read replicas. F -> False. Requires very operational effort to allow DB reads scaling F

Dawson75 👍 1 Selected: ACE

ACE best choices

Dawson75 👍 1

BCF is correct

Fu7ed 👍 3 Selected: ACE

I chose ACE, but I don't know why it's not D. If you tried to reduce the development effort, it wouldn't have been D, but if you want to reduce the operation effort, I think D is definitely the answer to some extent. However, I chose C because I thought using app refactoring -> java container development -> EKS Fargate was cumbersome.

4555894 👍 1 Selected: ACE

1. AWS CloudFront (CDN) 2. AWS Elastic Beanstalk 3. DMS 4. Aurora Auto Scaling

tushar321 👍 1

BDE B for Web Servers ASG with EFS for scale to share Linux apache servers D for App Servers - Fargate reduces ops efforts E for DB

AwsZora 👍 1 Selected: A

This is what my company does, and there is no mention here of enabling S3 static web hosting

teo2157 👍 2 Selected: BCE

A is incorrect because you can´t connect a bucket S3 to a Java application so going with Apcache Web Servers with autoscaling. Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services. It supports Java applications and can automatically handle the details of capacity provisioning, load balancing, scaling, and application health monitoring. The using of Aurora PostgreSQL is pretty obvious. Said that going for BCE.

Zas1 👍 4 Selected: ACE

In general, Beanstalk is the best option if your priorities are SIMPLICITY and low cost. Meanwhile, Fargate is better if you want more control over how your application is hosted, your budget is not especially tight, and your application can be containerized.

devnv 👍 1

ACE are correct

Comments & Corrections

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

Expert Analysis

Why the Answer Is Correct

A: Hosting static assets in Amazon S3 and serving them through CloudFront removes the frontend tier from the scaling path and is a well-established pattern that the Java application can call directly for assets. C: Running the Java application in Elastic Beanstalk gives it auto scaling and managed deployments without the team operating instances. E: Replatforming to Aurora PostgreSQL with Aurora Auto Scaling read replicas moves read traffic off the writer, which was the exact failure point when the database hit its capacity limit on reads.

Why the Other Options Are Wrong

B: Rehosting Apache on Auto Scaling EC2 instances with EFS keeps the servers to be patched and maintained, which is operational effort rather than savings, and the static assets still need serving capacity. D: Refactoring the Java application into a container on Fargate is a larger code change than the near-term schedule allows, and it does not by itself fix the database read bottleneck.

Community Comment Notes

The community voted 85 to 1 for A, C, E. Commenters noted they would have preferred containers over Elastic Beanstalk in practice, but the operational-effort wording in the question points to Elastic Beanstalk, and one commenter confirmed the near-term promotion schedule is why the refactor options are excluded.

Official Reference

https://docs.aws.amazon.com/dms/latest/userguide/Welcome.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