Quiz sur les déploiements Canary et Shadow

Les réponses et les explications apparaissent au fur et à mesure que vous répondez au quiz.

1. Qu'est-ce qui définit un déploiement Canary ?
   • Acheminer un petit pourcentage du trafic réel vers la nouvelle version tout en la surveillant
   • Envoi de tout le trafic vers la nouvelle version en même temps
   • Exécuter la nouvelle version uniquement le week-end
   • Déploiement sans aucune surveillance
2. Quelle est la caractéristique clé d’un déploiement fantôme ?
   • Ses réponses sont servies à la moitié des utilisateurs
   • Il reçoit du trafic en miroir mais ses réponses sont ignorées et ne sont pas présentées aux utilisateurs
   • Il ne fonctionne que dans l'environnement de développement
   • Il remplace immédiatement le modèle de production
3. What does a shadow deployment protect users from, and what can it still cost?
   • It uses no extra resources and cannot access user data
   • Its predictions are returned to every user
   • Candidate responses are withheld, but mirrored inference still consumes compute and needs side-effect controls
   • It guarantees the candidate has no production impact of any kind
4. How does user-facing traffic differ between a canary and a shadow?
   • Both always send candidate output to every user
   • A shadow deployment never uses production inputs
   • A canary is only an offline test
   • A canary serves candidate responses to a defined live-traffic segment; a shadow typically does not
5. What should a team define before starting a canary or shadow rollout?
   • Traffic rules, monitoring thresholds, rollout duration, and a rollback owner
   • A promise that the candidate will outperform production
   • A fixed traffic percentage that must never change
   • A requirement to expose every user to the candidate
6. Comment les déploiements Canary et Shadow se complètent-ils ?
   • C'est la même chose avec des noms différents
   • Shadow valide le comportement sur le trafic en direct sans risque pour l'utilisateur ; Canary valide l'impact réel de l'utilisateur sur une petite tranche
   • Canary rejette les réponses pendant que l'ombre les sert
   • Ni l’un ni l’autre n’implique le trafic de production
7. What should an operator do before mirroring production requests to a shadow model?
   • Allow the shadow model to execute writes twice
   • Assume copied requests contain no sensitive data
   • Isolate side effects and protect the handling of copied request data
   • Disable all monitoring of the candidate
8. What does a canary reveal that a shadow deployment does not directly measure?
   • Whether candidate inference consumes compute
   • How its predictions compare offline
   • Whether a model can load in the serving stack
   • How the candidate affects users who are actually served by it