MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

A fraud-detection team trains a model in SageMaker and wants to shift 10 percent of live prediction traffic to a newly retrained model to compare accuracy before a full cutover. The endpoint already serves the current model on one production variant. They need the endpoint to route a controlled fraction of requests to the new model without changing the client application. What should they do?

⚠ Common exam trap

The trap here is reaching for DNS-level or batch mechanisms for traffic splitting, when SageMaker production variant weights operate per invocation on a single endpoint.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Update the existing endpoint to add a second production variant for the retrained model and set its initial variant weight to 10 while the original variant keeps 90.

Production variants with weights are the native SageMaker mechanism for sending a percentage of live traffic to a new model on the same endpoint. Adding a variant for the retrained model and assigning it a weight of 10 while the incumbent holds 90 yields a canary deployment that clients see as a single endpoint. Weights can be adjusted as confidence grows and the old variant removed at full cutover.

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 existing endpoint to add a second production variant for the retrained model and set its initial variant weight to 10 while the original variant keeps 90.
Why this is correct
SageMaker production variants let one endpoint host multiple models with assigned weights, and InvokeEndpoint distributes traffic according to those weights. Setting the new variant to 10 and the existing one to 90 shifts a controlled fraction of requests without any client change, since the client still calls the same endpoint name. This is the built-in mechanism for canary-style traffic shifting.
✗
Enable an inference pipeline on the endpoint and place the retrained model as the second container in the pipeline.
Why it's wrong here
An inference pipeline chains containers so the output of one feeds the next, which is for preprocessing plus inference, not for splitting traffic between two competing models. Adding the retrained model as a pipeline stage would run both models on the same request in sequence and change the response semantics. It does not produce a 10/90 traffic split.
✗
Use a SageMaker batch transform job against the live traffic stream to score 10 percent of requests with the retrained model.
Why it's wrong here
Batch transform processes datasets in bulk from Amazon S3; it is not attached to a live real-time endpoint and cannot intercept a fraction of online requests. Fraud decisions require synchronous responses, which batch transform does not provide. It also requires duplicating the input data to S3, adding latency and complexity unrelated to the canary goal.
✗
Create a new endpoint for the retrained model and use Route 53 weighted routing to send 10 percent of DNS queries to the new endpoint.
Why it's wrong here
Route 53 weighted routing distributes DNS resolution, but clients cache DNS and reuse connections, so the split is coarse and not per-request. It also requires a second endpoint and does not integrate with SageMaker variant weights. The team wants per-invocation control and no client change, which DNS routing cannot reliably provide.

Go deeper

MLA-C01 Deployment and Orchestration of ML Workflows Practice Question

Why each option matters

Option-by-option breakdown

Related to this question