Weather alerts published to Amazon SNS must fan into a Lambda that opens incident tickets. How should the developer connect them?
Select an answer to reveal the explanation.
Short Explanation
SNS is the town loudspeaker; subscribe Lambda and each alert can open a ticket without the weather publisher knowing about your tracker. Tailing a log file on one EC2 box is not fan-in notification processing.
Full Explanation
Weather alerts published to Amazon SNS that must fan into a Lambda that opens incident tickets should be connected by subscribing the Lambda function to the SNS topic so each published alert can invoke the ticket-writing handler. SNS push subscription delivers the alert payload to Lambda (with the correct resource policy), enabling near-real-time municipal incident creation without the publisher knowing ticket-system internals.
Configuring SNS to archive alerts only to S3 while Lambda invents ticket text without subscriptions disconnects the publish path from the consumer. Having a single EC2 instance poll by scraping console HTML is not an integration architecture. Removing SNS and having API Gateway scrape third-party weather HTML on every citizen page load couples page views to brittle scraping and ignores the given SNS publish design.
Exam caveat: grant SNS permission to invoke Lambda; consider an SQS queue between SNS and Lambda for durability and smoother retries; make ticket creation idempotent on alert ID so SNS redeliveries do not open duplicate incidents.
Operational check: subscribe Lambda to the topic; publish a test alert; verify a ticket opens; confirm invoke permissions; add DLQ/failure handling; and ensure duplicate alerts do not duplicate tickets.