Course menuMLA-C02

Exams / MLA-C02 / Study guide / Deployment guardrails and rollback

Deployment guardrails and rollback: MLA-C02 study notes and practice questions

What to know about Deployment guardrails and rollback for the MLA-C02 exam, from the Deployment and Orchestration of ML and AI Workflows domain (24% of the exam guide), then 1 free question to test it. Part of the MLA-C02 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions ask how to update a model in production with minimal risk and automatic rollback.

Deployment guardrails

SageMaker AI updates endpoints with blue/green deployments: a new fleet (green) is created next to the old one (blue).

Traffic shifting How
All at once Shift everything, watch alarms during a baking period, roll back if they fire
Canary Shift a small share first, bake, then the rest
Linear Shift in equal steps with baking between
Rolling Replace capacity in batches; suits large models where doubling the fleet is costly
  • CloudWatch alarms (errors, latency, model metrics) trigger automatic rollback to the old fleet.
  • The old fleet stays until the deployment finishes, so rollback is fast.

Testing before full release

  • Shadow tests send a copy of production requests to the new variant; users see only the current model’s responses.
  • Production variants split traffic by weight for A/B tests, or route with TargetVariant.
  • Offline evaluation and a Model Registry approval come first.

Generative AI releases

  • Bedrock agent aliases move to a new version only after testing; switch back to roll back.
  • Version prompts in Prompt Management.
  • Run evaluation jobs before switching models.

Common traps

  • Replacing the endpoint all at once with no alarms.
  • Changing DNS by hand to roll back.
  • Shadow testing when the goal is to measure real user outcomes; shadow responses never reach users, so use an A/B test.
  • No baking period, so the rollout finishes before alarms have time to fire.
  • Alarms only on infrastructure metrics such as CPU, which miss a model that returns fast but wrong answers.

Try the 1 practice question

An esports league serves a match-prediction model from a production SageMaker AI endpoint. The team has a new model version that it expects to be more accurate, but a bad release would hurt the league's live betting partners within minutes.

The team wants the new version to receive a small share of live traffic first, and to shift the remaining traffic only if the endpoint's error and latency alarms stay quiet. If an alarm fires, traffic must return to the previous version automatically.

Which deployment approach meets these requirements?

Choose one answer.

  1. A. Replace the production endpoint configuration with the new model in a single all-at-once update, and roll back manually if partners report a problem.
  2. B. Create a second endpoint with the new model, and split traffic between the two endpoints with a weighted DNS change made by hand.
  3. C. Use a canary deployment guardrail on the endpoint to shift a small share of traffic first, with automatic rollback when CloudWatch alarms fire.
  4. D. Deploy the new model with a shadow variant that receives all traffic, so the old model only sees the requests that fail.
Show the answer and explanation

Answer: C

  • A. Wrong: An all-at-once replacement sends all traffic to the new version immediately, and rollback depends on people noticing the problem. The stem asks for a gradual shift with automatic rollback.
  • B. Wrong: Manual DNS changes give no automatic rollback on alarms and are slow to undo. The stem requires the rollback to happen without people acting.
  • C. Right: Correct. Deployment guardrails with canary traffic shifting send a small share of traffic to the new version, monitor the configured CloudWatch alarms, and roll back automatically on an alarm. The remaining traffic shifts only after the canary period passes. Learn more: Deployment guardrails for updating models in production (opens in a new tab)
  • D. Wrong: A shadow variant receives a copy of the traffic for comparison and does not serve responses to the callers. The stem asks for the new version to take live traffic with rollback.

Explanation

Deployment guardrails on a SageMaker AI endpoint use traffic shifting, such as a canary, with CloudWatch alarms that trigger an automatic rollback. All-at-once replacement and manual DNS changes lack automatic rollback, and a shadow variant does not serve the live responses.

A canary deployment with alarm-based rollback Users reach the service through a traffic-shifting layer such as a Lambda alias, load balancer or endpoint. Most traffic goes to the current version and a small share goes to the new version. A CloudWatch alarm on the new version's errors rolls traffic back to the current version. Users Traffic shifting alias, ALB or endpoint Current version most traffic New version small share first CloudWatch alarm errors, latency roll back
The endpoint's canary guardrail sends a small share of predictions to the new model and rolls back if an alarm fires.

Study

Want more on Deployment guardrails and rollback? The 5 full-length practice sets have 7 more Deployment guardrails and rollback questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Deployment guardrails and rollback

More Deployment and Orchestration of ML and AI Workflows topics