A small team wants to deploy a simple Java permit web app with platform-managed load balancing and scaling but without deep container orchestration. Which option fits?
Select an answer to reveal the explanation.
Short Explanation
Elastic Beanstalk is the paved road—upload the Java app and let AWS handle the load balancer and scaling knobs without standing up a Kubernetes city. S3 static hosting won’t run server-side Java.
Full Explanation
AWS Elastic Beanstalk fits a small team deploying a simple Java permit web app that needs platform-managed load balancing and scaling without deep container orchestration. Beanstalk provisions capacity, integrates a load balancer, and offers scaling policies while the team uploads an application bundle—PaaS convenience without standing up Kubernetes first. That matches “simple web app, managed LB/scaling, not deep orchestration.”
Building a custom Kubernetes control plane on EC2 before writing any application code fails by concept because it maximizes platform work before delivering the permit app. Requiring AWS raw metal provisioning tickets for every git push with no PaaS layer fails as heavy process without a managed application platform. Hosting the Java app only as static files in Amazon S3 fails because S3 static hosting does not execute server-side Java web applications.
Exam caveat: Simple web app + managed platform → Elastic Beanstalk (or similar PaaS). Custom K8s-first, bare-metal tickets, and S3-only static hosting miss the requirement.
Operational check: Confirm the Beanstalk environment runs the Java app behind a load balancer, health checks pass, auto scaling policies exist, and deployments are application versions—not manual metal tickets. If the team is still building a Kubernetes control plane before hello-world, the option fit is wrong.