DOP-C02 Incident and Event Response Practice Question
A company uses Amazon CloudWatch Synthetics canaries to monitor its web application endpoints. The canaries are failing intermittently with 'ClientError' status codes. Which TWO actions should the engineer take to diagnose the issue? (Choose two.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Review the canary's CloudWatch Logs for error details.
CloudWatch Synthetics canaries automatically log execution details, including errors, to CloudWatch Logs. Reviewing these logs provides specific error information, such as 'ClientError' details. Option C is correct because each canary runs as an AWS Lambda function, and the Lambda function's CloudWatch Logs contain runtime logs, including any exceptions or errors thrown during execution. Option A is incorrect because while adding logging could be a long-term improvement, the question asks for diagnostic actions; the canary already logs to CloudWatch Logs, so modifying the script is not necessary for diagnosis. Option D is incorrect because CloudWatch metrics provide aggregate statistics (e.g., success/failure rates) but not detailed error codes or messages. Option E is incorrect because CloudTrail records API calls to create, start, or stop canaries, not the execution details of individual canary runs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Modify the canary script to add more logging.
Why it's wrong here
You cannot modify the pre-built canary scripts that CloudWatch Synthetics provides (e.g., Heartbeat, API canary) to inject additional logging; they are managed runtimes intended for immediate use. For custom diagnostic logging, you would need to author a new custom canary script using the Synthetics SDK, then redeploy it—so modifying the script is not a valid, immediate diagnostics step and does not help you interpret an existing failure.
- ✓
Review the canary's CloudWatch Logs for error details.
Why this is correct
Reviewing the canary's CloudWatch Logs is the correct first step because each canary run emits a dedicated log stream containing step-by-step execution details, error and stack traces, HTTP response bodies, and console output from the canary script. Since the canary has already failed, these logs are the definitive source for pinpointing the root cause—whether it's an assertion failure, a timeout, an invalid response, or an unexpected HTTP status.
- ✓
Inspect the Lambda function logs associated with the canary.
Why this is correct
Because every Synthetics canary executes as an AWS Lambda function under the hood, inspecting the associated Lambda log stream (in the same CloudWatch log group, typically named /aws/lambda/cwsyn-<canary-name>-... or /aws/canary/...) reveals raw runtime exceptions, memory/timeout errors, and invocation-level details from the Lambda service. These logs complement the Synthetics-specific canary logs, and looking at them is a valid troubleshooting action—especially when the failure occurs before the canary script produces its own output.
- ✗
Examine CloudWatch metrics for the canary.
Why it's wrong here
CloudWatch metrics for a canary, such as SuccessPercent, Duration, and Failed, provide aggregated counts and timing data that tell you a failure happened but not why. They lack the granular diagnostic content needed to debug an error—no endpoint, response payload, stack trace, or specific assertion failure appears in the metric data. Metrics only help you detect the problem, not resolve it.
- ✗
Check CloudTrail for CanaryRun API calls.
Why it's wrong here
CloudTrail records control-plane API activities such as CreateCanary, StartCanary, and StopCanary, but it does not log the internal execution output or script-level errors of a canary run. A CanaryRun API call in CloudTrail would only indicate that a run was triggered or invoked, not what happened during that run or why it failed, so CloudTrail is not useful for diagnosing a failed canary.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.