A recreation booking site serves a static front end, calls business logic through an API, and must avoid storing session state on servers. Which architecture best matches a serverless multi-tier pattern?
Select an answer to reveal the explanation.
Short Explanation
Static pages up front, Lambda behind API Gateway in the middle, managed data in the back—and sessions live off the servers. One EC2 burrito with local sessions is the opposite of serverless multi-tier.
Full Explanation
A recreation booking site with a static front end, API business logic, and no server-local sessions matches a serverless multi-tier pattern: host the UI on S3 with CloudFront, expose business logic through Amazon API Gateway backed by AWS Lambda, and persist data in a managed store while keeping compute ephemeral and stateless. That design scales with demand for seasonal booking peaks without running always-on web/app/database co-tenancy on one box.
A single always-on EC2 host running web, app, and MySQL with local sessions is a classic monolith SPOF and contradicts serverless multi-tier goals. FTP upload of HTML to an unmanaged VM with sticky sessions on disk is fragile operations, not a modern scalable architecture. A mainframe green-screen farm as the only citizen interface fails the static/API serverless requirement entirely.
Exam caveat: serverless multi-tier almost always maps to CloudFront/S3 + API Gateway + Lambda + managed data (DynamoDB/RDS as appropriate) with externalized state. Operational check: deploy a static booking UI, authenticate API calls to Lambda, confirm no session files on compute, load-test a booking surge, and validate CloudWatch metrics for each tier independently.