Bootcamp Microsoft — les 10 labs de synthèse corrigés

Les cinq questions à se poser

Pour chaque lab, l'entretien porte moins sur les commandes que sur cinq réflexes : quel est le risque principal ? quel est le point de supervision ? quel est le moindre privilège ? comment revenir en arrière ? comment documenter ? Les réponses ci-dessous sont des modèles à reformuler avec vos mots.

Lab 1 — Azure : environnement de base

Lab simulé : Azure — Lab 1 : environnement de base. Critère : présenter l'architecture en 3 minutes.

• Risque principal : un environnement non gouverné — ressources sans étiquettes, VM exposée avec une IP publique, tout dans une seule zone.
• Supervision : journal d'activité du groupe de ressources, métriques de la VM, alertes de budget.
• Moindre privilège : Contributor limité au groupe de ressources pour l'équipe, Reader pour les autres.
• Retour arrière : ressources déployées en Bicep ; suppression du groupe de ressources en environnement de test.
• Documentation : schéma (abonnement → groupe → VNet → sous-réseaux → VM/stockage), plan d'adressage, étiquettes, propriétaires.

Lab 2 — Identité et RBAC

Lab simulé : Azure — Lab 2 : identité et RBAC. Critère : expliquer pourquoi on préfère un groupe et le moindre privilège.

• Risque principal : droits trop larges ou jamais retirés (accumulation, compte compromis = accès étendu).
• Supervision : journaux d'audit Entra (ajouts de membres, attributions de rôles), revues d'accès.
• Moindre privilège : Reader sur le seul groupe de ressources, attribué à un groupe, et PIM pour les rôles élevés.
• Retour arrière : az role assignment delete ; retrait du membre du groupe.
• Documentation : qui, quel rôle, quelle portée, pourquoi, jusqu'à quand.

Lab 3 — Réseau

Lab simulé : Azure — Lab 3 : NSG, autoriser le nécessaire et tester les flux. Critère : distinguer DNS, route, NSG, pare-feu et service.

• Risque principal : un port d'administration (22/3389) ouvert à Internet, ou une règle trop large.
• Supervision : journaux de flux NSG (VNet flow logs) et Traffic Analytics, test-ip-flow pour prouver une décision.
• Moindre privilège : n'ouvrir que le port du service, depuis la source nécessaire (étiquettes de service, sous-réseaux).
• Retour arrière : supprimer ou rétablir la règle ; NSG versionné en IaC.
• Documentation : matrice de flux (source, destination, port, justification, propriétaire).
• DNS / route / NSG / pare-feu / service : le nom se résout-il ? le paquet sait-il où aller ? est-il autorisé par le NSG, puis par le pare-feu (Azure Firewall, OS) ? le service écoute-t-il ?

Lab 4 — Stockage

Lab simulé : Azure — Lab 4 : compte de stockage, Blob, Azure Files et SAS. Critère : expliquer Blob contre Files et le choix de réplication.

• Risque principal : conteneur public ou clé de compte diffusée ; perte de données sans protection.
• Supervision : journaux de diagnostic du stockage, Defender for Storage, alertes de capacité.
• Moindre privilège : rôles de données (Storage Blob Data Reader), SAS de délégation utilisateur limités, accès par clé désactivé.
• Retour arrière : suppression réversible (soft delete), versionnage des blobs, snapshots de partage.
• Documentation : redondance choisie et pourquoi, règles de cycle de vie, qui accède à quoi.
• Blob ou Files : objet par HTTP/API contre partage SMB/NFS. Réplication : LRS (un datacenter), ZRS (zones), GRS/GZRS (autre région).

Lab 5 — Supervision

Lab simulé : Azure — Lab 5 : alerte CPU, Log Analytics et journal d'activité. Critère : expliquer comment passer d'une alerte à un incident.

• Risque principal : ne pas être prévenu, ou l'être trop souvent (fatigue d'alertes).
• Supervision : métriques, Log Analytics, journal d'activité, Service Health.
• Moindre privilège : Monitoring Reader pour la consultation, Monitoring Contributor pour gérer les alertes.
• Retour arrière : désactiver ou ajuster une alerte bruyante sans la supprimer.
• Documentation : seuils et justification, groupe d'actions, procédure de réponse (runbook).
• Alerte → incident : l'alerte se déclenche → qualification (impact, périmètre) → ouverture de l'incident avec priorité → diagnostic (métriques, journaux, changement récent) → correction réversible → surveillance → clôture et analyse de cause.

Lab 6 — VM troubleshooting

Lab simulé : Azure — Lab 6 : Break-Fix, l'application de la VM ne répond plus. Critère : méthode de diagnostic par couches.

• Risque principal : agir au hasard (redémarrer, ouvrir des ports) et masquer la cause.
• Supervision : état de la VM, Resource Health, métriques, journaux de l'OS et de l'application.
• Moindre privilège : Virtual Machine Contributor ou Run Command limité ; Bastion plutôt qu'une IP publique.
• Retour arrière : revenir à la configuration précédente, snapshot avant intervention.
• Documentation : compte rendu d'incident (cause, correction, prévention).
• Couches : plateforme → réseau (NSG, route) → hôte → service → application → identité.

Lab 7 — M365 / Entra

Lab simulé : Entra ID — Lab 7 : Break-Fix, connexion refusée en déplacement. Critère : décrire le cycle de vie d'un utilisateur.

• Risque principal : un compte orphelin après un départ, ou une exception d'accès conditionnel jamais retirée.
• Supervision : journaux de connexion et d'audit, Entra ID Protection (risques).
• Moindre privilège : rôles d'administration ciblés (User Administrator, Helpdesk Administrator), pas d'administrateur global au quotidien.
• Retour arrière : restauration d'un utilisateur supprimé pendant 30 jours ; retrait de l'exception.
• Documentation : procédures d'arrivée, de mouvement et de départ.
• Cycle de vie : création (ou synchronisation), groupes, licences, MFA → mouvements → départ : désactiver, révoquer les sessions, récupérer les données, retirer les licences, supprimer après rétention.

Lab 8 — Intune

Lab simulé : Intune — Lab 8 : Break-Fix, la stratégie ne s'applique pas sur deux postes. Critère : expliquer affectation, conformité et dépannage.

• Risque principal : une stratégie diffusée à tout le parc sans test, qui bloque des postes.
• Supervision : état des affectations, rapports de conformité, postes non synchronisés.
• Moindre privilège : rôles Intune délimités (étendues de rôle, balises d'étendue).
• Retour arrière : retirer l'affectation, ou affecter une stratégie corrective.
• Documentation : groupes ciblés, paramètres, raisons, calendrier de déploiement.
• Affectation : qui reçoit (groupes, filtres) ; conformité : évaluation de l'état ; dépannage : affectation → synchronisation → conflits → journaux.

Lab 9 — Architecture hybride

Lab simulé : Azure hybride — Lab 9 : Break-Fix, les VM Azure ne résolvent plus les noms internes. Critère : présenter les dépendances et le plan de reprise.

• Risque principal : une dépendance commune (DNS, identité, lien VPN, certificat) qui coupe tout.
• Supervision : état des connexions VPN/ExpressRoute, tests synthétiques de résolution DNS, santé d'Entra Connect.
• Moindre privilège : comptes de synchronisation dédiés, rôles réseau limités au hub.
• Retour arrière : configuration précédente des règles DNS et des routes, documentée.
• Documentation : schéma datacenter + Azure (VPN ou ExpressRoute, Entra hybride, DNS hybride), points de panne et ordre de reprise (réseau → DNS → identité → applications).

Lab 10 — Cas client complet

Lab simulé : Azure — Lab 10 : cas client, planifier la migration par vagues. Critère : présenter architecture et plan en 10 minutes.

• Risque principal : migrer un serveur sans ses dépendances, ou basculer sans plan de retour.
• Supervision : Azure Monitor dès la vague pilote, tableaux de bord de migration, suivi des coûts.
• Moindre privilège : équipes de migration avec des droits limités aux spokes concernés.
• Retour arrière : plan de retour testé avant chaque bascule (serveurs sources conservés jusqu'à validation).
• Documentation : inventaire, dépendances, vagues, critères de réussite, runbooks d'exploitation.
• Feuille de route type : découverte (Azure Migrate) → landing zone (réseau, identité, sécurité, supervision, sauvegarde, FinOps) → pilote → vagues par application → optimisation et passage en exploitation.