DOP-C02 Configuration Management and IaC 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.

• ✗

  Manually create the stack in the failed account using the same template.

  Why it's wrong here

  Manually creating the stack in the failed account bypasses CloudFormation StackSets governance entirely. The manually created stack becomes a drifted, out-of-band resource that StackSets no longer tracks, so you lose centralized visibility, auditability, and automated update/delete capabilities. It also risks divergence from the canonical template, and any future StackSet operations will not reconcile or manage this stack, creating an operational liability.

• ✓

  Use the 'Update stack instances' operation for the failed target account.

  Why this is correct

  The 'Update stack instances' operation is the correct remediation because it targets only the specific stack instance that failed inside the target account/region. CloudFormation StackSets treats a failed stack instance as an operation that can be retried without affecting other stack instances or the stack set definition. This operation re-invokes the deployment logic for that single instance, allowing transient issues such as permission timeouts or resource contention to resolve while preserving the centralized management model.

• ✗

  Update the entire stack set to retry all stack instances.

  Why it's wrong here

  Updating the entire stack set to retry a single failure is inefficient and unnecessarily broad. This operation triggers stack updates across all stack instances in all target accounts and regions, which can cause unintended changes, interruptions, or resource replacements in accounts that were unaffected. Moreover, it does not specifically isolate the root cause of the original failure, and it increases the blast radius of the retry action, making it a poor operational choice.

• ✗

  Delete the stack instance from the stack set and add it again.

  Why it's wrong here

  Deleting the stack instance and then re-adding it is more disruptive and not efficient. Deleting a stack instance marks the underlying stack for deletion, which typically destroys its resources; re-adding then recreates them from scratch, leading to downtime and potential data loss if resources aren't properly retained. It also requires the deletion operation to complete successfully before you can add it back, which may fail if the stack is already in a failed state, and it does not preserve the original stack's physical resources. This approach is far riskier than simply updating the existing failed stack instance.

Go deeper

Related to this question