Bootcamp Microsoft (mission ESN) — plan de 15 jours et livrables corrigés

Comment utiliser ce bootcamp

L'objectif n'est pas de mémoriser Microsoft Learn, mais de savoir expliquer une architecture, diagnostiquer un incident, justifier un choix et réaliser quelques opérations simples. Règle 30/40/30 : 30 % lecture, 40 % pratique, 30 % questions d'entretien.

Ordre logique d'administrateur : identité → réseau → compute → stockage → supervision → sécurité → Microsoft 365 → Intune → Copilot → incidents.

Jour 1 — Vue d'ensemble Azure

Programme : IaaS/PaaS/SaaS, régions et zones, abonnements, groupes de ressources, Azure Resource Manager, portail, Cloud Shell, Azure CLI.

Livrable — réponse modèle : « Un abonnement (unité de facturation et de gouvernance) contient des groupes de ressources (rg-app-prod), qui regroupent les ressources partageant le même cycle de vie. Dans le groupe : un VNet 10.20.0.0/16 découpé en sous-réseaux (snet-app, snet-data), une VM dans snet-app protégée par un NSG, sans IP publique (administration par Bastion), et un compte de stockage accessible par Private Endpoint. Tout passe par ARM, que l'on utilise le portail, la CLI ou Bicep. »

Lab : Azure — Lab 1 : environnement de base.

Jour 2 — Identité et gouvernance

Programme : Entra ID, utilisateurs, groupes, rôles, RBAC, MFA, accès conditionnel, moindre privilège.

Livrable — réponse modèle : « L'authentification prouve l'identité (mot de passe + MFA, gérée par Entra ID) ; l'autorisation détermine les actions permises (RBAC Azure : qui + rôle + portée). Cas de droits insuffisants : un utilisateur obtient AuthorizationFailed en créant une VM. Je vérifie que la connexion réussit (journaux de connexion), puis ses attributions effectives (az role assignment list --assignee … --include-groups) : il est Reader. Je n'attribue pas Owner : j'ajoute son groupe au rôle Virtual Machine Contributor sur le seul groupe de ressources concerné, et je documente. »

Lab : Azure — Lab 2 : identité et RBAC.

Jour 3 — Réseau

Programme : VNet et sous-réseaux, NSG, IP publiques et privées, DNS, VPN Gateway, peering, Bastion, Load Balancer et Application Gateway.

Livrable — réponse modèle : VNet 10.20.0.0/16 avec snet-web (10.20.1.0/24, derrière Application Gateway + WAF), snet-app (10.20.2.0/24), snet-data (10.20.3.0/24, Private Endpoints SQL et stockage). Chemin d'un paquet d'un internaute : DNS public → IP publique de l'Application Gateway (couche 7, WAF) → VM web dans snet-web (NSG : 443 depuis le sous-réseau de la passerelle uniquement) → API dans snet-app (NSG : 8080 depuis snet-web) → base via Private Endpoint dans snet-data (NSG : 1433 depuis snet-app). Les réponses suivent le chemin inverse (filtrage avec état).

Lab : Azure — Lab 3 : NSG, autoriser le nécessaire et tester les flux.

Jour 4 — Compute

Programme : VM, disques et images, groupes à haute disponibilité et zones, scale sets, notions de conteneurs/AKS et d'App Service.

Livrable — réponse modèle : VM sans IP publique, NSG n'autorisant que le port applicatif, administration par Bastion. Diagnostic RDP/SSH par couches : périmètre → état de la VM → test-ip-flow (NSG) → routes effectives → service et pare-feu de l'OS (Run Command) → identité (compte, clé). « Timeout » = réseau ; « refusé » = service.

Lab : Azure — Lab 6 : Break-Fix, l'application de la VM ne répond plus ; fiche RDP ou SSH impossible vers une VM.

Jour 5 — Stockage

Programme : comptes de stockage, Blob, Azure Files, réplication, SAS et clés d'accès, cycle de vie.

Livrable — réponse modèle : compte StorageV2 en ZRS (perte d'une zone), HTTPS seul, TLS 1.2, accès public désactivé ; conteneur Blob pour les archives, partage Files (SMB) pour remplacer un serveur de fichiers ; SAS de délégation utilisateur en lecture seule et à durée limitée pour un partenaire ; règle de cycle de vie vers le niveau froid puis archive.

Lab : Azure — Lab 4 : compte de stockage, Blob, Azure Files et SAS.

Jour 6 — Supervision

Programme : Azure Monitor, métriques, Log Analytics, alertes, Application Insights, journal d'activité.

Livrable — réponse modèle : alerte de métrique CPU moyen > 85 % sur 5 min, sévérité 2, reliée à un groupe d'actions d'astreinte. Où chercher lors d'une panne : Service Health (incident Microsoft ?) → métriques de la ressource (depuis quand ?) → journal d'activité (changement récent ?) → Log Analytics en KQL (détail) → Application Insights (erreurs applicatives, dépendances).

Lab : Azure — Lab 5 : alerte CPU, Log Analytics et journal d'activité.

Jour 7 — Sauvegarde et continuité

Programme : Azure Backup, coffre Recovery Services, RPO/RTO, snapshots, redondance, tests de restauration.

Livrable — réponse modèle : restaurer une VM : coffre › élément sauvegardé › point de restauration › créer une nouvelle VM ou remplacer les disques (ou restauration de fichiers) → vérification → bascule. Backup = revenir dans le passé (erreur, rançongiciel) ; réplication (Site Recovery) = copie quasi continue vers un autre site pour un faible RPO ; haute disponibilité = continuer pendant une panne (zones, équilibrage). Une HA ne protège pas d'une suppression : elle la réplique.

Fiche : Azure Backup — la sauvegarde d'une VM échoue.

Jour 8 — Microsoft 365

Programme : tenant, centre d'administration, Exchange Online, Teams, SharePoint, OneDrive.

Livrable — réponse modèle : Exchange = messagerie ; Teams = conversations, réunions, collaboration (fichiers stockés dans SharePoint) ; SharePoint = sites et bibliothèques documentaires ; OneDrive = espace personnel professionnel. Cycle de vie d'un compte : arrivée (création ou synchronisation depuis AD, groupes, licences, MFA) → mouvements (mise à jour des groupes et accès) → départ (désactivation, révocation des sessions, transfert de la boîte et du OneDrive au manager, retrait des licences, suppression après rétention).

Fiche : Microsoft 365 — un e-mail n'est jamais arrivé.

Jour 9 — Intune

Programme : inscription, jointure Entra, stratégies de configuration et de conformité, applications, notions d'Autopilot.

Livrable — réponse modèle : PC enregistré dans Autopilot par le fournisseur → premier démarrage, connexion de l'utilisateur → jointure Entra et inscription Intune automatiques → réception des stratégies de configuration et des applications affectées à ses groupes → évaluation de la stratégie de conformité (chiffré, à jour, Defender actif) → appareil conforme, accepté par l'accès conditionnel.

Lab : Intune — Lab 8 : Break-Fix, la stratégie ne s'applique pas sur deux postes.

Jour 10 — Sécurité

Programme : Zero Trust, MFA, accès conditionnel, Defender, RBAC, notions de PIM.

Livrable — réponse modèle (utilisateur distant) : identité protégée par MFA résistante à l'hameçonnage ; accès conditionnel exigeant un appareil conforme et bloquant les pays non autorisés ; poste géré par Intune (chiffrement, mises à jour) et protégé par Defender for Endpoint ; accès aux applications sans VPN global (proxy d'application ou ZTNA) ; données protégées par étiquettes et DLP ; droits élevés uniquement via PIM ; journaux centralisés dans Sentinel.

Jour 11 — Copilot

Programme : Copilot pour Microsoft 365, Graph, permissions, données de l'organisation, protection des données, prompts.

Livrable — réponse modèle : Copilot n'est pas un moteur de recherche public : il travaille sur les données du tenant via Graph, avec les permissions de l'utilisateur, et ses réponses dépendent de la qualité de la gouvernance (partages, étiquettes). Il peut se tromper : on vérifie ses réponses et on garde la décision humaine.

Lab : Microsoft 365 — Préparer Copilot : audit de l'oversharing ; examen Copilot, Purview et sécurité des données.

Jour 12 — Automatisation

Programme : PowerShell, Azure CLI, Graph, notions d'ARM/Bicep, idempotence, runbooks.

Livrable — réponse modèle :

# Liste les VM arrêtées mais toujours allouées (facturées) et produit un CSV exploitable
Get-AzVM -Status | Where-Object { $_.PowerState -eq 'VM stopped' } |
  Select-Object Name, ResourceGroupName, Location, PowerState |
  Export-Csv -Path vm-arretees-facturees.csv -NoTypeInformation

Le script ne modifie rien (lecture seule), peut être rejoué sans effet (idempotent), s'exécute dans un runbook Azure Automation avec une identité managée en rôle Reader, et sa sortie alimente un rapport ou un ticket.

Jour 13 — Troubleshooting

Méthode : symptôme → périmètre → journaux → hypothèse → test → correction → validation, une hypothèse à la fois, avec un compte rendu.

Livrable — réponse modèle : les cinq scénarios se trouvent dans la rubrique Troubleshooting (RDP/SSH, connexion Entra refusée, stratégie Intune, e-mail non reçu, VM lente) et dans les labs Break-Fix 6, 7, 8 et 9.

Jour 14 — Entretien technique

Programme : présentation, réponses STAR, architecture, diagnostic, sécurité, cloud hybride.

Livrable — réponse modèle : l'examen « Entretien technique Azure & Microsoft 365 » du Centre d'examen reproduit l'exercice (30 questions en 45 minutes, réponses expliquées). La banque complète des questions et réponses est dans la page Banque d'entretien Azure et Microsoft 365.

Jour 15 — Simulation finale

Livrable — réponse modèle : le Lab 10 — cas client, migration par vagues sert de simulation de 60 minutes (architecture, vagues, stratégie, plan de retour). Notez ensuite vos 10 lacunes à partir des questions ratées aux examens et des indices consultés dans les labs, et revenez aux modules Microsoft Learn correspondants.

Check-list technique

• Expliquer IaaS / PaaS / SaaS
• Dessiner une architecture Azure simple
• Expliquer VNet, sous-réseau, NSG, route, DNS
• Expliquer VM, disques et disponibilité
• Expliquer Entra ID, RBAC, MFA, accès conditionnel
• Expliquer Blob, Files, Backup
• Utiliser la logique métriques / journaux / alertes
• Expliquer Microsoft 365, Teams, SharePoint, Exchange
• Expliquer Intune, inscription et conformité
• Expliquer Zero Trust et moindre privilège

Check-list pratique

• Créer un groupe de ressources, un VNet et un sous-réseau (Lab 1)
• Créer et administrer une VM, configurer un NSG (Labs 3 et 6)
• Créer un compte de stockage (Lab 4)
• Créer une alerte et lire le journal d'activité (Lab 5)
• Trouver une erreur d'accès dans Entra (Lab 7)
• Comprendre une stratégie Intune (Lab 8)
• Écrire une commande Azure CLI ou PowerShell (tous les labs)

Check-list entretien

• Présentation de 90 secondes prête
• Trois projets racontables en contexte / action / résultat
• Une architecture Azure dessinable en 3 minutes
• Une méthode de troubleshooting claire
• Un exemple d'automatisation, un de réduction de risque, un d'incident résolu
• Une réponse honnête quand on ne sait pas
• Des questions à poser : rôle et niveau attendu, stack (Azure, M365, Entra, Intune, VMware, réseau), part build/run, astreinte, contexte hybride, outils ITSM, certifications appréciées, livrables des 3 premiers mois, organisation de l'équipe

Dernières 24 heures

Ne pas apprendre un domaine entier ; revoir Entra, réseau, VM, supervision, sécurité ; refaire un schéma Azure ; répondre à 20 questions à voix haute ; réviser deux incidents et un exemple d'automatisation ; vérifier CV et dates ; dormir.

Règle d'or : ne prétendez pas maîtriser une technologie jamais manipulée. Dites plutôt « je connais le concept, je l'ai pratiqué sur tel lab et je peux approfondir rapidement ».

Priorité si le temps manque : Entra ID → réseau Azure → VM → stockage et sauvegarde → supervision → Microsoft 365 → Intune → sécurité → Copilot.