SOA-C02 Deployment, Provisioning, and Automation Practice Question
A SysOps administrator is troubleshooting a CloudFormation stack that failed to create. The stack includes an Amazon RDS DB instance. The error message indicates that the DB instance name already exists. The stack uses a parameter for the DB instance identifier. What should the administrator do to resolve this issue and create the stack?
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
✓
Delete the failed stack, change the DB instance identifier parameter to a unique name, and recreate the stack.
When a CloudFormation stack creation fails due to a naming conflict (e.g., DB instance identifier already exists), the failed stack must be deleted because it cannot be updated or continued. Changing the parameter to a unique name and recreating the stack resolves the conflict. Option B is incorrect because, while deleting the conflicting DB instance would resolve the name conflict, the failed stack still exists and must be deleted before recreating the stack; in addition, deleting an existing DB instance is not the recommended approach — you should use a unique identifier. Option C is incorrect because `update-stack` cannot be applied to a failed stack creation; the stack is in a failed state and must be recreated. Option D is incorrect because `ContinueUpdateRollback` is used for update rollbacks, not for failed creations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Delete the failed stack, change the DB instance identifier parameter to a unique name, and recreate the stack.
Why this is correct
Deleting the failed stack is the correct first step because CloudFormation creation failures can leave resources in a transient or partially rolled-back state, and the stack cannot be updated or reused while it is in ROLLBACK_COMPLETE. Then changing the DB instance identifier parameter to a globally/regionally unique name avoids the RDS naming conflict that caused the failure; RDS DB instance identifiers must be unique per account within a Region. Finally, recreating the stack with the new parameter allows CloudFormation to provision a fresh DB instance without colliding with an existing resource, so this is the only approach that directly addresses the root cause.
- ✗
Manually delete the DB instance from the AWS Management Console and then retry the stack creation.
Why it's wrong here
The DB instance that caused the identifier conflict is not the one CloudFormation attempted to create—since the stack creation failed and rolled back, no DB instance from this stack exists. The conflict comes from a pre-existing DB instance in the account/Region that already holds that identifier, so manually deleting it from the console would remove an unrelated, possibly production resource and risk data loss. Even if you deleted that pre-existing instance, you would still need to clean up the failed stack and then recreate it; the safer and correct action is to choose a new unique identifier rather than deleting another resource.
- ✗
Use the AWS CLI command aws cloudformation update-stack with a new parameter value.
Why it's wrong here
While tempting because `update-stack` is used for modifying existing stacks, it cannot resolve a *creation* failure due to a pre-existing resource. The error indicates the DB instance identifier is already in use, preventing the *initial creation* of the stack. Updating a stack requires it to exist first, which is not the case here. This command is suitable for changing parameters on an *already created* or *updating* stack, not for fixing a failed initial creation.
- ✗
Execute ContinueUpdateRollback on the stack to retry the creation.
Why it's wrong here
ContinueUpdateRollback is an AWS CloudFormation API intended for recovering stacks that failed during an *update*—specifically, stacks in the UPDATE_ROLLBACK_FAILED state. In this scenario, the stack is in ROLLBACK_COMPLETE because the *creation* failed, not an update; there is no previous successful template or parameter set to roll back to. Running ContinueUpdateRollback on a failed creation stack will result in a validation error, and it does nothing to resolve the RDS identifier conflict, so it is not a valid option for this situation.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-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 SOA-C02 exam.