Which solution will meet these requirements?
Use a buildspec file in AWS CodeBuild to restore the DB cluster from a snapshot of the production database, run integration tests, and drop the restored database after verification.
Deploy the application to production. Configure an audit log of data control language (DCL) operations to capture database activities to perform if verification fails.
Create a snapshot of the DB cluster before deploying the application. Use the Update requires:Replacement property on the DB instance in AWS CloudFormation to deploy the application and apply the changes.
Ensure that the DB cluster is a Multi-AZ deployment. Deploy the application with the updates. Fail over to the standby instance if verification fails.
Explanations:
This option allows the DevOps team to create a temporary environment that mirrors the production database by restoring from a snapshot. By running integration tests on this restored database, they can verify the changes without impacting the production environment. Dropping the restored database after verification ensures that no unnecessary resources are left running, which is cost-effective.
Deploying the application directly to production without prior testing is risky, as it could lead to errors affecting users. While auditing DCL operations can help track changes, it does not provide a way to verify the application’s functionality before deployment. This option fails to meet the requirement of testing before deployment.
Creating a snapshot of the DB cluster before deployment does provide a backup, but it does not facilitate testing the changes prior to deployment. Using the Update requiresproperty may lead to downtime or service interruptions during the deployment process, which is not ideal for a production environment. This option does not meet the requirement of pre-deployment testing.
While ensuring the DB cluster is a Multi-AZ deployment provides high availability, deploying the application with updates and relying on a failover mechanism does not allow for testing the changes beforehand. If verification fails after deployment, it could result in service disruption. This approach does not satisfy the requirement for testing before deployment.