DOP-C02 Monitoring and Logging Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Replicate the canaries to US East (N. Virginia) and run them from there.

  Why it's wrong here

  Replicating the canaries to US East (N. Virginia) fundamentally changes the measurement perspective: the latency, availability, and success metrics you collect now reflect a Virginia-based vantage point rather than the experience of users in the actual target regions. This introduces a monitoring blind spot for region-specific failures or routing issues and does not preserve the cross-region view you need. It also fails to solve the dashboard problem, because you would still need a mechanism to aggregate and display metrics from the original regions if you want a single pane of glass.

• ✓

  Create a cross-region CloudWatch dashboard and add metrics from each region using metric math.

  Why this is correct

  CloudWatch dashboards are not region-bound artifacts: each widget can explicitly specify a different source region, and metric math can combine those cross-region metrics within a single expression, for example summing SuccessPercent or averaging Duration across all canary regions. This natively aggregates the existing Synthetics metrics without duplicating canaries, running Lambda functions, or parsing logs. It is the intended, low-operational-overhead mechanism for a consolidated cross-region view and requires no custom infrastructure.

• ✗

  Set up a Lambda function in each region to push canary results to a central S3 bucket, then create a dashboard from S3.

  Why it's wrong here

  This approach adds unnecessary architectural complexity: you must deploy and maintain Lambda functions in each region, configure IAM roles and cross-region S3 bucket policies, handle eventual consistency and object naming/versioning, and then build a separate dashboard layer (e.g., Athena or QuickSight) to query the centralized S3 data. That entire pipeline simply re-serves data that CloudWatch already exposes as regional metrics via the Synthetics canary integration. It also introduces extra latency, cost, and failure points while providing no benefit over the native cross-region dashboard capability.

• ✗

  Create a CloudWatch Logs Insights query across all regions and visualize results.

  Why it's wrong here

  CloudWatch Logs Insights queries are scoped to a single region: a query runs against log groups within one Region, so you cannot create a single query that spans all regions. Although you can add a Logs Insights widget to a dashboard, each widget is bound to a specific Region, so you would need a separate widget per region and still could not produce a combined cross-region metric view. Additionally, canary results are primarily published as numeric metrics, and deriving success/failure rates by parsing log text is slower, more complex, and less accurate than directly using the Synthetics metrics that are already available.

Go deeper

Related to this question