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.

• ✓

  Take a snapshot of the RDS database before the migration.

  Why this is correct

  A manual RDS snapshot taken immediately before the migration is the only mechanism that provides a point-in-time, database-level restore point independent of the application deployment. If the migration script corrupts data or fails mid-transaction, you can restore the instance from this snapshot and redeploy the previous code version, ensuring a clean rollback. This is the standard pre-migration practice because other options either target application code only or do not give you a deterministic restore point for the database itself.

• ✗

  Use CloudFormation with a custom resource to run the migration.

  Why it's wrong here

  CloudFormation custom resources can execute arbitrary logic (like a Lambda function that runs a migration script), but they are an implementation detail for running the migration, not a rollback strategy. The custom resource only signals success or failure to CloudFormation; it does not automatically capture a database restore point or revert schema changes. Relying on it for rollback would require you to manually author compensating actions inside the custom resource logic, which is error-prone and not a standard, out-of-the-box recovery mechanism for schema migrations.

• ✓

  Use CodeDeploy's AppSpec file to run a migration script in the AfterInstall lifecycle hook.

  Why this is correct

  CodeDeploy's AfterInstall lifecycle hook is the correct place to execute a migration script because it runs after the new application version is staged but before the deployment is marked complete. This ordering means the migration script has the new code in place, and if the script fails, CodeDeploy can fail the deployment and, with auto-rollback enabled, redeploy the previous version. However, the hook itself does not restore the database to a pre-migration state — it only provides the execution point for the migration script.

• ✗

  Use AWS Database Migration Service (DMS) to replicate the database continuously.

  Why it's wrong here

  AWS DMS is designed for continuous, asynchronous replication between database endpoints, typically for migrations between different database engines or for ongoing synchronization to a data warehouse. It is not a rollback mechanism for a one-time schema migration run during a CI/CD pipeline. Even if you used DMS to replicate continuously, the target schema changes would be replicated too, and you could not easily rewind to a pre-migration database state without manual intervention or point-in-time recovery from backups.

• ✓

  Configure the CodeDeploy deployment group to automatically roll back on failure.

  Why this is correct

  Configuring auto-rollback in the CodeDeploy deployment group handles the application side of a failed deployment: it automatically redeploys the last known good revision and triggers the AfterInstall hook of that old revision. For this to fully restore the database to a clean state, the deployment group's rollback event must be paired with a database restore action (e.g., a script in the old revision's AppSpec that restores from the pre-migration RDS snapshot). Auto-rollback alone does not repair schema changes; it only reverts the application code, so it is a correct component of the rollback strategy but not sufficient without the snapshot.

Go deeper

Related to this question