Intermédiaire

Stockage, continuité et applications

Comptes de stockage et redondance, sauvegarde et Site Recovery, supervision Monitor et Log Analytics, conteneurs et App Service.

▶

Module 5 — Stockage : comptes, redondance et blobs

Stockage 15 %

1. Compte de stockage et redondance

Le compte de stockage v2 à usage général (StorageV2) héberge blobs, fichiers, files d’attente et tables. Son nom est globalement unique (3 à 24 caractères, minuscules et chiffres). La redondance choisie à la création détermine la résilience : LRS (3 copies dans un datacenter), ZRS (3 zones), GRS (région secondaire), GZRS (zones + région secondaire).

Pourquoi c'est important : le stockage porte les sauvegardes, les disques de VM et les données applicatives : un compte en LRS ne survit pas à une perte de région, un conteneur public expose des sauvegardes sur Internet, des clés volées ouvrent tout le compte. L'examen exige de choisir la redondance et le niveau d'accès au plus juste.

L'analogie qui aide : le compte de stockage est une médiathèque : les conteneurs sont les rayons, les niveaux Chaud, Frais et Archive sont la salle de lecture, la réserve mensuelle et les archives au sous-sol, la redondance LRS, ZRS ou GRS est le nombre de photocopies gardées sur place, dans les autres bâtiments ou dans une autre ville.

az group create --name RG-Data --location francecentral

# Compte géoredondant + conteneur privé
az storage account create --name sthorizon5app --resource-group RG-Data --sku Standard_GRS --kind StorageV2 --location francecentral
az storage container create --account-name sthorizon5app --name sauvegardes --public-access off

# Lister les clés (rotation : 2 clés pour basculer sans interruption)
az storage account keys list --resource-group RG-Data --account-name sthorizon5app

2. Niveaux d’accès et protection

Le niveau Chaud convient aux données fréquentes, Frais aux données mensuelles, Archive aux archives longue durée (récupération en heures). La suppression réversible conserve les blobs supprimés pendant N jours ; la SAS (signature d’accès partagé) délègue un accès limité dans le temps sans exposer les clés.

Démonstration pas à pas : az storage account create fabrique sthorizon5app en Standard_GRS, donc chaque écriture est répliquée vers la région jumelée ; az storage container create isole les sauvegardes en accès privé ; az storage account keys list affiche les deux clés pour une rotation sans coupure ; la rétention de suppression à trente jours protège de l'effacement accidentel et la SAS en lecture seule jusqu'au 31 décembre délègue un accès borné sans livrer les clés.

# Suppression réversible 30 jours + SAS lecture 1 an sur le conteneur
az storage blob service-properties update --account-name sthorizon5app --enable-delete-retention true --delete-retention-days 30
az storage container generate-sas --account-name sthorizon5app --name sauvegardes --permissions r --expiry 2026-12-31

3. Synthèse : redondances

Option	Copies	Résiste à
LRS	3, un datacenter	Panne disque/rack locale
ZRS	3, trois zones	Perte d’un datacenter
GRS	LRS + région jumelée	Perte d’une région
GZRS	ZRS + région jumelée	Perte zone + région

Point d’examen : par défaut le compte accepte Internet : restreindre via pare-feu et réseaux virtuels, imposer HTTPS (TLS 1.2) et préférer l’accès Entra ID aux clés partagées. Azure Files expose des partages SMB/NFS avec snapshots et File Sync.

Pièges classiques : laisser l'accès public du conteneur ouvert ; mettre des archives rarement lues en niveau Chaud et payer le plein tarif ; croire que GRS protège d'une suppression accidentelle sans suppression réversible ; distribuer la clé du compte au lieu d'une SAS limitée en permissions et en durée.

À vous de jouer : un partenaire doit lire les sauvegardes jusqu'à fin décembre sans voir les clés du compte. Quelle commande utilisez-vous et quel niveau réseau vérifiez-vous ?

Voir la réponse

Générez une SAS avec az storage container generate-sas en permissions r et expiry au 31 décembre, conteneur en public-access off, puis restreignez le pare-feu du compte et imposez HTTPS : le partenaire lit sans jamais toucher aux clés.

▶

Module 6 — Sauvegarde et Site Recovery

Supervision 15 %

1. Azure Backup (sauvegarde)

Azure Backup protège VM, fichiers et bases via un coffre Recovery Services et une stratégie (fréquence + rétention). La sauvegarde restaure un état passé (RPO en heures) ; elle ne remplace pas la haute disponibilité.

Pourquoi c'est important : une suppression de disque ou un rançongiciel sans point de récupération récent signifie une perte sèche de données. En entreprise, la question n'est pas si la panne arrivera mais à quel point de restauration vous reviendrez, et en combien de temps le service repartira.

L'analogie qui aide : Backup est la photocopie quotidienne rangée dans un coffre ignifugé, Site Recovery est la salle de secours chauffée dans une autre ville avec des copies réchauffées toutes les minutes, les zones de disponibilité sont les piliers redondants du même bâtiment. On ne demande pas à une photocopie de remplacer une salle de secours.

az group create --name RG-Backup --location francecentral

# Coffre + activation de la protection avec la stratégie par défaut
az backup vault create --resource-group RG-Backup --name Coffre-Prod --location francecentral
az backup protection enable-for-vm --resource-group RG-Backup --vault-name Coffre-Prod --vm VM-Web01 --policy-name DefaultPolicy

# Sauvegarde immédiate avant une maintenance risquée
az backup protection backup-now --resource-group RG-Backup --vault-name Coffre-Prod --container-name VM-Web01 --item-name VM-Web01 --retain-until 2030-01-01

2. Azure Site Recovery (reprise d’activité)

Site Recovery réplique en continu les VM vers une région secondaire (RPO de quelques minutes) et orchestre le basculement via des plans de reprise. On teste le plan avec un test failover isolé, sans impacter la production. RTO et RPO sont les deux objectifs à connaître : durée maximale d’interruption acceptable et perte de données maximale acceptable.

Démonstration pas à pas : az backup vault create crée le coffre Coffre-Prod ; az backup protection enable-for-vm rattache VM-Web01 à la stratégie DefaultPolicy pour des sauvegardes régulières ; az backup protection backup-now force un point de récupération juste avant la maintenance à risque ; en parallèle, Site Recovery répliquerait la VM vers la région jumelée avec un plan de basculement testé par test failover sans toucher à la production.

Service	Question	Réponse
Backup	Restaurer un fichier supprimé hier ?	Oui (point de récupération)
Site Recovery	Basculer le service en région secours ?	Oui (réplication + failover)
Zones de disponibilité	Survivre à la perte d’un datacenter ?	Oui (haute disponibilité)

Point d’examen : ne pas confondre sauvegarde (restauration dans le temps), réplication (continuité en région secours) et haute disponibilité (zones, scale sets). Le coffre chiffre les points de récupération, en LRS ou GRS.

Pièges classiques : demander à Backup d'assurer un basculement régional, demander à Site Recovery de restaurer un fichier d'hier, lancer un vrai basculement au lieu d'un test failover pour valider le plan, confondre RTO (durée d'interruption) et RPO (perte de données).

À vous de jouer : un fichier a été supprimé hier et, en parallèle, la direction exige un redémarrage du service en région secours en cas de sinistre régional. Backup ou Site Recovery dans chaque cas ?

Voir la réponse

Fichier supprimé hier : Azure Backup avec le point de récupération adéquat. Sinistre régional : Site Recovery avec réplication continue et plan de basculement. Ce sont deux services complémentaires, jamais interchangeables.

▶

Module 7 — Supervision : Monitor, Log Analytics et alertes

Supervision 15 %

1. Métriques, journaux et KQL

Azure Monitor collecte les métriques (valeurs numériques temps réel : CPU, réseau) et les journaux centralisés dans un espace Log Analytics, interrogés en KQL (Kusto Query Language). Le journal d’activité trace le plan de contrôle : créations, attributions RBAC, déploiements.

Pourquoi c'est important : sans supervision, une saturation CPU ou des échecs de connexion passent inaperçus jusqu'à l'incident majeur. Une alerte bien réglée avec un groupe d'actions réveille l'astreinte avant les utilisateurs et déclenche une remédiation automatique au lieu d'un appel à trois heures du matin.

L'analogie qui aide : Monitor est la tour de contrôle : les métriques sont les cadrans temps réel du cockpit, les journaux Log Analytics sont les boîtes noires rejouées en KQL, les alertes sont les alarmes de seuil, et le groupe d'actions est la liste d'appel qui prévient le pilote, le mécanicien ou déclenche le pilote automatique.

# Créer une alerte CPU moyen supérieur à 80 % sur la VM
az monitor metrics alert create --name Alert-CPU-Haute --resource-group RG-Monitor --scopes /subscriptions/xxx/resourceGroups/RG-Compute/providers/Microsoft.Compute/virtualMachines/VM-Web01 --condition "avg Percentage CPU > 80" --description "CPU superieur a 80 pourcent"

# Consulter le journal d'activité récent
az monitor activity-log list --resource-group RG-App --start-time 2026-09-01T00:00:00Z

2. Exemples de requêtes KQL

// CPU moyen par ordinateur (compteurs invité, agent Azure Monitor)
Perf
| where CounterName == "% Processor Time"
| summarize avg(CounterValue) by Computer

// Échecs de connexion récents
SigninLogs
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, ResultDescription
| sort by TimeGenerated desc

3. Groupes d’actions

La règle d’alerte se déclenche sur une condition ; le groupe d’actions route la notification vers e-mail, SMS, application vocale, webhook, fonction Azure, runbook Automation ou ITSM. C’est le cœur de la remédiation automatique.

Démonstration pas à pas : az monitor metrics alert create surveille le Percentage CPU moyen de VM-Web01 au-delà de 80 pour cent sur l'étendue exacte de la VM ; az monitor activity-log list contrôle qui a créé ou modifié quoi dans RG-App ; côté KQL, la requête Perf filtre CounterName puis summarize par Computer, et SigninLogs filtre ResultType différent de zéro pour isoler les échecs. Le flux complet va de la collecte par l'agent Azure Monitor jusqu'à l'alerte routée par le groupe d'actions.

Donnée	Source	Usage
Métriques hôte	Plateforme Azure	Alertes temps réel
Compteurs invité	Agent AMA + règle de collecte	Disque, mémoire, processus
Journal d’activité	Plan de contrôle	Audit et alertes

Point d’examen : KQL se lit de gauche à droite avec des pipes : table, where, summarize, project, sort. Les métriques invitent nécessitent l’agent Azure Monitor et une règle de collecte de données (DCR).

Pièges classiques : attendre des compteurs invités sans agent Azure Monitor ni règle de collecte ; lire KQL à l'envers au lieu de suivre les pipes ; créer une alerte sans groupe d'actions et ne prévenir personne ; confondre métriques temps réel et journaux historiques.

À vous de jouer : vous devez lister le CPU moyen par machine puis les échecs de connexion récents. Quelles tables et quelles clauses KQL utilisez-vous ?

Voir la réponse

Perf avec where CounterName égal à % Processor Time puis summarize avg par Computer pour le CPU ; SigninLogs avec where ResultType différent de zéro puis project et sort par TimeGenerated desc pour les échecs. Les compteurs invités exigent l'agent et une DCR.

▶

Module 8 — Conteneurs et App Service

Compute 15 %

1. Azure Container Instances et AKS

Azure Container Instances (ACI) exécute des conteneurs serverless facturés à la seconde, sans cluster à gérer : idéal pour des tâches ponctuelles. Azure Kubernetes Service (AKS) orchestre des conteneurs à grande échelle avec mise à l’échelle, auto-réparation et réseau avancé. Azure Container Registry (ACR) stocke les images privées.

Pourquoi c'est important : déployer un site sur des VM quand un App Service suffirait, c'est payer le système d'exploitation pour rien ; monter un cluster AKS pour une tâche ponctuelle, c'est sortir l'artillerie pour une course locale. Le bon choix de service divise la facture et le travail d'exploitation.

L'analogie qui aide : App Service est l'hôtel tout compris où la chambre (l'application) se loue sans entretenir l'immeuble (le plan porte la capacité), ACI est la trottinette louée à la minute pour une course unique, AKS est la flotte de bus avec chauffeurs, horaires et ateliers de réparation intégrés.

2. App Service : application web managée

App Service héberge des applications web sans gérer les VM : le plan App Service définit la capacité (SKU, instances, zone), l’application porte le code et le runtime. Les slots de déploiement permettent un swap sans interruption après validation.

Démonstration pas à pas : az appservice plan create réserve la capacité Plan-Prod en SKU B1 ; az webapp create y dépose l'application Python 3.11 ; az container create lance le traitement ponctuel worker-taches en serverless avec redémarrage OnFailure. Le flux financier suit la capacité : le plan est facturé même avec une application arrêtée, alors que le conteneur ACI ne facture que son exécution à la seconde.

az group create --name RG-Web --location francecentral

# Plan + application web Python, puis conteneur serverless
az appservice plan create --resource-group RG-Web --name Plan-Prod --sku B1
az webapp create --resource-group RG-Web --plan Plan-Prod --name app-horizon5 --runtime "PYTHON|3.11"
az container create --resource-group RG-Web --name worker-taches --image mcr.microsoft.com/azuredocs/aci-helloworld --cpu 1 --memory 1.5 --restart-policy OnFailure

3. Synthèse : choisir le service

Besoin	Service	Gestion
Site web sans serveur à gérer	App Service	Plateforme managée
Conteneur ponctuel	Container Instances	Serverless
Microservices à grande échelle	AKS	Cluster orchestré

Point d’examen : le plan App Service porte le coût (SKU + instances), pas l’application. Pour un conteneur isolé et rapide, ACI ; pour l’orchestration (replicas, services, ingress), AKS.

Pièges classiques : croire qu'arrêter l'application stoppe la facturation du plan ; choisir ACI pour des microservices avec réplicas et ingress au lieu d'AKS ; déployer en production sans slot de validation puis subir une interruption ; oublier qu'ACR reste obligatoire pour des images privées.

À vous de jouer : un site Python à héberger sans gérer de VM et une tâche de calcul ponctuelle : quels services choisissez-vous et où porte le coût ?

Voir la réponse

App Service pour le site avec un plan B1, facturé sur le plan même si l'application est arrêtée, avec un slot pour le swap sans interruption ; ACI pour la tâche ponctuelle, facturée à la seconde sans cluster à gérer. AKS seulement si l'orchestration devient nécessaire.

Niveau suivant : Expert Tester mes connaissances