Courseiva
Deployment →hardMultiple Choice

DVA-C02 Deployment Practice Question

A company is deploying a critical application using AWS CloudFormation. The stack creation fails with a 'ROLLBACK_COMPLETE' status. The engineer wants to troubleshoot the failure without deleting the stack. What should the engineer do?

⚠ Common exam trap

DVA-C02 often tests the misconception that you can update or recreate a stack in ROLLBACK_COMPLETE without deleting it, or that rollback options like DO_NOTHING or disable-rollback can be applied after the fact, when in reality the stack is immutable and only event logs provide diagnostic insight.

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

✓

Use the 'aws cloudformation describe-stack-events' command to view the error messages.

When a CloudFormation stack enters ROLLBACK_COMPLETE, the stack is in a terminal state and cannot be updated or re-created directly. The only way to troubleshoot without deleting the stack is to inspect the stack events, which contain detailed error messages for each resource failure. The 'aws cloudformation describe-stack-events' command returns a chronological list of events, including the exact reason why resource creation failed, such as insufficient permissions, invalid AMI ID, or dependency issues. This allows the engineer to diagnose the root cause while preserving the stack for further analysis.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Use the 'aws cloudformation create-change-set' command with a rollback trigger.

    Why it's wrong here

    Using 'aws cloudformation create-change-set' is intended for previewing and applying modifications to an *existing* CloudFormation stack, not for troubleshooting a stack that failed during its initial creation. Rollback triggers, when configured, are designed to monitor specific CloudWatch alarms during stack *updates* and automatically revert changes if alarm thresholds are breached, preventing service disruption. Neither of these mechanisms provides the diagnostic event history necessary to understand the root cause of a failed stack creation.

  • ✗

    Recreate the stack using the '--on-failure DO_NOTHING' option.

    Why it's wrong here

    The '--on-failure DO_NOTHING' option is applied during stack *creation* to prevent CloudFormation from rolling back successfully provisioned resources if a subsequent resource fails. While this leaves the failed resources in place for manual inspection, it does not inherently provide the detailed error messages or event history from CloudFormation itself that explain *why* the creation failed. It requires re-attempting the stack creation, rather than diagnosing an already failed stack.

  • ✓

    Use the 'aws cloudformation describe-stack-events' command to view the error messages.

    Why this is correct

    The 'aws cloudformation describe-stack-events' command is the most effective method for troubleshooting a failed stack creation. It provides a chronological log of all events related to the stack, including the status of each resource operation (e.g., CREATE_IN_PROGRESS, CREATE_FAILED). Crucially, for failed events, it includes detailed error messages directly from the underlying AWS service, clearly indicating the specific resource that failed and the precise reason for its failure, enabling targeted debugging.

  • ✗

    Delete the stack and recreate it with the '--disable-rollback' flag.

    Why it's wrong here

    Deleting a failed stack using 'aws cloudformation delete-stack' removes all associated resources and, critically, purges the entire event history for that stack. This action eliminates the essential diagnostic information (error messages, resource statuses) that is needed to understand why the original stack creation failed. Recreating the stack with the '--disable-rollback' flag might prevent future rollbacks, but it does not help diagnose the *previous* failure, making it an inefficient troubleshooting approach.

About these practice questions

One of 1,135 original DVA-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 →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint

This DVA-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 DVA-C02 exam.