A media company is refactoring a monolithic claims application into a serverless architecture in a single account. The redesign needs a public HTTPS API for synchronous client requests, durable orchestration of a multi-step claim process with built-in retries and a step that waits hours for a human approval, and a loosely coupled way to fan one claim-submitted event out to several independently owned consumer services that may change over time. Leadership wants each concern met by a managed service that minimises operational overhead and avoids custom orchestration or polling code. Which THREE services BEST compose this serverless design? Select THREE.
- AUse Amazon API Gateway to expose the public HTTPS API for synchronous client requests, so the team offloads TLS termination, throttling and request routing to a managed front door without running its own web-server fleet. Correct
- BUse an Amazon EC2 Auto Scaling group behind an Application Load Balancer to host the API and run the orchestration logic, so the team keeps full control of the runtime while scaling capacity with claim volume during busy periods.
- CUse AWS Step Functions to orchestrate the multi-step claim process, so ordered steps, built-in retries with backoff and a long wait for human approval are expressed declaratively without writing or operating custom state-tracking code. Correct
- DUse Amazon SQS as the public entry point so clients place claim requests directly onto a queue, then poll the queue from the orchestration layer to drive each step of the multi-step claim process in order.
- EUse Amazon EventBridge to publish the claim-submitted event to an event bus, so multiple independently owned consumer services subscribe with their own rules and new consumers are added later without changing the producer. Correct
Why A is correct: API Gateway is the managed serverless front door for synchronous HTTPS, handling TLS, throttling and routing without a server fleet, which matches the public-API concern with the least operational overhead.
Why B is wrong: An Auto Scaling fleet can host an API, but it reintroduces server management and bespoke orchestration code, which contradicts the goal of managed, low-overhead serverless services for each concern.
Why C is correct: Step Functions provides managed orchestration with native retries, error handling and long-running waits for human approval, removing the custom state-tracking code the refactor is meant to eliminate.
Why D is wrong: A queue suits asynchronous buffering, but it is not a synchronous HTTPS API and polling it to drive ordered steps recreates the custom orchestration the team wants Step Functions to replace.
Why E is correct: EventBridge gives content-based fan-out where each consumer owns its rule and new subscribers attach without touching the producer, delivering the loose coupling the design requires for evolving consumers.