SOA-C02 Monitoring, Logging, and Remediation 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.

• ✗

  Create a custom CloudWatch metric for canary failures.

  Why it's wrong here

  CloudWatch Synthetics automatically emits a standard set of metrics, including SuccessPercent, Failed, and Duration, under the CloudWatchSynthetics namespace. Creating a custom metric for canary failures would duplicate this built-in telemetry and require additional PutMetricData code inside the canary script. Since the built-in metrics are already integrated with the CloudWatch alarm engine, a custom metric is unnecessary and adds complexity without any monitoring benefit.

• ✓

  Configure a CloudWatch alarm on the canary's `SuccessPercent` metric.

  Why this is correct

  SuccessPercent is a native CloudWatch Synthetics metric that represents the percentage of successful canary runs during a given period. Configuring a CloudWatch alarm on this metric, with a threshold such as a drop below 99 percent, directly triggers an ALARM state when reliability degrades. This approach uses the existing metric stream, so no custom code or additional metrics are required, and it supports standard alarm features like evaluation periods and actions.

• ✓

  Create a canary in CloudWatch Synthetics.

  Why this is correct

  A CloudWatch Synthetics canary must be created first to execute the user-interface script on a regular schedule. During each run, the canary records pass/fail results and publishes the SuccessPercent metric to CloudWatch, which is what the alarm will evaluate. Without a canary there are no metrics for the alarm to monitor, so this step is a mandatory prerequisite for the entire monitoring solution.

• ✓

  Configure the alarm to send a notification to an SNS topic.

  Why this is correct

  To ensure that the operations team is actually notified when the SuccessPercent alarm goes into ALARM state, you must attach an SNS topic to the alarm's notification action. The SNS topic can deliver alerts over email, SMS, or HTTP endpoints, turning the state change into an actionable incident. Skipping this step leaves the alarm as a silent state change, which defeats the purpose of proactive monitoring.

• ✗

  Enable detailed monitoring on the canary.

  Why it's wrong here

  Detailed monitoring is an option for EC2 instances or other services that sends metrics at a one-minute frequency, but CloudWatch Synthetics does not expose a similar detailed monitoring setting. Canary metrics are published after each run based on the configured schedule, and the alarm's granularity is controlled by the evaluation period, not by any 'detailed monitoring' toggle. Enabling a non-existent setting would have no effect on the canary's metric availability.

Go deeper

Related to this question