Deployment strategies and third-party tools: SOA-C03 study notes and practice questions
What to know about Deployment strategies and third-party tools for the SOA-C03 exam, from the Deployment, Provisioning, and Automation domain (22% of the exam guide), then 2 free questions to test it. Part of the SOA-C03 study guide.
Deployment strategy questions describe constraints (no downtime, full capacity, quick rollback, low cost) and ask for the strategy.
The strategies
Strategy
How
Trade-off
All at once
Update every instance together
Fastest and cheapest; downtime if it fails
Rolling
Update in batches
No extra cost; reduced capacity during the deploy
Rolling with additional batch
Launch a new batch first, then roll
Keeps full capacity; a little extra cost
Immutable
Launch a whole new set of instances, swap when healthy
Full capacity, quick safe rollback (terminate the new set); costs more during the deploy
Blue/green
A complete new environment; switch traffic
Instant rollback by switching back; double cost briefly
Canary
Send a small share of traffic to the new version first, then the rest
Limits impact of a bad release
Linear
Shift traffic in equal steps over time
Gradual exposure
Where they appear
AWS Elastic Beanstalk: all at once, rolling, rolling with additional batch, immutable, traffic splitting (canary), and blue/green by swapping environment URLs.
AWS CodeDeploy: in-place or blue/green for EC2; for Lambda, canary or linear shifting through an alias; for ECS, blue/green with traffic shifting. CloudWatch alarms can stop a deployment and roll back automatically.
Amazon ECS rolling updates with minimum healthy percent and maximum percent, and the deployment circuit breaker for automatic rollback.
Auto Scaling instance refresh for rolling replacement of instances.
Third-party and other tools
CloudOps engineers often run Terraform or other infrastructure tools, Git for templates, and CI/CD pipelines. AWS supports them with the AWS provider, CodePipeline integrations and state stored in S3. Know that they fit alongside CloudFormation, not that you must replace them.
Common traps
Rolling when full capacity must be kept. Use rolling with additional batch or immutable.
All at once for production. It risks downtime.
Blue/green without automated traffic switching and rollback alarms.
A dental chain's booking application runs in an AWS Elastic Beanstalk environment with 12 instances.
Rolling deployments reduce capacity during busy hours, and when a bad version was released last month, rolling back took 40 minutes.
The chain wants deployments that keep full capacity, put no new code on existing instances, and allow a fast rollback by simply removing new instances. The environment's URL and DNS must not change.
Which deployment policy should a CloudOps engineer choose?
Choose one answer.
AA. All at once, so that the new version reaches every instance together and the deployment finishes as quickly as possible.
BB. Rolling with additional batch, so that a new batch of instances is launched first and capacity stays full during deployment.
CC. Immutable, so that the new version goes to new instances in a temporary Auto Scaling group.
DD. Blue/green with a CNAME swap, so that the new version runs in a separate environment before traffic moves to it.
C. Right: Correct. Immutable deployments launch a full set of new instances alongside the old ones and move them in only when they pass health checks. Rolling back means terminating the new instances, and the environment's URL stays the same. Learn more: Deployment policies and settings (opens in a new tab)
Elastic Beanstalk offers several deployment policies. Immutable deployments never change existing instances, keep full capacity and make rollback a matter of terminating the new instances, all inside the same environment. Blue/green also gives quick rollback, but it relies on swapping the environment's CNAME.
A pet insurer releases new versions of its premium-calculation AWS Lambda function with AWS CodeDeploy.
Last week, a faulty version reached all users at once and returned errors for 20 minutes before anyone noticed.
The team wants each new version to receive a small share of traffic first, and the deployment to roll back automatically if errors rise, without human action.
Which TWO changes should a CloudOps engineer make? (Choose two.)
Choose two answers.
AA. Point a Route 53 weighted record at the old and new function versions, and adjust the weights by hand during each release.
BB. Publish each new version and have clients call the version number directly, so that the team can change it back if errors appear.
CC. Use the CodeDeployDefault.LambdaCanary10Percent5Minutes deployment configuration for the function's deployment group.
DD. Use the CodeDeployDefault.LambdaAllAtOnce deployment configuration and lower the function's reserved concurrency during deployments.
EE. Add a CloudWatch alarm on the function's error metric to the deployment group and turn on rollback when an alarm threshold is met.
Show the answer and explanation
Answers: C, E
A. Wrong: Lambda versions are not DNS endpoints, and manual weight changes need human action. Traffic shifting between Lambda versions is done with alias routing, which CodeDeploy manages. Learn more: Weighted routing (opens in a new tab)
CodeDeploy shifts traffic between Lambda versions through an alias. A canary configuration sends a small share of traffic to the new version first, and CloudWatch alarms attached to the deployment group trigger automatic rollback when errors rise. Together they limit the impact of a bad release without anyone watching.
CodeDeploy shifts 10 percent of traffic for 5 minutes, and the error alarm rolls the alias back automatically.
Want more on Deployment strategies and third-party tools? The 5 full-length practice sets have 10 more Deployment strategies and third-party tools questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →