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

Notions qui ne 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 sur 8 pays. La DSI veut confier le reset password / déblocage de compte aux Helpdesks locaux (~15 personnes/pays), sans leur donner Global Admin. L'audit exige : aucun owner local ne doit pouvoir s'ajouter lui-même au groupe Helpdesk, traçabilité totale, et MFA renforcée sur les opérations. Choix architectural : des groupes role-assignable (1 par pays : HelpdeskTeam-FR, etc.) sur lesquels on pose le rôle Helpdesk Admin, activé en just-in-time via PIM. Nécessite Entra ID P2. Architecture / pattern :

• 8 groupes role-assignable, option cochée dès la création (irréversible).
• Rôle Helpdesk Administrator posé sur le groupe, pas sur chaque user.
• PIM : droit éligible sur le groupe → activation 4h avec MFA + justification + validation manager.
• Logs d'audit Entra envoyés vers Log Analytics + Sentinel pour les alertes. Trade-offs assumés :
• Gain : anti-escalade (un owner local ne peut PAS modifier le groupe — seul un Privileged Role Admin le peut), traçabilité complète.
• Perte : on ne peut pas convertir un groupe existant en role-assignable → il faut le recréer et réimporter les membres. Coût Entra ID P2 par user. Pièges à éviter :
• Oublier de cocher l'option à la création → groupe inutilisable pour les rôles, à recréer.
• Mettre le groupe en appartenance dynamique → ❌ interdit (role-assignable = membres assignés à la main).
• Les owners « standards » ne peuvent plus toucher au groupe : si l'unique Privileged Role Admin quitte la boîte sans remplaçant → groupe orphelin. 📐 Réf. CAF/WAF — Enterprise access model (control plane / least-privilege JIT) : le modèle d'accès d'entreprise impose RBAC à privilège minimal + PIM (JIT) pour le plan de contrôle identité, exactement ce que réalisent role-assignable groups + activation just-in-time. Lien

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

Contexte business : labo pharma, 3 000 commerciaux terrain qui doivent atteindre le portail SharePoint 2019 on-prem (catalogues, fiches). Pas de VPN sur les appareils perso (BYOD). La DSI refuse d'ouvrir un port entrant sur le firewall, et la compliance impose MFA + appareil conforme pour les données R&D. Choix architectural : App Proxy avec délégation Kerberos (KCD) + Conditional Access. SharePoint reste on-prem, publié sans VPN ni reverse proxy en DMZ. Architecture / pattern :

• 4 connecteurs App Proxy on-prem (2 sites × 2 = HA) → Connector Group dédié SharePoint.
• Compte de service AD + délégation Kerberos → le connecteur demande les tickets au nom du user Entra connecté.
• Pré-authentification Entra → MFA obligatoire + Conditional Access « appareil conforme + localisation non-Tor ».
• Domaine perso sharepoint.contoso-pharma.com + certificat wildcard. Trade-offs assumés :
• Gain : aucun port entrant ouvert, MFA appliquée à une vieille app qui ne sait pas faire OIDC, SSO transparent pour l'utilisateur.
• Perte : la config KCD est délicate (SPNs, délégation AD, comptes de service) → apprentissage pour les admins IAM. Latence un peu plus élevée qu'en LAN. Pièges à éviter :
• Un Connector Group avec 1 seul connecteur → point unique de panne (toujours ≥2 par groupe).
• Oublier le SPN côté AD → ticket Kerberos invalide, erreur 401 peu explicite.
• Mettre les connecteurs dans un subnet sans sortie 443 vers Azure → ils restent Inactive. 📐 Réf. CAF/WAF — Zero Trust « Verify explicitly » / secure remote access : publier une app web on-prem via App Proxy (sans port inbound, avec pre-auth Entra + MFA + Conditional Access) applique le principe Zero Trust de validation explicite de chaque accès. Lien

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

Contexte business : cabinet de conseil (5 000 consultants) qui collabore avec ~200 partenaires externes (sous-traitants, freelances) sur des projets ponctuels. Aujourd'hui, le helpdesk crée chaque invité à la main = 2-3 jours de friction. La direction veut : « partenaire opérationnel en < 1h, accès limité au projet, et coupure automatique à la fin ». Choix architectural : Entitlement Management (Entra ID P2) — un libre-service d'accès — avec un Access Package par projet, et des Connected Organizations pour les cabinets partenaires réguliers. Architecture / pattern :

• 1 Catalog par métier (Strategy, Tech, Audit) → ressources : groupes Teams, sites SharePoint, apps SaaS via SCIM.
• Access Package « Projet-XYZ-External » : durée 90j, validation par le Project Manager, MFA exigée.
• Connected Organizations pour les cabinets récurrents → leurs users demandent l'accès directement, sans invitation manuelle.
• Access reviews trimestrielles → les managers confirment ou révoquent. Trade-offs assumés :
• Gain : onboarding qui passe de 2j à < 1h, coupure auto (plus de comptes invités fantômes), prêt pour l'audit ISO 27001.
• Perte : Entra ID P2 par user (cher à grande échelle), mise en place des catalogs/policies = projet de 2-3 mois. Pièges à éviter :
• Mettre des ressources sensibles (groupes admin, SharePoint finance) dans un catalog ouvert aux externes.
• Oublier les Access reviews → les invités s'accumulent → bombe à retardement RGPD/sécu.
• Mettre l'expiration sur « Never » pour un access package externe → contredit l'objectif de coupure auto. 📐 Réf. CAF/WAF — Identity governance (entitlement management, accès externes) : access packages + connected organizations + access reviews gouvernent le cycle de vie des identités externes (self-service, approbation, déprovisionnement auto), pilier de l'Identity Governance. Lien

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

Contexte business : e-commerce SaaS multi-tenants, ~80 boutiques en marque blanche sur VMs Azure. Chaque commande déclenche 6-8 appels HTTPS vers des APIs externes (Stripe, transporteurs, anti-fraude, ERP). Au pic Black Friday : ~2 000 commandes/min × 8 = 16k connexions sortantes en même temps. Symptôme : connection timeout intermittents vers Stripe → cause = SNAT port exhaustion (à court de ports sortants) sur le Standard LB. Choix architectural : NAT Gateway avec un Public IP Prefix /28 (16 IPs) sur les subnets des VMs → ~1M ports sortants dispo. Il remplace le LB par défaut pour le trafic sortant. Architecture / pattern :

• 1 NAT Gateway par zone (zonal) → 3 NAT GW pour la HA sur les 3 zones.
• Public IP Prefix /28 partagé entre les 3 NAT GW (ou 1 prefix par NAT GW selon le volume).
• Les subnets web/app sortent par le NAT GW ; le Public LB Standard reste pour l'entrant (combo classique).
• Avec des ASG sur les NICs : règles NSG ASG-web → ASG-app port 8080, indépendantes des plages d'IP. Trade-offs assumés :
• Gain : règle le SNAT exhaustion (de 1 000 ports/IP en LB → 64k ports/IP × 16 IPs en NAT GW), facturation prévisible ($45/mois par NAT GW + data traitée).
• Perte : le NAT GW est zonal (pas zone-redundant nativement) → la HA impose 1 NAT GW par zone = 3× le coût fixe. Sortant uniquement (l'entrant exige un LB/App GW à côté). Pièges à éviter :
• Croire que le NAT GW gère l'entrant → ❌, toujours le coupler à un LB/App GW/Front Door pour l'ingress.
• 1 seul NAT GW pour 3 zones → point de panne zonal : une panne de zone coupe tout le sortant.
• Une IP publique posée sur la VM court-circuite le NAT GW → le trafic peut sortir par l'IP de la VM = IPs source imprévisibles côté Stripe. 📐 Réf. CAF/WAF — Network topology & connectivity (outbound SNAT) : NAT Gateway est la méthode recommandée pour la connectivité sortante car elle scale jusqu'à >1M ports SNAT (64 512/IP) et prend précédence sur le LB, éliminant le SNAT port exhaustion. Lien

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

Contexte business : cabinet d'audit (compliance stricte, données clients sensibles), 14 apps internes legacy on-prem (vieux ERP, GED, app .NET maison). Direction : « nos auditeurs en mission y accèdent de partout, mais AUCUNE app ne doit apparaître sur Internet et AUCUN VPN client sur les laptops ». MFA obligatoire (norme 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 connecteurs par groupe sur 3 VMs séparées.
• Apps modernes : OIDC. Apps legacy .NET : Header-based (mapping des claims). ERP : Kerberos (KCD) vers l'AD on-prem.
• Conditional Access : MFA + appareil conforme + risque de connexion faible + localisation déclarée (IPs du cabinet + IPs partenaires autorisées).
• Access Packages par mission → l'auditeur demande, le manager de mission approuve, expiration auto en fin de mission. Trade-offs assumés :
• Gain : aucune surface d'attaque sur Internet, MFA appliquée à des apps qui ne savent pas faire OAuth, cycle de vie des accès automatisé.
• Perte : licences Entra ID P1 (Conditional Access) + P2 (Entitlement Mgmt) pour tous → coût notable. Latence en plus (~50-150ms) vs accès direct. Pièges à éviter :
• Publier en Passthrough (sans pré-auth Entra) « pour aller plus vite » → on perd CA et MFA = trou de sécu.
• Oublier qu'App Proxy plafonne à ~500 MB par requête → les apps qui transfèrent de gros fichiers (GED) exigent une alternative (partage de fichiers via Private Link + VPN).
• Sous-dimensionner les connecteurs → au pic de fin d'exercice la latence explose → toujours sur-dimensionner et surveiller leur CPU. 📐 Réf. CAF/WAF — Zero Trust apps / accès distant sécurisé sans VPN : App Proxy avec pre-authentication Entra rend les apps internes invisibles depuis Internet (zéro surface inbound) tout en appliquant Conditional Access, conforme à l'architecture Zero Trust des applications. Lien