Considering the requirements, Option B (Amazon EventBridge with AWS Lambda and S3 Lifecycle Expiration Policy) seems to be the most cost-effective and appropriate solution. It combines the scalability and flexibility of AWS Lambda for image processing with the straightforward event handling of Amazon EventBridge, and appropriately manages the image lifecycle with an S3 expiration policy. While Option C is also a strong contender, the misalignment of the lifecycle policy with the requirement makes Option B a better fit. Option A might be more suitable for complex workflows but is likely not needed for this scenario, and Option D includes unnecessary long-term archival steps.

B is for sure A no because Step Function is not in list of s3 event destinations https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-event-types-and-destinations.html C and D has option for storing data longer than 6 months which is not required

I think this question is warding wrong. If we look at the requirement "store the files in an Amazon S3 bucket for up to 6 months." and decide that objects can be deleted after 6 months, C and D are excluded. But is that true? Would AWS create a problem involving such an elementary mistake?

A is the answer

Vote D because the requirement "rerun processing jobs in the event of failure." Glacier Deep archive is also really cost-effective

Option D is right answer as it gets the batch files with significant variance in demand

Going for A as it's the only option that achieve reprocessing, B could be a good answer but it doesn´t allow any reporcessing.

a: step function for 'the ability to rerun processing jobs in the event of failure'. c,d out for keeping the files after 6 months. b: not able to rerun failures..

Correct: A An S3 event is created by eventbridge and can trigger a step function. Image processing cannot be done a lambda function alone. Step function is preferred for image processing. You also need the ability to rerun the jobs. https://docs.aws.amazon.com/step-functions/latest/dg/use-cases-data-processing.html https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-cloudwatch-events-s3.html

B is the answer. A is wrong - AWS Step Function cannot directly be invoked by S3 Event Notification.

B is the best answer (cheapest option) compared to A as step functions requires event notification (for trigger) which is typically done using event bridge .

Another poorly worded question. First of all, C and D can be eliminated since they keep files after the 6 month period. Then, both A and B are valid. Both will use a Lambda to do the work, but the state changes in the Step Function will incur a very slight cost. Personally, I'd choose A to get control of retries, etc, but the MOST cost-effective alternative is B.

C & D are automatically eliminated as the images don't need to be stored beyond 6 months. Step Function cannot be invoked for an S3 Event, thus EventBridge.

By default, EventBridge retries sending the event for 24 hours and up to 185 times with an exponential back off and jitter, or randomized delay. If an event isn't delivered after all retry attempts are exhausted, the event is dropped and EventBridge doesn't continue to process it. To avoid losing events after they fail to be delivered to a target, you can configure a dead-letter queue (DLQ) and send all failed events to it for processing later.

It is B

A is the most cost effective, and Stepfunction can retry on failure. Only missing is what will invoke STF. Still I vote for A.

A, B and C - there's no mechanism to retry failed jobs, so these options don't meet the mandatory requirement: "The solution must also be reliable at enterprise scale and have the ability to rerun processing jobs in the event of failure." There's no mandatory requirement to delete the files after 6 months. D - meets the mandatory requirements.