Explanation:
The correct answer is B.
This approach meets the requirements with the least operational overhead because it uses a fully managed, event-driven push model to send AWS service status updates directly to the existing on-premises management application’s HTTPS endpoint—no application code changes, no polling, and no retirement of the current tool.
EventBridge (formerly CloudWatch Events) + SNS + HTTPS subscription is the native, low-effort integration for AWS Health events.
You create a simple EventBridge rule that matches AWS Health events (source = aws.health, detail-type = AWS Health Event). The rule targets an SNS topic, and you subscribe the management application’s existing HTTPS endpoint to that SNS topic. SNS delivers the messages as HTTPS POSTs.
This is real-time (push), serverless, and requires only console/CLI configuration—no ongoing maintenance, no custom code, and no polling costs.
It uses the AWS Personal Health Dashboard events (the account-specific, personalized view of service issues and scheduled changes that actually affect the company’s consumed AWS resources). This is exactly what the company needs. The events are automatically published to EventBridge with no extra setup.
A: Requires retiring the existing on-premises management application and migrating everything to OpsCenter. This is high-effort, high-risk, and far more operational overhead than a simple integration. Not “least overhead.”
C: Forces the on-premises application to be modified to repeatedly call the AWS Health API (polling). This adds code, scheduling logic, error handling, rate-limit management, and constant network traffic—clearly more operational overhead than a push-based solution.
D: Uses the wrong source (“AWS Service Health Dashboard”). The public Service Health Dashboard (status.aws.amazon.com) does not publish the same detailed, actionable events to EventBridge that the Personal Health Dashboard does. The “topic filter” idea is possible with SNS subscription filter policies, but it is irrelevant because the foundational event source is incorrect.
This is the standard, recommended pattern for incorporating AWS Health events into external monitoring systems with minimal work.
Ultimate access to all questions.
No comments yet.
A company is building a hybrid solution berween its existing on-premises systems and a new backend in AWS.The company has a management application to monitor the state of its current IT infrastructure and automate responses to issues.The company wants to incorporate the status of its consumed AWS services into the application.The application uses an HTTPS endpoint to receive updates.Which approach meets these requirements with the LEAST amount of operational overbead ？
A
Configure AWS Systems Manager OpsCenter to ingest operational events from the on-premises systems.Retire the on-premises management application and adopt OpsCenter as the hub.
B
Configure Amazon EventBridge（Amazon CloudWatch Events ）to detect and react to changes for AWS Health events from the AWS Personal Health Dashboard.Configure the EventBndge（CloudWatch Events）event to publish a message to an Amazou Simple Notification Service（Amazon SNS）topic and subscribe the topic to the HTTPS endpoint of the management application.
C
Modify the on-premises management application to call the AWS Health API to poll for status events of AWS services.
D
Configure Amazon EventBndge （Amazon CloudWatch Events）to detect and react to changes for AWS Health events from the AWS Service Health Dashboard.Configure the EventBridge（CloudWatch Events）event to publish a message to an Amazon Simple Notification Service（Amazon SNS）topic and subscribe the topic to an HTTPS endpoint for the management application with a topic filter corresponding to the services being used.