Microsoft AZ-900: Support, cycle de vie des services et Marketplace — Guide d'étude

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure AZ-900 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Intégrité du service, maintenance planifiée et SLA dans la gestion des incidents

Azure fournit plusieurs perspectives sur l’intégrité. Azure Status est la vue publique et globale des problèmes à l’échelle de la plateforme. Azure Service Health est personnalisé pour vos abonnements, affichant les problèmes de service, la maintenance planifiée et les avis d’intégrité affectant vos régions et ressources. Resource Health détaille l’état des ressources individuelles, fournissant les événements de disponibilité récents et les causes racines telles que des événements de la plateforme, des actions initiées par l’utilisateur ou des pannes matérielles sous-jacentes. Les alertes Service Health s’intègrent avec des groupes d’actions pour les e-mails, SMS, appels vocaux, webhooks, connecteurs ITSM et Azure Functions. La maintenance planifiée est communiquée via Service Health avec les fenêtres prévues et les détails de l’impact. Pour les machines virtuelles, Azure Scheduled Events expose des notifications au sein de l’invité (via le service de métadonnées d’instance) concernant les actions à venir comme les redémarrages, permettant aux applications de drainer les connexions, de créer un point de contrôle ou de basculer. Maintenance Control est disponible pour les Azure Dedicated Hosts et certaines tailles de VM isolées, permettant aux administrateurs de retarder la maintenance de la plateforme dans une fenêtre de report définie pour s’aligner sur les processus de contrôle des changements. Les SLA définissent les objectifs mensuels de disponibilité ou de réussite des transactions pour chaque service. Lors de l’architecture de solutions multi-services, la disponibilité combinée est multiplicative entre les dépendances. Les niveaux de disponibilité plus élevés nécessitent généralement des déploiements redondants interzones ou à plusieurs instances. Par exemple, l’exécution de machines virtuelles sur deux zones de disponibilité ou plus dans une région permet d’atteindre un SLA plus élevé qu’une seule VM ou un groupe à haute disponibilité. Si un SLA n’est pas respecté, des crédits de service sont disponibles sur demande ; soumettez la demande via le portail avec des preuves (horodatages, ressources affectées) dans la fenêtre requise, et suivez l’incident et les examens post-incident dans Service Health.

• Machines virtuelles (instance unique)
  • Exigence clé pour le SLA : SSD Premium ou Ultra Disk pour le SE et les données
  • SLA publié (typique) : 99,9 %
  • Remarques : S’applique aux tailles et au stockage éligibles ; pas de groupe à haute disponibilité/zone
• Machines virtuelles dans un groupe à haute disponibilité
  • Exigence clé pour le SLA : Deux instances ou plus réparties sur des domaines de panne/mise à jour
  • SLA publié (typique) : 99,95 %
  • Remarques : Réduit le risque lié à un seul rack et au domaine de mise à jour
• Machines virtuelles réparties sur des zones de disponibilité
  • Exigence clé pour le SLA : Deux instances ou plus réparties sur des zones dans une même région
  • SLA publié (typique) : 99,99 %
  • Remarques : Meilleure résilience régionale sans basculement inter-région
• Azure SQL Database (base de données unique)
  • Exigence clé pour le SLA : Déploiement Standard
  • SLA publié (typique) : 99,99 %
  • Remarques : La redondance interzone peut améliorer la résilience aux pannes de zone
• App Service (multi-instance)
  • Exigence clé pour le SLA : Deux instances ou plus
  • SLA publié (typique) : 99,95 %
  • Remarques : Nécessite les niveaux De base ou supérieurs avec plusieurs instances

Politique de cycle de vie moderne et la Place de marché Azure

Les services Azure suivent la Politique de cycle de vie moderne, qui met l’accent sur les mises à jour continues des services et la responsabilité du client de rester à jour. Les changements de rupture nécessitant une action du client sont communiqués avec un préavis — généralement d’au moins 12 mois pour les services en ligne — par le biais d’annonces de dépréciation formelles, d’avis Service Health et de mises à jour de la documentation. Les calendriers de retrait, le versionnage des API et les chemins de migration sont fournis afin que les charges de travail puissent être corrigées dans des fenêtres de changement qui s’alignent sur la gouvernance d’entreprise. Ce modèle de livraison continue s’appuie sur des pratiques de déploiement sécurisées avec des déploiements par étapes et une atténuation automatique. La préparation opérationnelle signifie suivre les avis de service, valider les nouvelles versions de runtime ou de SDK en pré-production, et utiliser des indicateurs de fonctionnalité (feature flags) ou des déploiements bleu-vert pour les mises à jour d’applications. Les mises à jour de sécurité et de conformité arrivent sans cycles d’installation distincts, réduisant les fenêtres d’exposition tout en mettant l’accent sur l’observabilité et la discipline de publication. La Place de marché Azure étend la plateforme avec des solutions tierces : images de machines virtuelles, applications gérées, applications Kubernetes et offres SaaS. Les offres sont facturées via votre abonnement Azure avec des options telles que la facturation à l’utilisation, des plans annuels/à terme et le modèle « apportez votre propre licence » (BYOL). Les entreprises peuvent organiser une place de marché privée pour n’autoriser que les éditeurs ou les offres approuvés, appliquer Azure Policy pour contraindre l’empreinte de déploiement (régions, SKU, réseau), et négocier des tarifs personnalisés par le biais d’offres privées. Les appliances virtuelles de réseau (par ex., pare-feu, répartiteurs de charge), les plateformes de données, l’analytique de sécurité et les piles d’observabilité sont des modèles courants ; le support de l’éditeur est le canal principal pour ces solutions, avec une facturation consolidée dans Azure.

• Image de machine virtuelle (NVA ou serveur)
  • Modèle de déploiement : Modèle ARM/VM dans votre VNet
  • Modèle de facturation : PAYG ou BYOL
  • Exemples de cas d’usage : Pare-feu, WAF, IDS/IPS, applications packagées
  • Remarques opérationnelles : Vous gérez le cycle de vie, la mise à l’échelle et les correctifs de la VM
• Application gérée
  • Modèle de déploiement : Déployée sur votre abonnement, gérée par l’éditeur
  • Modèle de facturation : PAYG plus frais de gestion
  • Exemples de cas d’usage : Solutions clés en main avec opérations gérées
  • Remarques opérationnelles : L’éditeur met à jour les composants principaux ; vous gérez les données/la configuration
• Application Kubernetes (module complémentaire AKS)
  • Modèle de déploiement : Helm/ARM dans votre cluster AKS
  • Modèle de facturation : PAYG ou BYOL
  • Exemples de cas d’usage : Contrôleurs d’entrée, maillages de services, opérateurs
  • Remarques opérationnelles : Vous gérez AKS ; l’éditeur maintient les images de conteneur de l’application
• SaaS
  • Modèle de déploiement : S’exécute dans le tenant de l’éditeur ; s’intègre avec votre tenant
  • Modèle de facturation : Abonnement/consommation
  • Exemples de cas d’usage : API, plateformes d’analytique, SaaS de sécurité
  • Remarques opérationnelles : Délai de rentabilisation le plus rapide ; infrastructure minimale à gérer

Problème pratique : Coastal Outfitters : Opérationnalisation du support, de l’intégrité et des solutions de place de marché pour un pic saisonnier d’e-commerce

Scénario : Coastal Outfitters gère un site e-commerce hébergé sur Azure avec un trafic stable la plupart du mois et une forte augmentation de trafic de quatre jours en fin de mois. L’architecture utilise une Azure Application Gateway, deux niveaux web basés sur des VM et une base de données managée. La sécurité exige un pare-feu de nouvelle génération, et les opérations doivent garantir une disponibilité de 99,99 % pour le niveau web pendant les périodes de pic, tout en recevant des conseils proactifs durant le déploiement.

Défi : Choisir le bon plan de support pour obtenir des conseils d’architecture proactifs, déployer un pare-feu de la place de marché sous gouvernance, augmenter les quotas de calcul régionaux avant le pic de trafic, et mettre en œuvre des alertes d’intégrité et des workflows d’incidents qui s’alignent sur les objectifs de disponibilité de 99,99 %.

Approche recommandée :

1. Mettre à niveau l’abonnement vers le plan de support Professional Direct pour garantir une réponse 24h/24, 7j/7 aux incidents critiques et des conseils proactifs pour le déploiement en production.
2. Attribuer le rôle intégré Support Request Contributor au groupe NOC afin qu’il puisse ouvrir et gérer des tickets sans disposer d’autorisations étendues sur les ressources.
3. Déployer un pare-feu de nouvelle génération Palo Alto Networks ou Fortinet depuis Azure Marketplace dans un VNet hub dédié ; utiliser une place de marché privée pour que seules les offres privées négociées et approuvées soient visibles par les propriétaires d’abonnement.
4. Placer au moins deux VM web dans des zones de disponibilité distinctes derrière une Application Gateway pour atteindre le SLA de 99,99 % pour les VM ; stocker le système d’exploitation et les données sur des disques Premium SSD.
5. Soumettre une demande de Service and subscription limits (quotas) deux semaines avant le pic pour augmenter les quotas de vCPU par région pour les familles de VM requises ; ajouter des réservations de capacité pour le niveau web afin de garantir la capacité en rafale.
6. Configurer des alertes Azure Service Health pour les problèmes de service, la maintenance planifiée et les avis d’intégrité dans les régions du site ; acheminer les alertes vers un groupe d’actions qui notifie le personnel d’astreinte par e-mail/SMS et ouvre un incident dans ServiceNow via le connecteur ITSM.
7. Activer la gestion des Azure Scheduled Events sur les VM web pour drainer les connexions de manière progressive pendant la maintenance de l’hôte ; valider le comportement de basculement dans l’environnement de préproduction à l’aide de permutations bleu-vert.
8. Documenter le workflow de demande de crédit SLA dans le runbook, y compris la capture de preuves (horodatages, ID de ressource, métriques), et s’assurer que les demandes sont soumises via le portail dans la fenêtre de temps autorisée si les objectifs de disponibilité ne sont pas atteints.

Justification Azure : Le plan Professional Direct combine une réponse rapide avec les avantages de conseils proactifs sans la charge d’un contrat Unified à l’échelle de l’entreprise, s’alignant sur une seule charge de travail de production critique. Les VM zonales élèvent le niveau de disponibilité à 99,99 % avec un nombre minimal d’instances, tandis que les disques Premium SSD répondent aux exigences de stockage pour une instance unique. Une place de marché privée organisée et des offres privées négociées maintiennent les appliances de sécurité en conformité et à coût maîtrisé, et le support de l’éditeur reste la première ligne pour les problèmes de NVA. Les augmentations de quota anticipées et les réservations de capacité éliminent les frictions lors du déploiement pendant le pic. Les alertes Service Health, la gestion des événements planifiés et un runbook de demande de crédit SLA complètent la boucle de gestion des incidents avec des responsabilités et des pistes de preuves claires.

← Surveillance · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →