A classic multi-instance web app that issues building permits should run on a PaaS path with environment-level rolling updates. Which AWS deployment option best matches that application shape?
Select an answer to reveal the explanation.
Short Explanation
Beanstalk is the PaaS driveway for a classic multi-instance permit site—environments, rolling updates, less yak-shaving. Glue crawlers and static S3 sites are not your form-processing app servers.
Full Explanation
A classic multi-instance web application that issues building permits fits a PaaS-style path: upload a web app, get environments, capacity, and rolling updates without assembling every EC2 bootstrap piece by hand. AWS Elastic Beanstalk provides that model—application versions, environment configuration, and rolling (or immutable/blue-green) deployment policies—matching the application shape described for permitting workloads that still look like traditional multi-instance web tiers.
Rewriting the app as a single-threaded Lambda with a fifteen-minute synchronous HTTP wait fights both Lambda's request model and user experience for permit forms. Hosting only static HTML in S3 omits the application server tier permits processing needs. AWS Glue crawlers catalog data for analytics; they are not a web application runtime for citizen forms.
Exam caveat: Beanstalk remains a valid DVA-C02 deployment option for traditional web apps even though containers and Lambda appear frequently; match platform to application shape rather than forcing every civic app onto Lambda.
Operational check: create a Beanstalk environment for the permitting app, enable rolling updates, deploy an application version through the pipeline, and verify instances replace in batches while the citizen permit site remains available.