Exam AWS Certified SysOps Administrator - Associate topic 1 question 211 discussion

B. The questions states: "A SysOps administrator must implement a solution to retrieve client error details to help resolve this issue." Supporting answer: "Amazon SQS supports dead-letter queues (DLQ), which other queues (source queues) can target for messages that can't be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate unconsumed messages to determine why their processing doesn't succeed." https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html I'm really disappointed in the comments sections for this exam in particular. If you're going to take the time to comment, please include reference documentation that supports your choice.

Answer is absolutely "A" based on the links already provided. You need to replay the events, and try and identify why the monitoring app isn't able to contact EventBridge API. If you replace the monitoring app with SQS que, your just going to log Auto Scaling events. That isn't going to help you figure out why monitoring app isn't getting these same events through the EventBridge API. The SQS "B" answer may be easier than "A", but it isn't going to do any good on debugging EventBridge API access issue (probably a permissions/role/policy issue)

B>>This option is most suitable because Amazon EventBridge allows you to configure a dead-letter queue (DLQ) to handle events that fail to be delivered to the target. By directing these failed events to an Amazon SQS queue, you can store the events and analyze them to determine why the delivery failed, which may include client error details. This solution requires minimal operational effort as it leverages AWS's built-in mechanisms for error handling without the need to create additional resources or logging mechanisms.Creating an archive and replaying events is a more complex solution that might be necessary if you need to resend the events after fixing the issue. However, it doesn't directly address the requirement to retrieve error details and involves more operational steps compared to setting up a dead-letter queue.

Dead-letter queues (DLQ) are a feature in EventBridge that allows failed events (such as client errors when invoking an API destination) to be sent to a dead-letter queue (in this case, an Amazon SQS queue).

EventBridge Archive can retain event copies and replay them for debugging.

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-archive.html

EventBridge can now archive and replay events: You can now create an encrypted archive of the events published to an event bus. You can archive all events, or filter them using the same pattern matching syntax used by EventBridge rules. You can store events indefinitely, or set up a retention period after which older events are automatically removed from the archive. You can also replay the events stored in an archive. Events are replayed to all rules defined for the event bus (but not to managed rules created by other AWS services) or to the rules you specify. Replayed events contain an extra replay-name field in case you need to recognize them. When starting a replay, you define a time frame, and only events within that time frame are replayed. Currently, you can only replay events to the same event bus from which they were archived.

why not C? https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents.html

Based on the requirements to retrieve client error details with the least operational effort, option B would be the best solution. Adding an SQS standard queue as a dead-letter queue for the target will capture and store any failed messages, including error details. The messages can then be processed later to retrieve the error details, without requiring any additional configurations or modifications to the monitoring solution. Option A requires creating an EventBridge (CloudWatch Events) archive and replaying events, increasing logging, and then examining the error details. This solution requires additional effort and may not necessarily capture the exact error details that occurred.

Im in my opinion its A - https://aws.amazon.com/blogs/aws/new-archive-and-replay-events-with-amazon-eventbridge/ mainly because in the question it states they use the EventBridge API, meaning nothing goes into SQS and its unrelated to the question. By Default there's not invocation between EventBridge and SQS. U can however, create an Invoke Rule from EventBridge into SQS.

A is the correct answer from my point of view. After carefully reading the question, I agree with "yeacuz" argument from the link below. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-archive.html In EventBridge, you can create an archive of events so that you can easily replay them at a later time. For example, you might want to replay events to recover from errors or to validate new functionality in your application.

Option D, which is to configure the EventBridge (CloudWatch Events) rule to send error messages to an Amazon Simple Notification Service (Amazon SNS) topic, would be more efficient in terms of operational effort compared to Option C. This is because Option D requires only a simple configuration of the EventBridge (CloudWatch Events) rule and does not require the creation of a second EventBridge rule or a Lambda function. The error messages can be easily retrieved from the Amazon SNS topic and examined. I apologize for the error in my previous answer.

Answer is A: "In EventBridge, you can create an archive of events so that you can easily replay them at a later time. For example, you might want to replay events to recover from errors or to validate new functionality in your application." https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-archive.html

Answer is B