SOA-C02 Deployment, Provisioning, and 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.

• ✗

  Update the security groups to allow traffic from the new environment.

  Why it's wrong here

  Updating security groups is not a required or sufficient step for an Elastic Beanstalk platform update. When you perform an immutable update or a blue/green deployment via a cloned environment, Elastic Beanstalk automatically provisions and attaches the appropriate security groups to the new instances and load balancer. Manually modifying security groups in this context is irrelevant to the traffic cutover and could introduce unintended access issues without contributing to a smooth update.

• ✗

  Take a snapshot of the attached Amazon RDS database before starting the update.

  Why it's wrong here

  Taking an RDS snapshot before the update is a prudent backup action, but it does nothing to reduce or eliminate downtime during the platform version upgrade. Snapshotting only protects against data loss and provides a restore point; it does not facilitate traffic shifting, rollback of the application fleet, or seamless connection handover. You still need a deployment strategy like immutable or blue/green to achieve the stated requirement of minimal downtime.

• ✓

  Perform a blue/green deployment by cloning the environment and swapping the CNAME.

  Why this is correct

  Performing a blue/green deployment by cloning the environment, updating the clone to the new platform, and then swapping the CNAME is indeed a valid way to minimize downtime and lets you test the new version without affecting production. It gives you a full staging environment and an instant cutover via DNS, but it requires manual orchestration to keep the clone current and to execute the CNAME swap. While it achieves minimal downtime, it demands more operational effort than simply enabling immutable updates, which handles the entire process automatically.

• ✓

  Enable immutable updates in the environment configuration.

  Why this is correct

  Enabling immutable updates creates a completely new Auto Scaling group with the new platform version, performs health checks, and only after the new instances pass does it transfer all traffic and terminate the old instances. This process uses the existing environment's URL and load balancer, so there is no DNS change, and rollback is as simple as terminating the new fleet if health checks fail. It is the native Elastic Beanstalk option that directly minimizes downtime with minimal manual effort.

• ✗

  Manually drain connections from the current environment before swapping.

  Why it's wrong here

  Manually draining connections from the current environment before swapping is unnecessary because Elastic Beanstalk already manages connection draining for you during deployments. It deregisters instances from the load balancer, lets in-flight requests finish, and only then terminates old instances. If you manually drain the current environment while it is actively serving production traffic, you risk dropping active sessions or forcing users to reconnect before the new environment is ready, which is counterproductive to minimizing downtime.

Go deeper

Related to this question