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

SAP-C02 By islever Editorial Last updated

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

Short answer

ACE Host static assets on S3 with CloudFront, run the Java tier in Elastic Beanstalk, and replatform to Aurora PostgreSQL with Auto Scaling read replicas.

Question

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.)
  1. 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
  2. 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.
  3. Rehost the Java application in an AWS Elastic Beanstalk environment that includes auto scaling. Correct Answer
  4. Refactor the Java application, Develop a Docker container to run the Java application. Use AWS Fargate to host the container.
  5. 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

Key Takeaways

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.

Common mistake: 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.

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

This link opens the official vendor documentation in a new tab.

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.

Discussion 13 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 13

  1. blackname 👍 4
    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
  2. Zas1 👍 4
    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.
  3. Fu7ed 👍 3
    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.
  4. chris_spencer 👍 3
    I would preferred container over beanstalk but this are examen questions ACE
  5. teo2157 👍 2
    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.
Show 8 more comments
  1. backbencher2022 👍 1
    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/
  2. 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
  3. wbedair 👍 1
    The question says they have incoming campaigns in NEAR future. Doesn't this means Rehost options are better?
  4. AwsZora 👍 1 Answered A
    This is what my company does, and there is no mention here of enabling S3 static web hosting
  5. 4555894 👍 1
    1. AWS CloudFront (CDN) 2. AWS Elastic Beanstalk 3. DMS 4. Aurora Auto Scaling
  6. Dawson75 👍 1
    ACE best choices
  7. devnv 👍 1
    ACE are correct
  8. Dawson75 👍 1
    BCF is correct

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Reach a cross-account S3 data lake through a gateway endpoint and an access point bucket policy

S-grade

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