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.

• ✓

  Configure the CloudFormation deployment action in CodePipeline with 'ActionMode' set to 'CREATE_UPDATE' and check the 'Rollback on failure' option.

  Why this is correct

  In CodePipeline, the CloudFormation deployment action requires an explicit ActionMode such as CREATE_UPDATE to create a new stack or update an existing one. When 'Rollback on failure' is selected, CloudFormation automatically rolls back the stack to its last known good state if the deployment fails, restoring both resources and stack outputs. This is the correct mechanism because it leverages CloudFormation's native rollback capability within the pipeline execution, preserving the integrity of the deployed infrastructure.

• ✗

  Use the CodePipeline console to enable 'Automatic rollback' for the Deploy stage.

  Why it's wrong here

  The CodePipeline console does not expose an 'Automatic rollback' toggle for a Deploy stage; pipeline stages only support manual or automatic transitions, which either pause execution or allow it to proceed, not rollback of prior actions. A failed pipeline action stops the execution and marks the stage as failed, but CodePipeline itself does not revert deployed resources—it simply halts. The only way to achieve rollback is to configure the underlying deployment action, such as the CloudFormation action, to trigger a rollback on failure.

• ✗

  Set the stack's 'DisableRollback' parameter to 'true' in the template.

  Why it's wrong here

  Setting the CloudFormation stack's 'DisableRollback' parameter to 'true' explicitly instructs CloudFormation to leave the stack in a failed state (e.g., CREATE_FAILED or UPDATE_ROLLBACK_FAILED) instead of performing a rollback. This is the opposite of the desired behavior: it prevents automatic recovery from a failed update and can leave the stack partially updated or unusable. Rollback on failure requires the opposite setting—'DisableRollback' must be false or the parameter omitted—so this option is categorically wrong.

• ✗

  Add a stack policy to the CloudFormation stack that denies updates to the AMI parameter.

  Why it's wrong here

  A CloudFormation stack policy is a JSON document that defines which resources or Update actions are allowed or denied during stack updates. While it can protect the AMI parameter from being changed unintentionally, it does not initiate or influence rollback behavior when a deployment fails. The policy purely acts as an access control mechanism, not a failure-handling mechanism, so it would neither trigger a rollback nor restore the stack to a prior healthy state; it only prevents certain updates from being applied.

Go deeper

Related to this question