DVA-C02 Deployment Practice Question

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.