Vous avez publié la version 2.1.0 d'une image dans une Azure Compute Gallery et vos modèles ARM référencent la version "latest". Après avoir déployé de nouveaux hôtes de session, vous découvrez une régression dans la version 2.1.0. Vous devez empêcher les déploiements futurs d'utiliser la version 2.1.0 lorsque "latest" est spécifié, mais la maintenir disponible pour des tests limités, et planifier un retour arrière pour les hôtes affectés. Quelles sont les deux actions à entreprendre ? (Choisissez-en deux.)

Marquer la version d'image 2.1.0 comme "Exclure de la dernière version" dans l'Azure Compute Gallery est correct car cela empêche les futurs déploiements utilisant "latest" de sélectionner cette version, tout en la conservant disponible pour des tests spécifiques. Provisionner des hôtes de session de remplacement à partir de la version d'image stable précédente et purger/supprimer les hôtes affectés du pool est correct car cela permet de restaurer rapidement le service pour les utilisateurs en remplaçant les hôtes problématiques par des hôtes fonctionnels. Supprimer la version d'image 2.1.0 n'est pas idéal car cela empêcherait tout test ou analyse ultérieure de la régression. Modifier les déploiements pour qu'ils se fixent à la version 2.0.0 est une solution temporaire mais ne résout pas le problème de la version "latest" et nécessiterait une modification de tous les modèles ARM. Réimager les machines virtuelles affectées avec Azure Update Manager n'est pas la méthode standard pour un retour arrière d'image dans AVD et pourrait être plus complexe qu'un remplacement direct.