DOP-C02 Incident and Event Response Practice Question
A DevOps team is investigating a performance issue where an application's response time spiked during a deployment. The deployment used AWS CodeDeploy to update an Auto Scaling group. Which THREE actions should the team take to identify the root cause? (Choose THREE.)
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 CodeDeploy deployment logs for errors.
CodeDeploy deployment logs contain detailed information about the deployment process, including any errors or failed steps that could impact performance. Option B is correct because application logs on the new EC2 instances can reveal errors, misconfigurations, or resource contention that may have caused the spike. Option E is correct because comparing CloudWatch metrics (e.g., CPU utilization, latency, request count) before and after the deployment helps pinpoint changes that correlate with the performance issue. Option C is wrong because reviewing the deployment group configuration—which defines how deployments occur (e.g., traffic routing, instance selection)—is unlikely to directly identify the root cause of a performance spike; it is more relevant for deployment strategy issues. Option D is wrong because AWS CloudTrail records API calls for auditing and security, not application performance; unauthorized API calls are unlikely to cause a transient performance spike during deployment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Review the CodeDeploy deployment logs for errors.
Why this is correct
CodeDeploy deployment logs capture lifecycle event hook failures, invalid scripts, and resource timing issues during deployment (e.g., BeforeInstall/AfterInstall failures) that can leave instances in a degraded state causing performance hits. Any failed or aborted deployment step may cause new instances to be registered with incomplete configuration, leading to CPU/memory pressure or misrouted traffic. Scrutinizing these logs pinpoints whether the performance spike correlates with deployment execution timeouts, file overwrite errors, or instance registration failures.
- ✓
Examine application logs on the new EC2 instances launched during the deployment.
Why this is correct
Application logs on the freshly launched instances reveal runtime exceptions, slow database queries, or resource contention that only manifests on new capacity. They can show if an instance is receiving traffic before initialization is complete (e.g., due to target group deregistration delays) or if a startup script is causing contention. This isolates whether the issue is a bad deployment artifact or a configuration drift on the new instances, separate from CodeDeploy's own lifecycle logs.
- ✗
Review the CodeDeploy deployment group configuration.
Why it's wrong here
A deployment group configuration defines deployment type, target instances, and traffic routing strategy (AllAtOnce, Rolling, Blue/Green), which only affect availability and rollover semantics, not the runtime performance of the deployed application. Unless the configuration was modified just before the incident, it is a static settings snapshot that would not create a temporary performance spike. Misconfigurations such as improper instance selection could lead to capacity mismatch, but they manifest as consistent undercapacity rather than a spike correlated with a single deployment.
- ✗
Check AWS CloudTrail for any unauthorized API calls during the deployment.
Why it's wrong here
CloudTrail records control-plane API calls such as RunInstances or CreateAutoScalingGroup, but it does not capture OS-level process CPU usage, memory pressure, or application latency. Unauthorized API calls could indicate a compromised account launching rogue resources, but that would introduce a separate workload, not degrade a specific CodeDeploy deployment's targets. Performance issues are operational telemetry, not audit analytics, so CloudTrail logs are not the appropriate source for diagnosing a spike.
- ✓
Compare CloudWatch metrics for the Auto Scaling group before and after the deployment.
Why this is correct
Comparing CloudWatch metrics for the Auto Scaling group before and after the deployment gives a quantitative baseline for CPUUtilization, NetworkIn/Out, and GroupInServiceInstances, revealing exactly when the performance divergence began. A post-deployment metric spike can indicate the new launch template uses a different instance type, the deployment triggered a scale-in/scale-out cycle, or the new application code introduces a bottleneck (e.g., synchronous DB calls). This comparison is the first step in correlating the deployment timeline with resource utilization, allowing the team to determine whether the issue is capacity-related or code-related.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.