How to centralize CloudWatch metrics and alarms across accounts and Regions?

Answer Correct answer: D — Set up CloudWatch cross-account observability, designating the operations account as the monitoring account and the application accounts as source accounts.

A company has multiple AWS accounts that run applications in different AWS Regions. The company has configured Amazon CloudWatch alarms in each account to monitor CPU utilization and request latency metrics. An operations team must create a centralized dashboard in a single Region within the operations team's AWS account. The dashboard needs to be able to display metrics and alarm states from all applications. Which solution will meet these requirements?

  1. Enable the CloudWatch cross-account cross-Region console in each application account. Configure the sharing of metrics and alarms with the operations team's AWS account. In the operations team's AWS account, create a CloudWatch dashboard with the metrics and alarms from the application account.
  2. Create an Amazon EventBridge rule in each application account to forward CloudWatch alarm state changes to an Amazon SNS topic in the operations team's AWS account. In the operations team's AWS account, create a CloudWatch dashboard with the metrics and alarms from the application accounts.
  3. Deploy AWS Lambda functions in each application account. Configure the functions to periodically extract CloudWatch metrics and alarm states and copy the values to CloudWatch in the operations team's AWS account. In the operations team's AWS account, create a CloudWatch dashboard with the metrics and alarms from the application accounts.
  4. Set up CloudWatch cross-account observability. Designate the operations team's AWS account as the monitoring account. Configure the application accounts as source accounts. In the operations team's AWS account, create a CloudWatch dashboard with the metrics and alarms from the application accounts. Correct Answer

Community Insight

The test is whether you know the native CloudWatch cross-account observability linking model (monitoring account + source accounts), versus bolt-on workarounds — the trap is picking the legacy cross-account cross-Region console option that must be enabled in the wrong account.

CloudWatch cross-account observability links application accounts as source accounts to a single monitoring account so one dashboard can display CPU and latency metrics plus alarm states from every Region. This page confirms that option D is the designed solution and explains why the older per-account console sharing, EventBridge forwarding, and Lambda copying fall short.

Choosing option A because it mentions CloudWatch dashboards and cross-account cross-Region access, while missing that the legacy console setting is enabled in the account that views the dashboard (the monitoring account), not in each application account, and that it does not provide the same centralized, Region-spanning observability link as source-account onboarding.

Community Discussion (1 comments)

Bad_Mat 👍 1 Selected: D
The correct answer option is D. Set up CloudWatch cross-account observability. Designate the operations team's AWS account as the monitoring account. Configure the application accounts as source accounts. In the operations team's AWS account, create a CloudWatch dashboard with the metrics and alarms from the application accounts

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

CloudWatch cross-account observability is purpose-built for this scenario: the operations team's account is designated the monitoring account, each application account is onboarded as a source account, and the monitoring account can then build a single dashboard in one Region that queries metrics, alarm states, and even Logs Insights from all linked accounts and Regions. Because the source accounts are only linked — not modified with roles, functions, or forwarding pipelines — the operations team gains read access without duplicating data or adding per-account plumbing. Option D matches every requirement: one Region, one dashboard, metrics and alarms from all applications, across accounts and Regions.

Why the Other Options Are Wrong

Option A relies on the older cross-account cross-Region console behavior, which is enabled in the account where the dashboard is created (the monitoring account) and depends on a sharing role in the source accounts, so "enable in each application account" is the wrong direction and does not deliver a truly unified cross-Region view. Option B only forwards alarm state changes into an SNS topic; it delivers notifications, not the CPU utilization and request latency metric data a dashboard needs to render graphs. Option C works only in the sense of brute force — Lambda functions polling and re-publishing metrics into the operations account duplicate data, add cost and lag, and cannot faithfully reproduce alarm states or original metric dimensions.

Community Comment Notes

Bad_Mat states plainly that "The correct answer option is D" and walks through the monitoring-account/source-account designation followed by dashboard creation in the operations account, which mirrors the official feature design. That reasoning also implicitly rejects the per-application-account console setup in option A, since the link is created once in the monitoring account. No comment endorses the EventBridge or Lambda approaches, so the community view is aligned with the vendor's documented cross-account observability workflow.

Official Reference

Exam Strategy

When a question asks for one dashboard in one account that shows data from many accounts and Regions, look immediately for "cross-account observability" with monitoring/source roles before considering notification or replication workarounds. Answers that copy or forward data (Lambda, EventBridge to SNS) only satisfy alerting, not dashboard aggregation, so eliminate them fast.

Frequently Asked Questions

Why is option A's per-account console sharing insufficient for this dashboard?

The legacy cross-account cross-Region console setting is enabled in the account that views the dashboard, not in each application account, and it does not give the unified source-account link that cross-account observability provides.

Does CloudWatch cross-account observability work when the application accounts are in different Regions?

Yes. A source account in any Region can be linked to the monitoring account, so a single dashboard in one Region can show metrics and alarms from all of them.

More SOA-C03 FAQ →

Related Analysis

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide