0 — Utiles (concepts épars zappés ou survolés)

Notions qui sont pas dans une fiche dédiée AZ-305 mais qui reviennent souvent en design. Souvent vues vaguement en AZ-104, à clarifier ici.

A. Role-assignable Groups (Entra ID)

Le problème : si tu veux donner un rôle Entra (ex: Helpdesk Admin) à plusieurs users d'un coup, normalement tu le fais user par user. Lourd. Le role-assignable group permet d'assigner le rôle au groupe une fois, puis ajouter/retirer des users du groupe pour gérer l'accès.

Caractéristiques

• Licence : Entra ID P1 requis.
• Création : uniquement à la création du groupe → option Microsoft Entra roles can be assigned to the group cochée. Irréversible (ni on, ni off après création).
• Types acceptés : Security ou Microsoft 365 groups. Membership : Assigned uniquement (pas dynamic).
• Protection : par défaut, seul un Privileged Role Administrator ou Global Admin peut modifier le groupe (membres, owners, settings). Les Group Owners standards ne peuvent PAS modifier ce type de groupe → protège des escalades de privilège.

Use case

Tu as 5 users qui doivent être Helpdesk Admin. Au lieu d'assigner le rôle 5 fois → 1 role-assignable group "HelpdeskTeam" + 1 assignment du rôle au groupe + 5 ajouts au groupe.

Piège exam

🚨 "Un user a été ajouté à un groupe mais n'a pas le rôle Entra associé" → le groupe doit avoir été créé role-assignable. Si oublié à la création → recréer le groupe (pas modifiable).

B. App Proxy — sécurité + auth protocols

App Proxy = reverse proxy managé par Azure pour publier une app on-prem privée sur Internet sans VPN ni inbound firewall, avec auth Entra ID + SSO. Déjà vu AZ-104 fiche 3.

Sécurité — pourquoi c'est sûr

Protocoles d'auth supportés

Piège exam

🚨 App on-prem qui parle Kerberos (ex: SharePoint Server, vieille app .NET) → App Proxy avec KCD (Kerberos Constrained Delegation). Configurer le connector pour qu'il demande des tickets Kerberos au nom du user Entra connecté.

C. Microsoft Entra ID Governance Suite (4 piliers)

Couvre l'objectif AZ-305 "Recommend a solution for identity governance" (domaine 1). Partiellement vu AZ-104 (PIM, Access Reviews brièvement). Ici : vue d'ensemble exam + features avancées.

Vue d'ensemble — 4 piliers + PIM

Entra ID Governance répond à 5 questions :

1. Quels users doivent avoir accès à quelles ressources ? → Entitlement Management
2. Que font-ils avec cet accès ? → Access Reviews + Audit logs
3. Y a-t-il un contrôle organisationnel ? → PIM (privileged) + Lifecycle Workflows
4. Les auditeurs peuvent-ils prouver que ça marche ? → All features + audit logs
5. Les users sont-ils prêts day 1 et révoqués à temps ? → Lifecycle Workflows

Entitlement Management — l'essentiel

Self-service access requests pour internal users + external (B2B guests).

Composants :

• Catalog : panier de ressources (groups, apps, SharePoint sites)
• Access Package : bundle prêt à demander = ressources catalog + policy (qui demande, qui approuve, expiration, MFA required, justification)
• Connected organizations : whitelist tenants partenaires externes
• Auto-assignment policies : règles attribut user (ex department=Sales → auto-assign "Sales Tools" access package)

Use case design : "partners externes auto-onboardés sans intervention helpdesk" → Access Package configuré pour Users from other directories ou Anyone (sign-up flow) → invitation B2B auto + provisionning ressources + expiration auto fin projet.

Access Reviews — l'essentiel

Recertification périodique d'accès. Audit-ready ISO 27001, RGPD, SOC 2.

Reviewable items :

• Membres d'un groupe (security ou M365)
• Role assignments (Entra ID roles + Azure RBAC + role-assignable groups)
• Guests dans le tenant (clean-up B2B fantômes)
• Access package assignments (lifecycle policy)
• PIM eligible role assignments

Workflow :

1. Créer review : scope (ce qui est revu), reviewer (manager / owner / self-review), fréquence (one-time / weekly / monthly / quarterly / annual)
2. Reviewer reçoit notif email + lien portail
3. Décision par row : Approve / Deny / Don't know (Don't know = comme Deny si auto-apply)
4. Auto-apply ou manual : si Deny → l'user est retiré du groupe / rôle révoqué automatiquement
5. Audit log : qui a approuvé quoi, quand, justification

ML-assisted review (Entra ID P2) : recommandations IA "ce user semble inactif sur ce groupe → propose deny".

Lifecycle Workflows — l'essentiel (LE plus net new AZ-305)

Automatise les processes joiner / mover / leaver (JML). Avant LWF : scripts PowerShell + tickets ITSM = lourd, sources d'erreurs.

Concepts :

• Workflow = collection de tasks déclenchées par un trigger
• Trigger : event-based (employeeHireDate-7j, employeeLeaveDate) ou on-demand
• Scope : userType=Member ou Guest, department=..., etc.

Built-in tasks (à connaître AZ-305) :

• Send welcome email to user
• Send manager notification email
• Add user to groups (joiner)
• Add user to teams
• Enable / disable user account
• Remove user from all groups (leaver)
• Remove user from all teams
• Delete user
• Run custom Logic App (extensibilité pour scénarios complexes)
• Generate Temporary Access Pass (TAP) for new joiner first sign-in

Patterns design AZ-305 :

• Joiner day-7 (pre-hire) : RH set employeeHireDate → workflow envoie email welcome + génère TAP + ajoute groupes par défaut + notifie manager
• Mover : changement attribute department → re-évaluation auto-assign access packages + remove ancien dept groups
• Leaver J-Day : employeeLeaveDate atteint → disable account + remove all groups + remove all teams + notify manager
• Leaver J+30 : delete user account (RGPD cleanup)

Licensing — critique 2026

⚠️ Piège exam 2026 : depuis janvier 2026, MS impose l'add-on "Entra ID Governance for Guests" pour utiliser les features Governance avancées sur des guest users. Sans cet add-on → impossible de créer access reviews ML-assisted scopés guests, ou Lifecycle Workflows ciblant userType=Guest. → Pour B2B Gouvernance enterprise = budget supplémentaire.

Identity Governance Administrator role

Rôle Entra spécifique (Identity Governance Administrator) — granulaire, permet de gérer Entitlement Mgmt + Access Reviews + Lifecycle Workflows sans être Global Admin. Best practice : assigner à l'équipe IAM via role-assignable group + PIM.

Pièges design Identity Governance

• Acheter P2 puis croire que Lifecycle Workflows sont inclus → ❌ add-on séparé "Entra ID Governance"
• Configurer access reviews sans auto-apply → reviewers approuvent, mais rien ne se passe automatiquement → faux sentiment de sécurité
• Lifecycle Workflows trigger sur employeeHireDate mais HR système ne push pas cet attribut → workflow jamais déclenché
• Leaver workflow active immédiatement disable+delete sans grace period → si erreur RH, user supprimé définitivement (data SharePoint, Teams perdus). Toujours grace period (ex disable J+0, delete J+30)
• Oublier le nouveau add-on Governance for Guests pour scénarios B2B → budget surprise + features bloquées

D. NAT Gateway — outbound only

Déjà vu AZ-104 fiche 4. Rappels critiques AZ-305 :

• Outbound uniquement : ❌ pas d'inbound. C'est un service de SNAT massif pour les VMs d'un subnet.
• Subnet-level : attaché à 1 subnet (1 subnet = 1 NAT GW max, mais 1 NAT GW peut couvrir plusieurs subnets).
• Public IP : 1 PIP ou un Public IP Prefix /28 (16 IPs) → jusqu'à 16 IPs × 64k ports ≈ 1M ports SNAT. Résout les SNAT exhaustion des LB standard.
• Zone scope : zonal (à 1 zone) — pour HA cross-zone = déployer 1 NAT GW par zone.
• Route auto via system route : pas besoin d'UDR (NAT GW remplace la route 0.0.0.0/0 → Internet automatiquement).

Piège exam

🚨 "Je veux qu'une IP Internet se connecte à mes VMs derrière NAT GW" → ❌ impossible. NAT GW = outbound only. Pour inbound → Public IP sur VM, ou LB/App Gateway/Front Door en frontend.

Combo classique design

NAT GW (outbound) + Public LB ou App Gateway (inbound) sur le même VNet → outbound massif + inbound contrôlé.

E. ASG (Application Security Group)

Déjà vu AZ-104 fiche 4. Précision AZ-305 :

Sur quoi ça s'attache ?

• NICs uniquement (pas directement sur VMs, mais en pratique ça revient au même puisque chaque VM a 1+ NIC).
• ❌ Pas sur subnets, ❌ pas sur App Service, ❌ pas sur Storage, ❌ pas sur PaaS génériques.

Contraintes

• Toutes les NICs d'un ASG = MÊME VNet (régional).
• ASG locked sur le VNet dès la 1ère association.
• 1 NIC peut être dans plusieurs ASGs.
• Pas de nesting (ASG ne contient pas un autre ASG).

Use case design

Au lieu d'écrire des règles NSG par CIDR ("subnet web → subnet db port 1433"), tu fais :

NSG rule : source=ASG-web → destination=ASG-db port 1433 Allow

→ Indépendant des plages IP, indépendant du subnet → réutilisable, lisible.

Piège exam

🚨 "Appliquer des règles à des App Services ou Storage Accounts via ASG" → ❌ impossible. ASG = NICs de VM uniquement. Pour PaaS → Service Tag, Private Endpoint, ou firewall ressource.

F. Azure Blueprints (deprecated 11 juil 2026, encore en exam AZ-305)

Package réutilisable d'artifacts (Resource Groups, Policies, Role assignments, ARM templates) déployable de façon cohérente sur des subscriptions. Remplacé MS par Template Specs + Azure Policy + Deployment Stacks, mais encore au programme exam jusqu'à la date de retraite.

Definition vs Assignment — scoping ⭐

🚨 Piège case study type : "3 MGs avec 5 subs au total, 1 blueprint par MG (artifacts différents)" → Definitions = 3 (1 par MG), Assignments = 5 (1 par subscription).

⚠️ Distractors :

• "Definitions = nombre de subscriptions" = faux (c'est l'assignment qui est subscription-level)
• "Assignments = nombre de MGs" = faux (assignment = subscription only)
• "Definition au root MG toujours" = faux (on prend le scope minimum couvrant les cibles)

ARM Templates vs Azure Blueprints

🚨 ARM vs Blueprints — règle clé : ARM templates = stateless one-shot, PAS de lien persistant avec les ressources. Blueprints = restent liés aux ressources, tracker audit/compliance des deployments.

⚠️ Distractors :

• "ARM templates restent connectés post-deploy" = faux (c'est Blueprints)
• "Policy uniquement dans ARM ou uniquement dans Blueprints" = faux (les deux supportent policies + role assignments + RGs)

⚠️ MS a annoncé déprécation Blueprints (→ Template Specs + Deployment Stacks) le 11 juil 2026, mais encore testé en exam AZ-305.

G. Azure Policy — workflow remediation (DeployIfNotExists / Modify)

Pour remédier des ressources existantes non-conformes (les nouvelles sont auto-remédiées au déploiement par l'effet deployIfNotExists / modify).

Ordre canonique D-A-R

1. Create policy Definition (effet deployIfNotExists ou modify)
2. Create policy Assignment (MG / sub / RG) + assigner une managed identity (system-assigned) au scope de l'assignment
3. Grant role permissions à la MI (typiquement Contributor sur le scope) pour qu'elle puisse modifier les ressources non-conformes
4. Create remediation task ciblant les ressources existantes non-conformes

🚨 Mnémo ordre : D-A-R → Definition → Assignment (+ MI + role) → Remediation task.

⚠️ Distractors / pièges :

• Inverser definition ↔ assignment = impossible (on assigne ce qu'on a défini)
• Oublier la MI / role = le remediation task ne peut pas modifier les ressources → fail silencieux
• Effets audit ou deny = PAS besoin de remediation task (ils ne modifient pas les ressources, juste log ou refusent)

💡 Bonne pratique : la MI doit avoir le rôle minimum requis (rarement Contributor full) — chercher le built-in role spécifique recommandé par la policy (ex: Log Analytics Contributor pour deployIfNotExists Diagnostic Settings).

H. Azure Files — tiers (Transaction Optimized / Hot / Cool / Premium)

Notion AZ-104 territory, ressort souvent en AZ-305 design data storage. Le bon tier dépend du ratio ops/storage (lourd transactions vs lourd capacité) et du pattern d'accès (fréquent vs rare).

Comparatif tiers Azure Files

Règle de choix ⭐

• Ratio ops/GB élevé (= heavy IO sur peu de data) → Transaction Optimized
• Ratio ops/GB faible (= peu d'IO sur beaucoup de data) → Cool
• Usage général équilibré → Hot
• Latence < 10ms ou IOPS élevés → Premium (seul tier SSD)

🚨 Piège exam : "file share usage général, accès fréquent" → souvent Hot ou Transaction Optimized. La distinction se joue sur les transactions : si l'app fait beaucoup d'open/read/write par seconde → Transaction Optimized ; si c'est browsing + écritures modérées → Hot.

⚠️ Distractors :

• Cool pour "accès fréquent" = ❌ pénalité transactions chères
• Premium pour "économies" = ❌ Premium = tier le plus cher (SSD)
• Confondre "Standard" et "Transaction Optimized" = Standard a été renommé Transaction Optimized

I. VNet — CIDR overlap & GatewaySubnet sizing

Notion AZ-104 territory mais piège récurrent en design AZ-305 (hub-spoke, peering, hybrid connectivity).

CIDR overlap = peering échoue silencieusement 🚨

• Le CIDR d'un VNet Azure ne doit JAMAIS chevaucher avec :
  • On-prem (VPN S2S / ExpressRoute) → routing cassé, traffic ambigu
  • D'autres VNets peerés (direct ou transitif via hub)
  • Pool d'IPs P2S VPN clients
• Détection : pre-flight check avant peering — si overlap, peering en statut Initiated ou Connected mais traffic ne passe pas (fail silencieux, pas d'erreur claire)

GatewaySubnet — règles strictes

🚨 Piège exam :

• Overlap CIDR entre VNet hub et on-prem → peering / VPN ne route pas, pas de message d'erreur clair → toujours planifier plan d'adressage IPAM dès le départ
• GatewaySubnet en /29 → marche en VPN basique mais bloque les upgrades (zone-redundant gateway, ExpressRoute coexistence)
• NSG attaché à GatewaySubnet → contrôle plane MS bloqué → gateway en état dégradé

⚠️ Distractors :

• "Renommer le subnet en GW-Subnet pour clarté" = ❌ casse la gateway
• "/28 suffit pour ExpressRoute" = ❌ MS recommande /27 min, /26 pour features avancées

J. Continuous Access Evaluation (CAE)

Feature Entra ID essentielle Zero Trust / compliance. Notion AZ-305 territory (Identity Governance + sécurité). Sans CAE, un token JWT compromis reste valide jusqu'à expiration (typiquement 1h) = fenêtre de risque même après révocation admin.

Principe

• Sans CAE : token JWT émis valide jusqu'à expiration (~1h). Admin désactive user → user garde accès 1h via son token actif.
• Avec CAE : Entra notifie les apps compatibles en quasi-temps-réel quand un critical event se produit → l'app révoque la session immédiatement.

Critical events qui déclenchent CAE

• User disabled / deleted
• Password reset / changed
• MFA challenge raté (anomalie)
• IP change suspecte (location anomaly, hors named locations)
• Token revocation (admin force Revoke-AzureADUserAllRefreshToken)
• Risk level user/sign-in change (avec Identity Protection P2)

Apps compatibles CAE

• Activé par défaut depuis 2022 pour les services MS first-party
• Configurable via Conditional Access policy (Session control → Customize CAE) — peut être strict mode ou disabled

Use case AZ-305

• Compliance (ISO 27001, SOC 2, RGPD) qui exige "révocation accès <X min après off-boarding"
• Zero Trust : invalider session sur changement de contexte (location, device, risk)
• Question type exam : "User désactivé, comment garantir accès révoqué immédiatement ?" → CAE + Conditional Access (pas juste "disable user", car token reste valide)

🚨 Piège exam :

• "Disable user dans Entra suffit pour révoquer accès" = ❌ faux, token JWT valide jusqu'à expiration sans CAE
• "CAE marche pour toutes les apps" = ❌ apps custom doivent l'implémenter via MSAL
• "CAE = remplace Conditional Access" = ❌ CAE est une feature CA (Session control), pas une alternative

K. Azure Arc-enabled Kubernetes

Distinct d'AKS et d'Arc-enabled servers. Notion AZ-305 (gouvernance multi-cloud / hybrid). Permet de gouverner depuis Azure des clusters K8s hors Azure.

Principe

• Projette le control plane Azure (Policy, Defender, Monitor, GitOps, RBAC Entra) sur des clusters K8s hors Azure :
  • On-prem (vSphere, bare metal, OpenShift)
  • Autres clouds (EKS, GKE)
  • Edge (Raspberry Pi clusters, retail stores, factories)
• Pas une migration : le cluster reste là où il est, Azure le gouverne à distance via un agent (outbound HTTPS 443 vers Azure Arc service)

Features activables une fois connecté

Use case AZ-305

• Flotte multi-cloud K8s (EKS prod + AKS dev + on-prem legacy) gouvernance unifiée Azure
• Edge K8s : 200 magasins retail × 1 K3s cluster → 1 single pane Azure pour Policy + Monitoring
• Compliance multi-region : enforcer mêmes policies (PCI-DSS, HIPAA) sur clusters distribués

Distinctions à retenir ⭐

🚨 Piège exam :

• "Migrer EKS vers AKS pour utiliser Azure Policy" = ❌ overkill — Arc-enabled K8s permet d'appliquer Policy sur EKS sans migration
• "Arc K8s = Azure manage le control plane" = ❌ faux, Azure gouverne mais le control plane reste géré par toi (ou EKS/GKE/etc.)
• "Nécessite VPN ou ExpressRoute" = ❌ outbound HTTPS 443 suffit

⚠️ Distractors :

• AKS Hybrid (anciennement AKS-HCI) = différent, c'est AKS sur Azure Stack HCI (on-prem MS-managed)
• Arc-enabled Servers = pour VMs, pas pour K8s clusters

L. Multi-tenant Entra — assignments par tenant

Précision design AZ-305 (Identity Governance multi-org).

• Si un user travaille avec N tenants Entra distincts (orgs différentes, ESN consulting, M&A), chaque tenant = ses propres rôles, ses propres assignments
• Minimum 1 role assignment par tenant où l'accès est requis — pas de cross-tenant role inheritance native
• Pour partager des resources cross-tenant : B2B guest invitation + role assignment explicite dans tenant cible, ou Cross-tenant Sync (Entra ID Governance) pour syncer users entre tenants

🚨 Piège exam : "User a Network Contributor sur tenant A, doit avoir accès tenant B" → ❌ rôle pas hérité, re-assigner explicitement dans tenant B (après B2B invite si user externe au tenant B)

⚠️ Distractor : "Global Admin tenant A = accès tenant B" = ❌ rôles scopés à leur tenant (sauf Lighthouse pour MSP/CSP, scénario différent)

M. Storage Account design (Blob types, Tiers, Lifecycle, Immutable, Replication)

Objectif AZ-305 "Design data storage solutions for non-relational data". Vu AZ-104 territory, ressort en design AZ-305 pour les choix tiers + redondance + immuabilité (compliance).

M.1 Blob types — 3 types, choix au moment de l'upload (irréversible)

🚨 Piège exam : "Choisir le bon type pour logs streaming append-only" → Append blob. Pour stockage générique → Block blob. Page blob = legacy VHD/disque VM custom.

M.2 Access tiers — Hot / Cool / Cold / Archive ⭐

Tier = coût stockage vs coût d'accès. Plus c'est froid, moins ça coûte au GB, mais plus c'est cher pour lire/écrire et plus c'est lent.

Règles clés :

• Set au niveau Storage Account (default tier) + override au niveau blob possible

• Archive = offline : pour lire → rehydrate vers Hot ou Cool (peut prendre plusieurs heures, ou 1h en priority rehydrate )

• Early deletion fee : supprimer un blob avant min retention = pénalité (ex: blob Cool supprimé à J+10 = facturé 30j)

• Cold tier (sorti GA fin 2023) = sweet spot entre Cool et Archive (accès online ms mais moins cher que Cool)

🚨 Piège exam : "Archive a 180j min retention" — supprimer ou changer de tier avant = early deletion fee. Pour pattern "vieux logs accessibles rarement mais en ligne" → Cold (pas Archive ∵ rehydrate lent).

M.3 Lifecycle Management — automatiser les transitions

Policy JSON sur le Storage Account : règles If blob not modified for X days → move to tier Y / delete.

Actions possibles :

• tierToCool, tierToCold, tierToArchive
• delete (suppression auto)
• enableAutoTierToHotFromCool (auto-rehydrate si accès)

Filters : par container, prefix path, blob index tags.

Use case design : "logs après 30j → Cool, après 90j → Archive, après 7 ans → delete" = 1 policy lifecycle ⇒ pas de scripts custom.

🚨 Piège exam : Lifecycle agit sur Last modified ou Last accessed time tracking (à activer explicitement). Sans tracking activé → lifecycle utilise Last modified (≠ pattern d'accès réel).

M.4 Immutable Blob Storage — WORM (Write Once Read Many)

Compliance critique : SEC 17a-4, FINRA, CFTC, HIPAA, RGPD legal hold. Empêche modification/suppression de données pour durée fixée.

Scope : container-level ou version-level (immutable storage with versioning enabled).

Use case : "données médicales conservées 10 ans non-modifiables" → time-based retention locked, 10 ans. Litige en cours → legal hold en + jusqu'à clôture.

🚨 Piège exam :

• "Modifier la durée d'une time-based locked policy" = ❌ irréversible, peut augmenter mais jamais réduire
• "Delete container avec immutable policy active" = ❌ refusé tant que policy non-expirée + container vide
• "Legal hold = compliance officielle" = ✅ mais pas de durée, jusqu'à retrait explicite (compliant SEC/FINRA)

M.5 Object Replication — async blob copy cross-account

Réplication asynchrone unidirectionnelle de blobs entre 2 Storage Accounts (même région ou cross-region, même tenant ou cross-tenant).

Composants :

• Source account + Destination account (versioning et change feed activés sur source)
• Replication policy : rules (container source → container dest, optional prefix filter, optional copy historical data)

Use case :

• Source EU dataset → réplication vers compte US analytics
• Backup secondaire dans un autre tenant pour DR cross-tenant
• Read-only replica pour offload de lecture

🚨 Piège exam :

• Object Replication ≠ GRS : GRS = redondance interne MS au niveau Storage Account ; Object Replication = blob-level vers autre account
• Async only : pas de garantie RPO=0
• Block blobs uniquement (pas append/page)

M.6 Redundancy — LRS / ZRS / GRS / RA-GRS / GZRS / RA-GZRS ⭐

Règles design :

• HA zonale dans 1 région = ZRS (3 zones, pas de DR cross-région)
• HA zonale + DR cross-région = GZRS (ZRS primary + LRS DR)
• Lecture du secondaire (analytics offload, DR drill) = RA-GRS / RA-GZRS
• Storage Account Failover : commande explicite ou Microsoft-initiated. RA permet de lire avant failover.

🚨 Piège exam :

• "DR cross-région le moins cher" = GRS (pas GZRS qui inclut ZRS primary, plus cher)
• "HA zone-redundant" = ZRS ou GZRS (LRS et GRS = single datacenter primary)
• "Lire le secondaire sans failover" = RA-GRS ou RA-GZRS (GRS/GZRS seuls = secondaire inaccessible sauf en failover)
• GZRS dispo sur sous-ensemble régions uniquement (vérifier mapping région)

M.7 Decision tree Storage Account design

Type de données ?
├─ Logs/audit append-only → Append blob
├─ VHD VM unmanaged → Page blob
└─ Reste (99%) → Block blob

Pattern d'accès ?
├─ Fréquent (apps actives) → Hot
├─ Peu fréquent (backups <30j) → Cool
├─ Rare (archives chaudes >90j online) → Cold
└─ Très rare + offline OK + compliance → Archive

Compliance immuabilité ?
├─ Période fixe (SEC, médical 10 ans) → Time-based retention LOCKED
└─ Litige en cours → Legal hold

DR ?
├─ Single zone → LRS (testing) - PAS pour prod HA
├─ HA zonale, 1 région → ZRS
├─ DR cross-région + le moins cher → GRS
├─ HA zonale + DR cross-région → GZRS
└─ + Lire secondaire sans failover → RA-* variants

N. Automated deployment (CI/CD + IaC)

Objectif AZ-305 "Design a solution for automated deployment". Pas du AZ-400 deep (pipelines DevOps), juste le choix d'outils + patterns IaC + stratégies de déploiement.

N.1 Azure DevOps vs GitHub Actions — quel outil pour quel contexte

🚨 Piège exam :

• "Pipeline CI/CD avec auth la plus sûre vers Azure" = Workload Identity Federation (OIDC) = pas de secret stocké, federated trust via Entra. ❌ ne pas stocker un Service Principal secret dans pipeline.
• "Azure DevOps obligatoire pour déployer Azure" = ❌ faux, GitHub Actions le fait aussi très bien.

N.2 IaC — Bicep / ARM / Terraform — choix

🚨 Piège exam :

• "Multi-cloud (Azure + AWS) IaC unifié" = Terraform
• "Azure-only nouveau projet 2026" = Bicep (ARM legacy)
• "Convertir ARM existant vers Bicep" = bicep decompile

N.3 Stratégies de déploiement — Blue-Green / Canary / Rolling

N.4 Deployment Stacks (successeur de Azure Blueprints)

Deployment Stacks = ressource managée groupant des déploiements (RG / sub / MG). Permet denyAssignments (lock at deploy) + manage lifecycle (delete stack → optionnel cleanup ressources). Remplace Blueprints (deprecated 11 juil 2026).

Use case : déployer un "landing zone block" cohérent (RG + VNet + Storage + Key Vault) avec lock anti-suppression + cleanup auto si block retiré.

🚨 Piège exam : "Remplacer Azure Blueprints pour landing zone factory" → Deployment Stacks + Template Specs (versioning des templates) + Azure Policy (gouvernance).

N.5 Pièges design CI/CD

• Stocker un Service Principal secret dans GitHub Secrets / Azure DevOps Library → ❌ utiliser Workload Identity Federation (OIDC) = pas de secret, federated trust
• Pipeline avec rôle Contributor sur subscription entière → ❌ over-privileged ; scoper au RG cible, principe moindre privilège
• Pas de approval gate sur deploy prod → risque push direct prod ; ajouter environment protection rules (GitHub) ou approvals & checks (Azure DevOps)
• IaC sans state remote / state non-locké → conflits déploiements // ; Terraform = remote backend Azure Storage + state lock via blob lease

O. Microsoft Sentinel — SIEM/SOAR awareness AZ-305

Objectif AZ-305 "Design a logging and monitoring solution" + sécurité globale. Sentinel = SIEM/SOAR cloud-native sur Log Analytics Workspace. Pas du AZ-500 deep, juste positionnement design.

O.1 Qu'est-ce que Sentinel

• SIEM (Security Information & Event Management) : collecte logs sécurité (signaux multi-sources), corrèle, détecte menaces
• SOAR (Security Orchestration, Automation & Response) : automatise réponses via playbooks (Logic Apps)
• Bâti sur Log Analytics Workspace (LAW) → mêmes mécanismes (tables, KQL, retention, archive)
• Activé par-LAW via menu Sentinel → ajoute des features (workbooks, hunting queries, analytics rules, incidents)

O.2 Composants clés

O.3 Pricing — 2 modèles

• Pay-as-you-go : par GB ingéré dans Sentinel (en plus du coût LAW underneath)
• Commitment tier : 100 GB/jour à 5 TB/jour fixe = remise vs PAYG

🚨 Piège design : facturé 2x sur les données SecurityEvent / SigninLogs / etc. : 1× par LAW (ingestion) + 1× par Sentinel (analytics). Optimiser : basic logs / archive tier pour logs verbeux + transformations DCR pour drop avant ingestion.

O.4 Use case design AZ-305

• Compliance ISO 27001, SOC 2, PCI-DSS exigeant SIEM centralisé → Sentinel agrège Entra + Azure + M365 + on-prem (via AMA / syslog forwarder)
• MSSP / multi-tenant : Sentinel Lighthouse-enabled pour gérer plusieurs clients depuis 1 SOC console
• Réponse auto sur incident haute sévérité → Playbook isolation device + notification Teams + création ticket Jira

🚨 Piège exam :

• "Activer Sentinel sur 1 LAW dédié sécurité" = ✅ best practice (isolation logs sécu + retention/archive tuning indépendant)
• "Sentinel remplace Defender for Cloud" = ❌ complémentaires : Defender = CSPM/CWPP (postures + workload protection), Sentinel = SIEM/SOAR (corrélation + réponse)
• "Sentinel ingère uniquement logs Azure" = ❌ multi-cloud (AWS, GCP) + on-prem + SaaS via connectors

P. Azure Arc-enabled Servers

Cousin de K (Arc-enabled K8s) mais pour VMs / serveurs physiques hors Azure. Couvre objectif AZ-305 "Design for hybrid and multicloud workloads".

P.1 Principe

• Installe l'agent Azure Connected Machine sur une VM/serveur hors Azure (on-prem, AWS EC2, GCP Compute Engine)
• La machine devient une ressource Microsoft.HybridCompute/machines dans Azure Resource Manager
• Outbound HTTPS 443 vers Azure Arc service uniquement (pas d'inbound, pas de VPN requis)
• Une fois connectée → traitée comme une Azure VM côté gouvernance (mais reste là où elle est physiquement)

P.2 Features activables une fois connecté

P.3 Distinction Arc-enabled — récap ⭐

P.4 Use case design AZ-305

• Datacenter hybride : 200 VMs on-prem + 150 VMs Azure → 1 single pane de gouvernance (Policy, Defender, Monitor, Update Manager) sans migrer
• Multi-cloud lift-and-shift partiel : VMs AWS EC2 critiques restent là, mais gouvernées depuis Azure (compliance unifiée)
• Edge servers : magasins / usines avec serveurs locaux → Arc agent → patching auto + monitoring centralisé
• SQL Server inventory + LTR Backup vers Azure : Arc-enabled SQL Server → backup auto vers Azure Storage (rétention 10 ans)

🚨 Piège exam :

• "Migrer vers Azure VM pour utiliser Azure Policy / Defender" = ❌ overkill ; Arc-enabled Server permet gouvernance sans migration
• "Arc-enabled Server = Azure managé la VM" = ❌ la VM reste managée par toi côté OS/hardware ; Azure gouverne via agent
• "Nécessite VPN / ExpressRoute" = ❌ outbound HTTPS 443 suffit
• "Azure VM Extensions disponibles" = ✅ la plupart marchent identiquement (AMA, DSC, Custom Script, Defender, etc.)

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix architectural (uniquement les services traités dans la fiche) → trade-offs → pièges typiques.

Scenario 1 : Banque retail — délégation Helpdesk multi-pays avec gouvernance forte

Contexte business : Banque retail européenne, 12 000 employés répartis sur 8 pays. La DSI veut déléguer le reset password / unlock account aux Helpdesks locaux (≈15 personnes par pays), sans donner Global Admin. Audit interne exige : aucun owner local ne doit pouvoir s'auto-ajouter au groupe Helpdesk pour escalader, traçabilité des modifications, MFA renforcée pour les opérations. Choix architectural : Role-assignable Groups (1 par pays : HelpdeskTeam-FR, HelpdeskTeam-DE, ...) + PIM pour activation just-in-time du rôle Helpdesk Admin sur le groupe. Entra ID P2 requis pour la combinaison. Architecture / pattern :

• 8 groupes role-assignable créés à la création avec option cochée (irréversible)
• Rôle Helpdesk Administrator assigné au groupe, pas aux users individuellement
• PIM eligibility sur le groupe → activation 4h avec MFA + justification + approbation manager
• Audit log Entra streamé vers Log Analytics + Sentinel pour alerting Trade-offs assumés :
• Gain : protection anti-escalade (Group Owner local ne peut PAS modifier le groupe — seul un Privileged Role Admin peut), traçabilité totale
• Perte : impossible de transformer un groupe existant en role-assignable → migration = recréation + ré-import membres. Coût Entra ID P2 par user concerné. Pièges à éviter :
• Créer le groupe sans cocher l'option à la création → groupe inutilisable pour rôles, faut recréer
• Configurer le groupe en Dynamic membership → ❌ refusé (Assigned only sur role-assignable)
• Oublier que les Group Owners "standards" ne peuvent plus modifier le groupe : si l'unique Privileged Role Admin part de la boîte sans backup → groupe orphelin

Scenario 2 : Industrie pharma — publier SharePoint 2019 on-prem aux commerciaux en déplacement

Contexte business : Laboratoire pharma, 3 000 commerciaux terrain qui ont besoin d'accéder au portail SharePoint 2019 on-prem (catalogues produits, fiches scientifiques). Pas de VPN sur les tablettes/laptops perso (BYOD partiel). DSI refuse d'ouvrir un port inbound sur le firewall, et compliance interne exige MFA + device compliant pour tout accès données R&D. Choix architectural : App Proxy avec Kerberos Constrained Delegation (KCD) + Conditional Access. SharePoint reste on-prem, exposé sans VPN ni reverse proxy DMZ classique. Architecture / pattern :

• 4 App Proxy Connectors installés on-prem (2 sites, 2 par site = HA) → Connector Group dédié SharePoint
• Compte de service AD + délégation Kerberos configurée → connector demande tickets au nom du user Entra connecté
• Pre-authentication Entra ID → MFA obligatoire + Conditional Access policy "device compliant + location non-tor"
• Custom domain sharepoint.contoso-pharma.com + cert wildcard Trade-offs assumés :
• Gain : zéro port inbound ouvert, MFA appliquée à une app legacy qui ne sait pas faire OIDC, SSO transparent pour le user
• Perte : KCD config un peu complexe (SPNs, délégation AD, comptes service) → courbe d'apprentissage admins IAM. Latence légèrement plus élevée qu'en LAN. Pièges à éviter :
• Connector Group avec 1 seul connector → SPOF (toujours ≥2 par group)
• Oublier de configurer le SPN côté AD → ticket Kerberos invalide, erreur 401 sans message clair
• Mettre les connectors dans un subnet sans accès outbound 443 vers Azure → connectors restent en Inactive

Scenario 3 : ESN consulting — onboarding partenaires externes self-service avec gouvernance

Contexte business : Cabinet de conseil (5 000 consultants internes) qui travaille avec ~200 partenaires externes (sous-traitants, freelances, autres cabinets) sur projets ponctuels. Aujourd'hui : helpdesk crée chaque guest manuellement = 2-3 jours, friction massive. Direction veut "amener un partenaire à bord en <1h, avec accès uniquement aux ressources projet, et déprovisionnement auto à la fin". Choix architectural : Entitlement Management (Entra ID P2) + Access Packages par projet + Connected Organizations pour les cabinets partenaires réguliers. Architecture / pattern :

• 1 Catalog par practice métier (Strategy, Tech, Audit) → ressources : groupes Teams projet, SharePoint sites, apps SaaS via SCIM
• Access Package "Projet-XYZ-External" : durée 90j, approval = Project Manager, MFA-required policy
• Connected Organizations pour cabinets récurrents → leurs users peuvent demander directement sans invitation manuelle
• Access reviews trimestrielles auto → managers valident encore-nécessaire ou révocation Trade-offs assumés :
• Gain : onboarding partenaire passe de 2j à <1h, déprovisionnement auto (plus de comptes guests fantômes), audit-ready pour ISO 27001
• Perte : Entra ID P2 par user (cher à l'échelle), setup initial des catalogs et policies = projet de 2-3 mois Pièges à éviter :
• Mettre des ressources sensibles (groupes admin, SharePoint finance) dans un catalog accessible aux external users
• Oublier d'activer Access reviews → guests accumulent → bombe à retardement RGPD/sécu
• Configurer expiration à "Never" sur l'access package external → contradiction de l'objectif lifecycle

Scenario 4 : E-commerce SaaS — scaling outbound vers APIs partenaires

Contexte business : Plateforme e-commerce SaaS multi-tenants, ~80 boutiques en marque blanche hébergées sur des VMs Azure. Chaque commande déclenche 6-8 appels HTTPS vers APIs externes (Stripe, transporteurs, anti-fraude, ERP partenaires). En pic Black Friday : ~2 000 commandes/min × 8 appels = 16k connexions outbound simultanées. Symptôme observé : erreurs intermittentes connection timeout vers Stripe → enquête révèle SNAT port exhaustion sur le Standard LB outbound. Choix architectural : NAT Gateway avec Public IP Prefix /28 (16 IPs) attaché aux subnets des VMs → ~1M ports SNAT dispo. Remplace le default outbound LB pour le trafic sortant. Architecture / pattern :

• 1 NAT Gateway par zone de disponibilité (zonal) → 3 NAT GW pour HA cross-zone
• Public IP Prefix /28 partagé entre les 3 NAT GW (ou Prefix par NAT GW selon volume)
• Subnets web/app pointent vers NAT GW pour outbound; Public LB Standard reste pour inbound (combo classique)
• Combiner avec ASG sur les NICs : règles NSG ASG-web → ASG-app port 8080 indépendantes des CIDR Trade-offs assumés :
• Gain : résout SNAT exhaustion (de 1 000 ports/IP en LB → 64k ports/IP × 16 IPs en NAT GW), facturation prédictible ($45/mois par NAT GW + data processed)
• Perte : NAT GW = zonal (pas zone-redundant nativement) → architecture HA = 1 NAT GW par zone = 3× le coût fixe. Outbound only (inbound nécessite un LB ou App GW à côté). Pièges à éviter :
• Croire que NAT GW peut faire inbound → ❌, toujours coupler avec un LB/App GW/Front Door pour les ingress
• Déployer 1 seul NAT GW pour 3 zones → SPOF zonal, panne zone = panne outbound complète
• Oublier que Public IP existante sur la VM "court-circuite" NAT GW → trafic outbound peut sortir par la PIP de la VM au lieu de NAT GW = IPs source non-prédictibles côté Stripe

Scenario 5 : Cabinet d'audit — apps internes accessibles SANS exposer sur Internet

Contexte business : Cabinet d'audit (compliance hyper-stricte, données clients sensibles). 14 apps internes legacy on-prem (vieux ERP, GED, app .NET custom). Direction : "nos auditeurs en mission doivent y accéder depuis n'importe où, mais ZÉRO de ces apps ne doit apparaître sur Internet, ZÉRO VPN client à installer sur les laptops". MFA obligatoire pour conformité ISAE 3402. Choix architectural : App Proxy pour les apps web on-prem (OIDC/SAML/Header/Kerberos selon l'app) + Conditional Access strict + Entitlement Management pour gérer qui a droit à quoi. Architecture / pattern :

• 6 Connector Groups (par criticité d'app) → 3 connectors par group sur 3 VMs séparées
• Apps modernes : OIDC. Apps legacy .NET : Header-based avec mapping claims. ERP : KCD vers AD on-prem.
• Conditional Access : MFA + device compliant + sign-in risk low + named location (filtre IPs cabinet + IPs partenaires whitelisted)
• Access Packages par mission d'audit → auditeur demande, manager mission approuve, expiration auto fin de mission Trade-offs assumés :
• Gain : aucune surface d'attaque Internet sur les apps, MFA appliquée à des apps qui ne savent pas faire OAuth, lifecycle access automatisé
• Perte : licences Entra ID P1 (Conditional Access) + P2 (Entitlement Mgmt) sur tous les users → coût significatif. Latence supplémentaire (~50-150ms) vs accès direct. Pièges à éviter :
• Publier une app avec Passthrough (pas de pre-auth Entra) "pour aller plus vite" → tu perds CA et le filtre MFA = trou de sécu
• Oublier que App Proxy a une limite de ~500 MB par requête → apps qui transfèrent gros fichiers (GED) nécessitent une alternative (Files share via Private Link + VPN)
• Ne pas dimensionner les connectors → en pic mission de fin d'exercice, latence explose → toujours sur-dimensionner et monitorer CPU connectors