DOP-C02 Incident and Event Response Practice Question
A company uses AWS CloudFormation to manage infrastructure. A stack update fails with a 'ROLLBACK_IN_PROGRESS' status. The DevOps engineer needs to investigate the failure. Which TWO actions should the engineer take?
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 'Stack Events' tab in the CloudFormation console to see the specific error messages.
To investigate a CloudFormation stack update failure, the DevOps engineer should review the 'Stack Events' tab (Option B), which provides detailed error messages for each resource, helping identify the root cause. Additionally, examining the stack's 'Template' and 'Parameters' (Option D) can reveal misconfigurations that may have caused the failure. Option A is incorrect because CloudTrail logs record API calls but not the specific resource-level errors from the stack update. Option C is incorrect because 'Rollback triggers' are used to monitor stack status and initiate rollback, not to diagnose failures. Option E is incorrect because Change Sets are for previewing changes before execution, not for debugging a failed update.
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 AWS CloudTrail logs for the 'UpdateStack' API call.
Why it's wrong here
CloudTrail logs the UpdateStack API call as a record of the request—who made it, when, and the raw request payload—but it does not contain the resource-level validation results or internal error strings that CloudFormation generates during the update. After a failed update, the stack enters UPDATE_ROLLBACK_COMPLETE and each resource's statusReason is only surfaced in the stack events, not in the CloudTrail event. CloudTrail is useful for auditing the action, not for diagnosing why a property like a VPC ID or IAM role failed to validate.
- ✓
Review the 'Stack Events' tab in the CloudFormation console to see the specific error messages.
Why this is correct
The Stack Events tab in the CloudFormation console (or the describe-stack-events API) is the primary diagnostic source because every resource creation, update, and deletion emits an event with a status and a statusReason field. For a failed update, the event that shows status UPDATE_FAILED includes the exact error message—for example, 'Parameter validation failed: Invalid value for parameter' or 'The following resource(s) failed to create: EC2Instance'. This per-resource reason tells you precisely which logical resource and which property caused the failure, so you can correct the template or parameters before retrying.
- ✗
Check the 'Rollback triggers' configuration for the stack.
Why it's wrong here
Rollback triggers are optional CloudWatch alarms that CloudFormation monitors during stack creation and update operations; if an alarm transitions to ALARM, CloudFormation rolls back the stack immediately. They are not a diagnostic tool for an already-failed update, because they only influence whether a rollback is initiated mid-operation, not why a resource failed. Reviewing the rollback trigger configuration after a failure will tell you which alarms might have fired during the operation, but it will not provide the validation errors or resource status reasons you need to fix the template.
- ✓
Examine the stack's 'Template' and 'Parameters' to ensure they are correct.
Why this is correct
After a failed update, inspecting the stack's current template and parameters is a sensible corrective step because many failures stem from invalid parameter values, unsupported resource properties, or referencing a resource that was renamed or removed in the template. However, be aware that if CloudFormation successfully rolled back, the stack's current template and parameters reflect the original state, not necessarily the failed update's input—so you should also compare against the previous version or a change set to see what was actually attempted. Correcting a typo in a parameter, fixing a bad AMI ID, or passing a proper subnet ID can resolve the error, but the Stack Events tab will confirm the exact cause before you change anything.
- ✗
Create a Change Set to see the proposed changes before re-attempting the update.
Why it's wrong here
A change set is designed for planning and previewing the impact of a proposed update—it shows what resources will be added, modified, or deleted—but it does not reveal why a previous update failed. Even if you create a change set after the failure, it will only validate that the new template and parameters are built correctly, and it will not replay or return the error messages from the earlier attempt. You would still need stack events to identify the original failure reason, and you should not use a change set as a substitute for checking the stack's rollback status or event history.
Go deeper
Related to this question
About these practice questions
One of 251 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.