Lab 2C part 2 — SNS fan-out

15 timed scenario questions (~24 min, ~96 sec each). Reinforces night-14-sns-fanout.md and night-14-lab-sns-setup scripts. Answer without peeking at night-14-quiz-answers.json first.

1. 1.Iceland batch exits 1 after an S3 permission error. Night 13 SQS completion queue only receives exit code 0 events. Ops wants email and a ticketing SQS queue notified from the same failure event without each channel polling a shared work queue. What service fits?

   A.Amazon SQS FIFO — strict ordering so email and ticketing receive failures in sequenceB.AWS Step Functions — Catch on the Iceland container routes failures to two separate queuesC.Amazon SNS topic with email and SQS subscriptions — one publish fans out to subscribersD.Amazon EventBridge archive — replays failed ECS events to subscribers on a fixed schedule

2. 2.night-14-lab-sns-setup subscribes saa-study-gsa-iceland-alerts-inbox to the alerts topic. Messages never arrive in the inbox after sns:Publish succeeds. Subscription shows Confirmed. What is the most likely missing piece?

   A.SQS queue policy allowing sns.amazonaws.com sqs:SendMessage with aws:SourceArn = topic ARNB.IAM user policy granting sqs:ReceiveMessage to the SNS service principal on the inbox queueC.EventBridge input transformer mapping SNS Message to SQS MessageBody before each deliveryD.FIFO topic suffix .fifo required whenever SNS targets any SQS standard queue subscriber

3. 3.You subscribe an email endpoint to an SNS topic for Iceland failure alerts. aws sns list-subscriptions-by-topic shows SubscriptionArn PendingConfirmation. What must happen before email delivery?

   A.Attach an IAM role to the topic so SES can assume it and send mail on behalf of SNSB.The recipient confirms the subscription via the link AWS emailed to that addressC.Enable SNS delivery status logging to S3 — confirmation is automatic after first publishD.Convert the subscription protocol from email to email-json using a second subscribe call

4. 4.Night 12 CloudWatch alarm saa-study-gsa-iceland-task-failed watches FailedInvocations on the schedule rule. Night 14 adds the same SNS topic as an alarm action. What does this alarm detect?

   A.Iceland container exit code 1 after the Fargate task stops successfully in the ECS clusterB.SQS completion queue depth exceeding one visible message for more than five continuous minutesC.NAT Gateway bandwidth saturation in the Night 9 private subnets during the ecs:RunTask callD.EventBridge could not invoke the ECS RunTask target — infra or config failure on the rule

5. 5.An exam scenario needs three internal teams each with its own durable queue receiving every order-placed event from a single checkout service. Producers should not know team queue URLs. Best pattern?

   A.One SQS standard queue — all three teams share ReceiveMessage on the same queue URLB.Three Lambda functions polling one DynamoDB stream shard in a round-robin patternC.SNS topic publish from checkout; three SQS queue subscriptions — classic fan-out patternD.EventBridge custom bus with one rule per team and identical event patterns applied in series

6. 6.night-14-lab-sns-setup creates EventBridge rule saa-study-gsa-iceland-failure-to-sns targeting SNS. FailedInvocations metric increments on that rule. Topic policy and rule pattern look correct. What is the usual fix?

   A.SNS topic policy allowing events.amazonaws.com sns:Publish with aws:SourceArn = rule ARNB.Subscribe EventBridge as an HTTPS endpoint on the topic before put-targets will succeedC.Enable SNS server-side encryption with a customer-managed CMK that trusts only the default event busD.Change the SNS topic to FIFO — EventBridge cannot target standard SNS topics for rule delivery

7. 7.A mobile app needs push notifications to millions of devices with platform-specific payloads (APNS, FCM). The backend publishes one logical event per user action. Which SNS capability is most relevant?

   A.SNS mobile push endpoints with platform application ARNs — fan-out to device tokensB.SNS email-json protocol only — mobile devices poll the topic over HTTPS for payloadsC.SQS long polling from the mobile client — SNS is not used for device push deliveryD.EventBridge Scheduler one-off schedules — replaces SNS for per-device delivery timing

8. 8.You need strict ordering and deduplication of trade-execution alerts delivered to multiple FIFO SQS queues. Which SNS topic type should you create?

   A.Standard SNS topic with raw message delivery enabled on every subscription endpointB.FIFO SNS topic (name ends in .fifo) with deduplication — pairs with FIFO queue subsC.Standard SNS topic with message filtering on the subscription filter policy attributes onlyD.SNS topic in another Region — cross-Region FIFO ordering is automatic for finance alerts

9. 9.Night 13 completion consumer and Night 14 SNS inbox both need Iceland pipeline signals. Success should buffer for a slow stats worker; failures should push to ops immediately. How should you split services?

   A.Single SNS topic for both success and failure — every subscriber receives every messageB.Replace both with one EventBridge rule targeting five Lambda functions directly for all pathsC.SQS for success path (pull/worker buffer); SNS for failure path (push fan-out alerts)D.SNS for success only — SQS cannot receive EventBridge ECS Task State Change event payloads

10. 10.An SNS subscription uses a filter policy so only messages with attribute severity=critical reach a PagerDuty HTTPS endpoint. Non-critical publishes still succeed. What happens to filtered-out messages for that subscription?

    A.SNS delivers them to the DLQ configured on the topic for all rejected filter policy matchesB.SNS retries the HTTPS endpoint until the filter policy is updated to allow those messagesC.Messages are rerouted to the default EventBridge bus so operators can replay them manuallyD.That subscription simply does not receive them — other subscribers still get the publish

11. 11.Raw message delivery is enabled on an SNS→SQS subscription. What does the SQS message body contain compared to the default SNS wrapping?

    A.Base64-encoded gzip of the payload plus mandatory MessageId and TopicArn attributesB.Only the published message payload — no SNS metadata JSON envelope around the bodyC.The ECS Task State Change event only — SNS strips custom publish bodies from the queueD.An empty body — raw delivery requires MessageAttributes on every sns:Publish API call

12. 12.A Lambda function is subscribed directly to an SNS topic (not via SQS). The function times out on some invocations. What is SNS default behavior?

    A.SNS retries delivery to Lambda with backoff; configure a subscription DLQ for poison messagesB.SNS immediately deletes the message — Lambda must poll a separate SQS DLQ for retriesC.SNS pauses all topic publishes globally until the Lambda reserved concurrency limit is raisedD.SNS converts the subscription to email-json after three consecutive Lambda timeout failures

13. 13.Compared to Night 13 SQS completion queue, why is SNS the wrong choice for the stats-uploader worker pool that processes one message at a time with back-pressure?

    A.SNS cannot deliver to Lambda — only SQS supports Lambda event source mapping integrationsB.SNS is Regional and cannot be used in us-east-1 together with ECS Fargate task workloadsC.SNS push fan-out does not buffer work for competing consumers — use the SQS pull modelD.SNS requires email confirmation before any programmatic subscriber endpoint can be added

14. 14.Cross-account Account B must publish to Account A SNS topic saa-study-gsa-iceland-alerts. What two controls are typically required?

    A.VPC peering between accounts; SNS publish cannot cross account boundaries without peering linksB.SNS topic created only in Account B — cross-account publish is unsupported for standard SNS topicsC.AWS Organizations SCP denying all SNS in B — cross-account requires Control Tower enrollmentD.Topic policy on A allowing B principal sns:Publish; IAM on B allowing sns:Publish to topic ARN

15. 15.After Night 14 teardown, you want Iceland success events on SQS and failure alerts on SNS again. Minimum lab scripts to re-deploy both paths?

    A.night-14-lab-sns-setup only — it recreates the Night 13 completion queue and DLQ automaticallyB.night-13-lab-sqs-setup then night-14-lab-sns-setup — success queue and failure fan-out are separateC.night-12-lab-eventbridge-schedule only — the schedule rule already includes both SQS and SNS targetsD.night-14-lab-sns-inbox only — the inbox script creates the topic and failure rule on first run