TL;DR: For a model, promotion is a pointer change plus a traffic change, not an artifact copy. The same immutable file stays in object storage; you reassign an alias (or approve a model package), a CD job shifts traffic progressively with auto-rollback alarms, and the old version stays warm. Deploy and release are decoupled, so promotion is purely a routing decision and instantly reversible.
How to approach it
This question exists because "promoted the model to production" appears on every MLOps resume, and the interviewer wants to know if you can name what physically happens. The trap is describing a generic code deploy. The strong answer states the punchline early: for a model, promotion is usually a pointer change plus a traffic change, not an artifact copy.
A strong answer
First disambiguate, because "staging" means two different things and conflating them is the tell: there's the registry state (a model version marked staging/@challenger in MLflow or SageMaker Model Registry) and the environment (a staging endpoint serving test traffic). Promotion involves both, and nothing about the artifact itself changes, the same immutable file trained once sits in object storage throughout. What you're changing is which version production points at.
Then give the mechanics, concretely. In an MLflow shop: the candidate version has passed its gates, so promotion is reassigning an alias, client.set_registered_model_alias("fraud", "champion", 14). Serving infrastructure that loads models:/fraud@champion picks up version 14 on its next resolution, or a CD job reacts to the registry event and rolls the serving deployment. In a SageMaker shop: approve the model package in the registry, which triggers a pipeline that creates a new endpoint configuration and shifts traffic between variants, typically canary or linear shifting with CloudWatch alarms attached, so 10% of traffic hits the new version and an alarm on error rate or latency auto-rolls the weights back. On Kubernetes with KServe, it's editing the InferenceService spec so the canary revision's traffic percentage walks from 10 to 100.
So "push staging to production" decomposes into: gates passed (evaluation versus champion, latency and container tests, often a human approval recorded in the registry) → pointer reassigned (alias, approval status, or spec) → traffic shifted progressively with automatic rollback triggers → old version kept warm, because instant rollback is the reason the pointer pattern exists.
A habit worth describing because almost nobody does it: rehearse the rollback before the first promotion, not during the first incident. In staging, flip the alias backward under representative load and measure what actually happens: how long until serving resolves the old version (cached alias lookups can pin the new model for minutes if the resolution TTL is generous), whether the prior version was genuinely warm or had been garbage-collected by an eager cleanup job, and whether in-flight requests complete on the version that started them. Each of those has burned a real team, and each is invisible until the flip is exercised. The rehearsal takes an afternoon, produces a measured number for the incident runbook ("rollback is 40 seconds, not 'fast'"), and changes the promotion conversation with a nervous customer from "we can roll back quickly" to "we rolled back on Tuesday as a drill; here is the timing." Interviewers hear the difference immediately, because one of those sentences can only be said by someone who has operated the pattern.
One more sentence that lands well: the deploy and the release are decoupled. The new model can be fully deployed, container running, model loaded, while receiving 0% of traffic. Promotion is then purely a routing decision, which is what makes it both fast and reversible.
What interviewers probe next
- "What gates have to pass before the flip?", offline eval vs champion on a fixed holdout plus a recent time slice, container integration test with golden requests, latency budget under load, and for regulated models a recorded approver.
- "How do you roll it back?", same pointer, opposite direction: alias back to the prior version or variant weights back to 100/0, in minutes; which is why the previous version stays deployed and warm for a soak period rather than being torn down.
- "Who or what is allowed to flip the alias?", the CD pipeline's service identity, not humans with prod write access; promotion permissions on the registry are an access-control surface people forget.
- "Does the artifact get rebuilt for production?", no, and it must not: rebuild means retrain means a different model than the one you validated. Same artifact, new pointer.
Common mistakes
Describing a code deployment, "merge to main, CI builds, deploys to prod", without ever mentioning a registry, an alias, or traffic weights; this is the exact failure the question is designed to surface. Conflating registry stage with staging environment. Saying "we copy the model to the prod bucket," which implies mutable, untraceable deployment state. And having no rollback story, when the entire point of pointer-based promotion is that rollback is one reassignment away.