DVA-C02 Deployment Practice Question
A company is deploying a critical application using AWS CloudFormation. The stack creation fails due to a resource creation failure. The developer needs to troubleshoot the issue. Which TWO actions should the developer take to identify the root cause? (Choose TWO.)
⚠ Common exam trap
DVA-C02 often tests whether candidates know that stack events contain the specific resource failure reason, while CloudTrail is for API auditing — the trap is picking CloudTrail or stack outputs as the primary troubleshooting source.
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
✓
View the stack events in the CloudFormation console.
Option A is correct because CloudFormation records every resource-level status transition (CREATE_IN_PROGRESS, CREATE_FAILED, etc.) as a stack event, and the event for the failed resource includes the exact StatusReason returned by the underlying service, which is the fastest way to pinpoint the root cause. Option D is correct because a resource creation failure is frequently caused by an invalid template definition — for example a bad property value, an incorrect intrinsic function reference, or a missing required parameter — so reviewing the template for logical errors validates the resource configuration against the service's requirements. Option B is not appropriate because stack outputs are only populated after resources are successfully created and are not generated for a failed stack, so they contain no troubleshooting data. Option C is not appropriate because deleting and recreating with identical parameters reproduces the same failure without gathering any diagnostic information. Option E is not appropriate because CloudTrail logs API calls made to AWS services (such as CreateStack), not the internal per-resource failure reasons that CloudFormation surfaces in stack events.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
View the stack events in the CloudFormation console.
Why this is correct
Viewing stack events in the CloudFormation console is the direct diagnostic path. During stack creation, every resource activity is logged as an event with a status (CREATE_IN_PROGRESS, CREATE_FAILED, etc.) and a 'status reason' field. That status reason for the first failed resource contains the precise underlying error returned by the AWS service (for example, an EC2 error or an IAM permission problem), making it the authoritative source for troubleshooting a failed stack.
- ✗
Check the stack outputs.
Why it's wrong here
Stack outputs are values defined in the Outputs section of the template, and CloudFormation only populates them after the stack has been successfully created or updated. If the stack creation failed, the stack never reaches a complete state, so no Outputs are available in the console or via DescribeStacks. Therefore, checking outputs offers zero diagnostic value for a failed creation.
- ✗
Delete the stack and recreate it with the same parameters.
Why it's wrong here
Deleting the failed stack triggers CloudFormation to clean up any resources that were created, which also discards the stack events and the rollback history that contained the failure reasons. Recreating with identical parameters will almost certainly reproduce the same failure, and you'll be no closer to identifying the root cause. The correct pattern is to inspect stack events and template logic before any destructive action.
- ✓
Review the stack template for logical errors.
Why this is correct
Reviewing the stack template for logical errors is a valid complementary diagnostic because CloudFormation performs template validation at submit time but not all logical issues are caught. Errors such as invalid resource property references, unresolved Refs, circular dependencies, missing DependsOn ordering, or invalid parameter constraints often surface only during provisioning. Comparing the template against the failed resource events can reveal whether a mistake in the template's structure or dependencies is responsible.
- ✗
Check AWS CloudTrail logs for the stack creation attempt.
Why it's wrong here
AWS CloudTrail records the underlying API calls that CloudFormation makes on your behalf (for example, ec2:RunInstances or iam:CreateRole), but it does not include CloudFormation-specific resource status reasons or stack-level error messages. To understand why a particular resource failed, you need the statusReason found in the stack events, not the raw AWS API logs. CloudTrail is useful for auditing who triggered the stack operation, not for diagnosing mostly internal CloudFormation resource failures.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 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 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.