DOP-C02 SDLC Automation 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.

• ✗

  Increase the stack creation timeout to allow more time for the database to be created.

  Why it's wrong here

  Increasing the stack creation timeout only adjusts how long CloudFormation waits before declaring the overall stack creation failed; it does not address resource-level validation errors that occur immediately during the DBInstance provisioning. If the database resource returns a CREATE_FAILED status quickly, the problem is almost always an invalid configuration parameter (e.g., unsupported DB instance class, wrong engine, or misconfigured DB subnet group), not a lack of time. Timeout changes would leave the root cause unresolved and would merely delay the same failure.

• ✓

  Check the CloudFormation stack events for a detailed status message from the DBInstance resource.

  Why this is correct

  Checking the CloudFormation stack events is the most direct and authoritative diagnostic step because every resource action logs a status reason that mirrors the exact API error returned by the RDS service. For a DBInstance failure, the event's status message will contain the precise reason—such as an invalid DB instance class, insufficient subnet coverage, or a parameter group mismatch—saving you from guesswork. The events tab also shows the sequence of resource creation, so you can determine whether the failure is isolated to the database or caused by a dependency like a VPC or subnet group that failed earlier.

• ✗

  Verify that the VPC has at least two public subnets in different Availability Zones.

  Why it's wrong here

  Verifying that the VPC has at least two public subnets is incorrect because an Amazon RDS database does not require public subnets; it can be deployed entirely within private subnets. The actual networking requirement is that the DB subnet group contains at least one subnet in two or more Availability Zones, and those subnets can be private. Public subnets with an Internet Gateway are only necessary if you explicitly enable Public Access on the RDS instance, which is neither required by CloudFormation templates nor a common cause of stack creation failure.

• ✗

  Use the Amazon RDS console to check if a DB instance with the same identifier already exists.

  Why it's wrong here

  Using the RDS console to check for an existing DB instance with the same identifier is a possible but indirect and incomplete approach. A duplicate identifier would indeed cause a failure, but that is only one of many potential causes, and CloudFormation stack events already capture the specific error message from the RDS CreateDBInstance call. Furthermore, DB instance identifiers are scoped per AWS account and region, so collisions are less common; even if one exists, you would still need to examine stack events to confirm the failure reason and decide whether to change the identifier or delete the old instance.

Go deeper

Related to this question