Courseiva
SDLC AutomationhardMultiple SelectObjective-mapped

DOP-C02 CloudFormation stack events Practice Question

A company uses AWS CloudFormation to deploy a multi-tier application. The stack creation fails with a 'CREATE_FAILED' error for a resource. The engineer wants to troubleshoot the issue. Which TWO steps should the engineer take? (Choose TWO.)

⚠ Common exam trap

The main trap is that candidates may incorrectly think that CloudFormation automatically creates a CloudWatch Logs log group for all stack errors (Option B), or prematurely delete the stack (Option D) instead of investigating the failure using stack events and the ResourceStatusReason field.

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 'describe-stack-events' AWS CLI command to view the events.

The 'describe-stack-events' AWS CLI command retrieves all stack events, including the specific event for the failed resource. This event contains the 'ResourceStatusReason' field, which provides the detailed error message from CloudFormation explaining why the resource creation failed. Option C is correct because checking the 'ResourceStatusReason' field in the stack events directly reveals the underlying error. Option B is incorrect because CloudFormation does not automatically create a CloudWatch Logs log group for stack errors; resource-specific logs are only available if the resource itself writes to CloudWatch. During a stack creation failure, there may be no such logs to review. Option D is incorrect because deleting the stack would lose the event history and prevent effective troubleshooting. Option E is incorrect because 'describe-stacks' only returns stack outputs and status, not failure details.

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 'describe-stack-events' AWS CLI command to view the events.

    Why this is correct

    The describe-stack-events AWS CLI command is the correct programmatic way to inspect the full event history of a stack, including each resource's CREATE_FAILED event followed by the overall stack rollback event. Each event object contains a ResourceStatusReason property with the detailed error thrown by the failed resource, along with the logical resource ID, physical resource ID, and timestamps. This command is ideal for automation because it returns the exact same failure information you would see in the CloudFormation console, allowing you to log or alert on the root cause.

  • Review the CloudWatch Logs log group for the stack to find detailed error logs.

    Why it's wrong here

    CloudFormation does not automatically create a CloudWatch Logs log group for stack errors. Resource-specific logs are only available if the resource itself writes to CloudWatch, which may not be the case during a creation failure.

  • Check the 'ResourceStatusReason' field of the failed resource in the stack events.

    Why this is correct

    Each CloudFormation stack event for a resource includes a ResourceStatusReason field that carries the exact error message reported by the resource provider (e.g., an EC2 instance not being created due to a subnet issue). This field is the authoritative source for why that specific resource failed, and it is visible in the AWS console on the Events tab or retrievable via the CLI. Without it, you would only see a generic CREATE_FAILED status with no actionable detail.

  • Run 'delete-stack' to remove the failed stack and start over.

    Why it's wrong here

    Running delete-stack on a failed stack immediately removes the stack and its event history, making it impossible to query the events afterwards to determine what went wrong. CloudFormation retains stack events only while the stack exists, and deletion permanently erases that troubleshooting record. You should first inspect the ResourceStatusReason from the stack events to understand the failure; if the issue is a misconfigured parameter or transient resource problem, you may be able to update or retry the stack without paying the cost of a full teardown.

  • Use the 'describe-stacks' AWS CLI command to get the stack outputs.

    Why it's wrong here

    The describe-stacks AWS CLI command returns stack-level metadata such as the overall StackStatus, stack Parameters, Tags, Capabilities, and any Outputs that were generated during successful creation. It does not expose individual resource events, so if a resource fails during create, this command will only tell you that the stack entered CREATE_FAILED or ROLLBACK_COMPLETE, not which resource caused the failure or why. Since Outputs are typically only populated after resources are created successfully, they are rarely useful for diagnosing a mid-creation failure.

About these practice questions

One of 1,013 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 →

How Courseiva writes practice questions · Editorial policy

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.