Which solution would satisfy these requirements?
Create another SQS queue. Update the S3 events in the bucket to also update the new queue when a new object is created.
Create a new SQS queue that only allows Amazon S3 to access the queue. Update Amazon S3 to update this queue when a new object is created.
Create an Amazon SNS topic and SQS queue for the bucket updates. Update the bucket to send events to the new topic. Updates both queues to poll Amazon SNS.
Create an Amazon SNS topic and SQS queue for the bucket updates. Update the bucket to send events to the new topic. Add subscriptions for both queues in the topic.
Explanations:
This option suggests creating another SQS queue and updating the S3 event notifications to both queues. However, S3 can only send events to a single destination per event type, making it impossible to notify two SQS queues simultaneously without using an intermediate service like SNS.
Similar to option A, this option involves creating a new SQS queue for S3 notifications. However, it does not resolve the requirement to notify both teams since S3 can only target one destination for event notifications. Thus, the operations team’s existing setup would still be disrupted.
This option proposes creating an SNS topic and a new SQS queue, but states that both queues will poll SNS. This is not valid since SQS queues cannot directly poll an SNS topic; they must be subscribed to it to receive messages. This option doesn’t satisfy the requirement for both teams to receive notifications properly.
This option correctly creates an SNS topic to which the S3 bucket can send notifications. By adding subscriptions for both the existing SQS queue (for the operations team) and a new SQS queue (for the development team) to the SNS topic, both teams can receive notifications without impacting the current workflow of the operations team. This setup adheres to the requirement of maintaining the existing workflow while allowing the development team to receive new object notifications.