Q76 — AWS DOP-C02 Ch.3
Question 76 of 100 | ← Chapter 3
• The application must deploy one instance at a time to ensure the message queue continues serving traffic. • The application is CPU-intensive and requires monitoring. • If the deployed instance’s CPU utilization exceeds 85%, the deployment must automatically roll back.
- A. Use AWS CloudFormation to create an AWS Step Functions state machine and Auto Scaling lifecycle hooks to place one instance at a time into a wait state. Use AWS Systems Manager Automation to deploy updates to each instance and use heartbeat timeouts to return it to the Auto Scaling group.
- B. Use AWS CodeDeploy integrated with Amazon EC2 Auto Scaling. Configure an alarm associated with the CPU utilization metric. Use the CodeDeployDefault.OneAtATime deployment strategy. Configure automatic rollback in the deployment group to revert on alarm threshold violation. ✓
- C. Use AWS Elastic Beanstalk with load balancing and AWS Auto Scaling. Configure an alarm associated with the CPU utilization metric. Configure a rolling deployment with a fixed batch size of one instance. Enable enhanced health to monitor deployment status and trigger rollback based on the previously created alarm.
- D. Use AWS Systems Manager to perform blue/green deployments through Amazon EC2 Auto Scaling. Configure an alarm associated with the CPU utilization metric. Deploy one updated instance at a time. Configure automatic rollback in the Auto Scaling group to revert on alarm threshold violation.
Correct Answer: B. Use AWS CodeDeploy integrated with Amazon EC2 Auto Scaling. Configure an alarm associated with the CPU utilization metric. Use the CodeDeployDefault.OneAtATime deployment strategy. Configure automatic rollback in the deployment group to revert on alarm threshold violation.
Explanation
Option B is correct. AWS CodeDeploy integrates natively with Amazon EC2 Auto Scaling and supports the OneAtATime deployment strategy, enabling sequential instance updates. It also supports automatic rollback triggered by CloudWatch alarms—including CPU utilization thresholds—ensuring immediate remediation if performance degrades beyond 85%. Elastic Beanstalk (Option C) supports rolling deployments and alarms but lacks native, granular rollback tied directly to custom metrics during deployment phases. Options A and D involve complex custom orchestration and do not provide built-in, metric-driven rollback capabilities like CodeDeploy.