WIKI Retour au Portfolio

Dernière mise à jour : 12 juin 2026

AZ104, A retenir:

ENTRA-ID Free: MFA basic via Authenticator (Security Defaults all-or-nothing) P1: Dynamic Groups + AU + SSPR writeback + Conditional Access + Group-based licensing + Entra custom roles + App Proxy + MFA granulaire (via CA) P2: Identity Protection (sign-in/user risk) + PIM + Access Reviews + Access Packages Custom domain tenant: TXT (ou MX) record chez registrar pour vérifier Auth hybrid methods: PHS (hash dans cloud, marche si AD onprem DOWN) / PTA (verif live onprem, agent) / Federation ADFS (legacy) / Seamless SSO (combinable avec PHS ou PTA) CloudSync vs ConnectSync: CloudSync = PHS only, pas de writeback device/exchange, pas de PTA, pas de Federation, agent léger sans SQL / ConnectSync = full features mais lourd Security Group: user / device / group / SP (utilisable RBAC) M365 Group: USERS only, collaboratif (Teams/SharePoint/mail), expiration policy possible - membership PAS de licence M365 requise (juste être user Entra) - licence M365 requise uniquement pour USER les apps (Exchange/SharePoint/Teams individuel) Custom Security Attributes (P1+): clé-valeur custom sur USERS / GROUPS / SP (PAS devices, PAS resources Azure) - usage ABAC conditions RBAC + filtres + audit - rôles dédiés Attribute Definition Admin (crée schéma) / Attribute Assignment Admin (assigne valeurs) / Attribute Reader - GLOBAL ADMIN PAS D'ACCÈS PAR DÉFAUT, doit s'auto-assigner un de ces rôles Dynamic Group (P1): pas de membre manuel + pas de mix user/device (1 type/groupe) Device Entra Registered: BYOD/perso (settings > accounts > access work or school) Device Entra Joined: cloud-only, login via Entra Device Hybrid Joined: AD onprem + Entra via Connect Sync ("Configure hybrid Azure AD join") Entra > Devices > Device settings: qui peut joindre, max devices/user, MFA pour join AU (Administrative Units): scope user/group/device (menu Roles & admins) Licences: attribuer à user ou groupe (group-based = P1), requiert UsageLocation Custom roles: Azure RBAC gratuit (New-AzRoleDefinition / az role definition create) / Entra ID custom roles = P1 (New-MgRoleDefinition via MS Graph) Owner (RBAC Azure) ≠ Global Admin (Entra) - 2 annuaires différents / toggle "Access management for Azure resources" sur Global Admin = devient User Access Admin au scope root / Tags & Locks: sub / RG / resource (CanNotDelete ou ReadOnly) Rôles Entra clés: Global Admin (full) / User Admin (gère users+pwd+groups) / Helpdesk Admin (reset pwd users NON admin) / Privileged Role Admin (assigne rôles Entra) / Authentication Admin (gère MFA) / Cloud Device Admin (enable/delete devices, pas groups) Hybrid user: attributs synced AD = READ-ONLY côté Entra (Department, JobTitle, etc.) - modifiables CLOUD-only = UsageLocation + licences + rôles Entra + méthodes MFA + group membership cloud-only + CA exclusions (tout ce qui n'existe QUE dans Entra) MIM: solution hybride entreprise (cert mgmt, SSPR multi-sys) - rare AZ-104 Entra Domain Services (ex-Azure AD DS): AD DS MANAGÉ par MS dans Azure pour apps legacy Kerberos/LDAP/NTLM, sync ONE-WAY Entra → Entra DS, vit dans VNet dédié B2B Collab: invite guests externes par mail (IdP enregistré possible: Google etc), apparaît en guest dans tenant B2B Direct Connect: trust tenant-to-tenant (Teams shared channels UNIQUEMENT) External ID (ex-B2C): tenant SÉPARÉ pour customers (apps custom) B2B Collab setup: Guest invite settings ON + (option) enregistrer IdP + invite par mail MENU MFA: Protection > Authentication Methods > Policies (moderne, cibler users/groups + methods FIDO2/Authenticator/SMS/etc) / Per-user MFA legacy (Disabled/Enabled/Enforced) / RECOMMANDÉ Conditional Access > Policies (require MFA conditionnel) Security Defaults: gratuit, all-or-nothing, Authenticator only, admins MFA immédiat + users 14j, bloque legacy auth - INCOMPATIBLE Conditional Access (désactiver SD pour activer CA) SSPR: cloud users = gratuit / hybrid users = P1 (password writeback obligatoire vers AD) Conditional Access: signals (user/group/app/device/location/risk) → controls (require MFA / compliant / block / session) - P1 requis, risk-based = P2 CA Grant vs Session controls: GRANT = MFA / compliant device / hybrid joined / approved app / terms of use (s'applique à la connexion) - SESSION = expérience DANS l'app (sign-in frequency, persistent browser, app-enforced restrictions) - MFA s'exige TOUJOURS en GRANT, jamais en SESSION Break-glass accounts: 2 comptes admin EXCLUS de CA et MFA, monitorer alertes sign-in Named Locations (CA): IP ranges ou pays → trusted/blocked dans policies PIM (P2): activation temporaire rôle Entra / RBAC / groupe (approval + justification + MFA + time-bound) Identity Protection (P2): sign-in risk (impossible travel, anonymous IP...) + user risk (leaked creds...) - intégré dans CA via conditions "user risk"/"sign-in risk" Access Packages (P2 - Entitlement Mgmt): catalog → ressources (GROUPS + APPS + SharePoint, PAS de resources Azure RBAC) → packages (qui demande, qui valide, expiration) - self-service Access Reviews (P2): revue périodique des accès (rôles, groups, packages, guests) App Proxy: agent onprem + relai cloud pour publier apps internes via Entra (auth Entra + SSO) - publié en Enterprise App Sign-in logs vs Audit logs: Sign-in = connexions users / Audit = changements admin (créa user/role/group) - Entra > Monitoring

NETWORK DNS delegation: NS record chez parent pointe vers nameservers Azure - délégation subdomain = ajouter NS record dans la zone PARENT pointant vers les NS de la zone enfant DNS public zone import (zone file BIND): Azure CLI ou Portal UNIQUEMENT - PAS PowerShell, PAS ARM template VNet: 1 région, pas d'overlap avec VNet peerés, 5 IPs réservées/subnet (.0 network, .1 default gw, .2 .3 DNS Azure, .255 broadcast) Subnets spéciaux (NOM EXACT + taille): GatewaySubnet /27 (VPN/ER) / RouteServerSubnet /27 / AzureBastionSubnet /26 / AzureFirewallSubnet /26 / AzureFirewallManagementSubnet /26 Public IP: Standard SKU = static obligatoire + supporte zones / Basic déprécié sept 2025 - SKU PIP doit MATCH SKU LB (basic↔basic, std↔std) Outbound options (priorité Azure): NAT GW > LB outbound rules > Instance-level PIP > Default outbound (DÉPRÉCIÉ sept 2025) - MS recommande NAT GW NAT Gateway: NIVEAU SUBNET (1 subnet=1 NAT max, 1 NAT couvre plusieurs subnets), OUTBOUND ONLY, jusqu'à 16 PIPs ~1M ports SNAT, route auto via system route (PAS d'UDR), zonal (pas zone-redundant), PAS sur GatewaySubnet NSG: stateful, L3/L4 (IP+port), s'applique NIC OU subnet, priorité 100-4096, eval subnet PUIS NIC - PAS L7 ASG: regroupement de NICs MÊME VNet (même région), utilisé dans règles NSG (source/dest) - PAS de nesting UDR (route table): priorité UDR > BGP > System routes - hub-and-spoke: 0.0.0.0/0 next hop NVA - associée au subnet HUB & SPOKE traffic via NVA: 1) Allow forwarded traffic sur peerings (côté spoke surtout, idéal partout) 2) UDR sur spokes → NVA 3) IP forwarding ON sur NIC du NVA (Azure Firewall pas besoin) Service chaining (spoke-to-spoke via NVA dans hub): UDR sur spoke avec AddressPrefixes du spoke distant + next hop = NVA - PAS besoin de nouveau VPN GW, PAS Virtual Network Manager VNet Peering: bidirectionnel, NON transitif, backbone MS, cross-region/sub/tenant OK, PAS chiffré par défaut (option encryption), Sync peer si modif address space Standard LB scope: NE peut PAS load-balancer entre VMs de VNets DIFFÉRENTS (même peerés) - VMs backend doivent être MÊME VNet Peering gateway sharing: "Allow gateway transit" côté HUB (partage VPN GW) + "Use remote gateways" côté SPOKE VPN Gateway: route-based (recommandé, BGP + P2S + multi-tunnels) vs policy-based (legacy, S2S simple) - Basic SKU = pas de BGP, pas de zones, pas d'OpenVPN, pas d'Entra auth S2S VPN setup: 1) GatewaySubnet 2) VPN GW (route-based, VpnGw1+ si BGP) 3) Local Network Gateway (= onprem) 4) Connection (shared key) P2S VPN setup: 1) GatewaySubnet 2) VPN GW route-based 3) Auth (cert / Entra ID / RADIUS) 4) Address pool clients 5) Tunnel type (OpenVPN OBLIGATOIRE pour Entra auth) 6) Download VPN client + connect P2S après changement topologie (nouveau peering, nouveau VNet, route modifiée): REDOWNLOAD + REINSTALL le VPN client config sur les PCs - sinon les nouvelles routes ne sont pas connues ExpressRoute: connexion privée via partenaire (PAS via Internet), 50Mbps-100Gbps, peering Private (vers VNet) + Microsoft (vers M365/PaaS) - nécessite ExpressRoute Gateway dans GatewaySubnet VWAN: hub managé MS - Basic = S2S uniquement / Standard = S2S + P2S + ER + Hub-to-Hub global transit Service Endpoint: NIVEAU SUBNET, plusieurs services OK (Storage/SQL/KeyVault/etc), GRATUIT, source IP = privée VM, route via backbone, MÊME RÉGION (sauf Storage), PAS depuis onprem Private Endpoint: NIC privée DANS ton VNet pour service PaaS, IP PRIVÉE, payant, cross-region OK, accessible depuis onprem via VPN/ER, intégration Private DNS Zone auto Private DNS Zone: zone privée, link vers VNets (jusqu'à 1000) - AUTO-REGISTRATION = MAX 1 zone par VNet (autres zones = Resolution only) / 1 zone peut être liée à plusieurs VNets en auto-reg Private DNS et peering: résolution NE TRAVERSE PAS le peering, lier explicitement les VNets aux zones nécessaires Private Resolver: PaaS managé (remplace VM DNS forwarder) - 2 endpoints: Inbound (queries entrantes onprem→Azure) + Outbound (queries Azure→onprem via Forwarding Ruleset) - subnets DÉDIÉS délégués Microsoft.Network/dnsResolvers /28 min Utiliser Private Resolver: pas de case à cocher / configurer Custom DNS du VNet = IP Inbound EP + lier Forwarding Ruleset aux VNets cibles Azure Firewall: L4/L7 stateful, FQDN filtering, threat intel, DNAT/SNAT, subnet AzureFirewallSubnet /26 - Premium = TLS inspection + IDPS + URL filtering DDoS Protection: Basic gratuit auto / IP Protection ou Network Protection payants (SLA + telemetry + Rapid Response Team) Network Watcher: IP flow verify / Next hop / Connection troubleshoot / NSG diagnostic / Packet capture / Flow logs (stockés en Storage)

VM: Familles VM: quota par region & sub - A/B/D = General Purpose / F = Compute Optimized / E/M = Memory Optimized / L = Storage Optimized / N (NC/ND/NV) = GPU / H = HPC Move VM: cross sub/RG OK / cross region IMPOSSIBLE (utiliser ASR replication) / change de VNet impossible sans recréer (mais change de subnet dans MÊME VNet OK via NIC) Redeploy VM: déplace vers AUTRE HOST physique dans la MÊME région (utile pour panne hardware) - JAMAIS cross-region - PAS confondre avec move Génération: Gen1 (BIOS legacy) / Gen2 (UEFI, support Trusted Launch + secure boot + vTPM + disques >2TB) - Trusted Launch = recommandé, nécessite Gen2 Modèles paiement: PAYG / Spot (capacité Azure inutilisée, peut être éjectée, JAMAIS prod) / Reserved (1 ou 3 ans, -40 à -70%) / Savings Plan (engagement $/heure, flexible) / AHB Azure Hybrid Benefit (ramène licences Win Server/SQL) Lifecycle: Stopped = paie compute encore (rare cas) / Stopped (deallocated) = pas de compute, mais storage + IP réservée toujours payés / Running = full price Auto-shutdown: configurable par VM (heure + timezone + notification webhook/email) - économie coûts dev/test Disks: OS = C:\ / Data = E:\ ou autre (persistant) / Temp = D:\ (éphémère, perdu au dealloc) - Ultra Disk + Premium SSD v2 = DATA UNIQUEMENT (pas OS) / Premium SSD v1, Std SSD, Std HDD = OS + Data OK Managed Disks: gérés par Azure (par défaut depuis 2017), supportent snapshots, copies, AZ deployment - unmanaged disks = legacy (VHD dans storage account, déconseillé) Disk caching: None (write-heavy/log) / ReadOnly (OS disk default, read-heavy) / ReadWrite (data disk default, attention aux écritures non flushées) Resize VM / attacher NIC additionnelle: VM doit être STOPPED - resize crée reboot (interruption) Reset password / SSH key: via portal "Reset password" (utilise VMAccess Extension) - VM doit avoir l'agent VM running + accès via Run Command si bloqué Accelerated Networking: SR-IOV, bypass host pour faible latence + perf - activable sur NIC (selon SKU VM compatible), peut nécessiter stop VM Outils config: cloud-init (Linux, au premier boot) / Custom Script Extension (post-deploy, exécution unique) / Azure Automation DSC (déprécié au profit de Machine Config) / Machine Config (intégré Azure Policy, audit + remédiation guest) / Azure Arc (gérer VMs onprem/multi-cloud dans Azure) Azure Update Manager: scan + patch (on-demand / periodic assessment / scheduled via Maintenance Configuration) - Maintenance Configuration = standard moderne (remplace Update Management classic) VMSS Uniform: VMs identiques (homogène, autoscale optimal) / VMSS Flexible: VMs hétérogènes, visibles individuellement dans RG, support FD - Upgrade policy: Manual / Automatic / Rolling - Autoscale: manual / scheduled / metric-based HA: AS = panne rack/MAJ MS dans MÊME DC / AZ = datacenters différents dans région / ASR = DR cross-region (région paire) AS Fault Domain (FD): racks/alim/réseau indépendants, range 1-3, DEFAULT 2 / Update Domain (UD): groupes de maj séquentielle MS, range 1-20, DEFAULT 5 - AS et AZ MUTUELLEMENT EXCLUSIFS (sauf VMSS Flexible) SLA: 1 VM (Premium SSD) 99.9% / 2+ VMs AS 99.95% / 2+ VMs AZ 99.99% PPG (Proximity Placement Group): VMs physiquement proches pour low latency - risque échec déploiement si plus de capacité dans le rack Compute Gallery (ex-Shared Image Gallery): partager images custom cross sub/region, versioning, replication multi-region Snapshots & Backup: Snapshot disque = point-in-time copy / Azure Backup (Recovery Services Vault) = backup automatisé, retention, app-consistent (VSS Windows) JIT VM Access (Defender for Cloud): ouvre les ports admin (RDP/SSH) à la demande pour durée limitée + IP source spécifique - réduit surface d'attaque Encryption: SSE (storage at rest AES-256, ACTIVÉ par DEFAULT) / Encryption at Host (chiffre temp disk + cache VM, recommandé) / ADE = Azure Disk Encryption: BitLocker Win / dm-crypt Linux (en cours de dépréciation) - PMK (platform-managed) ou CMK (customer-managed via Key Vault + Disk Encryption Set) Key Vault pour CMK / ADE: DOIT avoir soft delete + purge protection activés ADE + KEK: ADE chiffre disque avec BEK (BitLocker Encryption Key) stockée en Key Vault / KEK (Key Encryption Key, OPTIONNELLE) = wrap la BEK pour couche supplémentaire - flux: disk ← BEK ← KEK ← Key Vault ADE + KEK setup: 1) Générer cle KEK dans Key Vault (TYPE RSA OBLIGATOIRE, 2048/3072/4096) 2) Access policy WrapKey/UnwrapKey accordée au resource provider "Azure Disk Encryption" (PAS au VM resource provider - piège exam classique) CMK prérequis universels (VM/Storage/SQL): KV avec Soft-delete ACTIVÉ + Purge protection ACTIVÉE + clé RSA 2048+ + identité ressource (MI ou DES) avec Get/WrapKey/UnwrapKey - sans ces 4 = refus CMK Encryption at Host setup CMK: 1) feature register Microsoft.Compute/EncryptionAtHost sur sub 2) KV+key RSA 3) Disk Encryption Set (DES) pointe vers KV 4) MI du DES = access policy KV 5) VM create > Encryption at host ON + CMK + select DES Monitor & Troubleshoot: Boot diagnostics (screenshot + console output au boot, troubleshoot boot stuck) / Serial console (accès console live via portail Win/Linux) / AMA Azure Monitor Agent (moderne, remplace MMA retiré août 2024) / DCR Data Collection Rule = définit QUOI collecter + OÙ envoyer / DCE Data Collection Endpoint = endpoint réseau ingestion pour AMA / VM Insights = perf + maps de dépendances (utilise AMA + Dependency Agent) Extensions VM: Custom Script / DSC / AMA / Dependency Agent / Network Watcher Agent / Antimalware / KeyVault VM Extension - installables via portal/CLI/ARM/Policy

STORAGE: Types SA: GPv2 (blob/file/queue/table, standard) / Premium Block Blob (block + append blob, low latency) / Premium File Share (files SMB/NFS premium) / Premium Page Blob (page blob, VM disks) - GPv1 et BlobStorage legacy (à migrer en GPv2) Move SA: cross sub/RG OK / cross region IMPOSSIBLE (recréer + AzCopy) Replication (durabilité): LRS = 3 copies dans 1 DC (11 nines) / ZRS = 3 copies sur 3 AZ même région (12 nines) / GRS = LRS primary + LRS secondary région paire = 6 copies (16 nines) / GZRS = ZRS primary + LRS secondary = 6 copies (16 nines) Read access secondary: RA-GRS / RA-GZRS = lecture seule sur région paire (endpoint -secondary) Compatibilité réplication: LRS dispo PARTOUT / ZRS dispo GPv2 + Premium (block/file/page) / GRS + RA-GRS dispo GPv2 + GPv1 (pas Premium) / GZRS + RA-GZRS dispo GPv2 UNIQUEMENT Failover: customer-initiated unplanned failover vers région secondaire (RPO ~15min-1h), devient LRS après failover, manuel ou Microsoft-initiated Conversion replication: LRS ↔ GRS/RA-GRS = live migration auto / LRS ↔ ZRS = customer-requested live migration / LRS → GZRS = 2 étapes ou ticket support / ZRS ↔ GZRS = live migration / Premium = options limitées Access tiers (blob block UNIQUEMENT, GPv2 + BlobStorage): Hot (frequent, storage cher + transactions cheap) / Cool (30j min, storage cheap + transactions cher) / Cold (90j min) / Archive (180j min, offline, rehydration heures) Lifecycle Management: policy automatique pour move blob entre tiers ou delete selon âge/modification Lifecycle scope ARM (PIÈGE): actions sur baseBlob (daysAfterModification ou daysAfterLastAccess) / snapshot (daysAfterCreation) / version (daysAfterCreation) - rule sur snapshot ≠ blob courant - filters.prefixMatch = array prefixes (containers ciblés UNIQUEMENT, reste pas affecté) HNS (Hierarchical Namespace): active Data Lake Storage Gen2 = vrais dossiers (pas flat namespace) + ACL POSIX - ONE-WAY ENABLE (pas désactivable après) Soft delete: blob (1-365j) + container (1-365j) + SA (rétention 7-365j) - recover deleted Versioning: garde versions automatiques de blob (à activer au niveau SA) - REQUIS pour version-level immutability Change feed: log audit de toutes modifications blob (append-only) - REQUIS pour object replication (côté source) Object replication: block blob UNIQUEMENT (GPv2 + Premium Block) - PRÉREQUIS source: versioning + change feed / PRÉREQUIS destination: versioning - cross-region OK, async, source + dest = SAs différents Immutable storage: WORM (Write Once Read Many) - container-level OU version-level policy / Time-based retention (locked = immuable ou unlocked) / Legal hold (tags, suppression possible avec rôle) Public access: anonymous container access DÉSACTIVÉ par défaut sur nouveaux SAs (sécurisé) / désactivable au niveau SA / préférer SAS ou private endpoint SAS tokens (3 types): Account SAS (signed account key, multi-services) / Service SAS (signed key OU stored access policy, 1 service) / User Delegation SAS (signed Entra ID, RECOMMANDÉ, pas de key exposée, requiert rôle Storage Blob Data) Stored Access Policy: container-level, permet de révoquer un Service SAS en modifiant/supprimant la policy Encryption: SSE AES-256 TOUJOURS ACTIVÉE (non désactivable) - PMK platform-managed (défaut) ou CMK customer-managed (Key Vault + Managed Identity sur SA) / Infrastructure encryption = double encryption (à activer à la CRÉATION du SA) / Encryption scopes = granular par container/blob Encryption Scopes (BLOB only) détail: clés indépendantes par container/blob (override config SA) - PMK ou CMK par scope, Infrastructure encryption activable par scope - assignation default par container OU override par blob via header x-ms-encryption-scope - use case multi-tenancy (1 container/tenant avec sa clé CMK) Storage CMK setup: 1) KV avec soft-delete + purge protection 2) Key RSA 2048+ 3) SA > Identity > System assigned ON 4) MI du SA = access policy KV (Get/Wrap/Unwrap) 5) SA > Encryption > CMK + select key (version auto recommandée) Transport: HTTPS only (par défaut) + TLS 1.2 min (configurable au SA) Backup blob: Operational backup (soft delete + versioning + change feed + restore point-in-time, jusqu'à 360j) / Vaulted backup (envoyé en Recovery Services Vault, longue rétention) - BLOCK BLOB uniquement en GPv2 Backup file share: Recovery Services Vault (snapshots, daily, retention configurable) Azure Files: SMB 2.1/3.x (Win/Linux/Mac, port 445) + NFS 4.1 (Premium UNIQUEMENT, Linux) - Tiers: Premium (SSD, low latency) / Standard: Transaction Optimized / Hot / Cool Auth Azure Files: AD DS onprem / Entra Domain Services / Entra Kerberos (hybrid users) - PAS d'auth cloud-only Entra pur / SA joint au domaine avec son objet computer Setup AD DS auth Azure Files: 1) Sync AD onprem → Entra 2) Enable AD DS auth sur SA 3) Assign RBAC share-level (Storage File Data SMB Share Reader/Contributor/Elevated Contributor) 4) Set NTFS ACLs file-level 5) Mount le share Azure File Sync: sync share onprem ↔ Azure Files - Composants: Storage Sync Service → AFS Agent installé serveur → Register serveur → Sync Group (1 cloud endpoint + N server endpoints) - Cloud tiering = garder fichiers récents en local + reste cloud (libère espace) AFS limites sync group: 1 sync group = 1 SEUL cloud endpoint - PAS 2 server endpoints du MÊME serveur dans le MÊME sync group (même si dossiers différents) - 2 server endpoints sur même volume OK seulement si namespaces non-overlapping + sync groups DIFFÉRENTS Azure NetApp Files (ANF): NFS/SMB managé enterprise high-perf (SAP, HPC, EDA) - tiers Standard/Premium/Ultra - ressource SÉPARÉE (pas dans un SA) - AZ-104 rarement, AZ-305/AZ-700 oui Data transfer tools: AzCopy (CLI, blob + file, le plus rapide) / Storage Explorer (GUI desktop) / Storage Browser (portal web) / Data Box (disque physique envoyé MS, TB-PB scale, offline) / Data Box Disk (petit, ~8TB) / Data Box Heavy (~1PB) / Import/Export (legacy, ship ses propres disques) / Data Box Gateway (virtual appliance, ongoing transfer) AzCopy auth Blob ET File: SAS token OU Entra ID (PAS Kerberos, PAS API key, PAS account key directe) - Entra ID requiert rôle Storage Blob/File Data Contributor Choisir le tool: petits volumes online → AzCopy / GUI rapide → Storage Explorer ou Browser / gros volume avec bandwidth limité → Data Box (envoi physique) / sync continu onprem → AFS ou Data Box Gateway

APP SERVICE: App Service Plan (ASP) = le compute facturé qui héberge les apps - 1 ASP peut héberger N apps (qui partagent les ressources) Tiers ASP: Free F1 (60min CPU/j, pas de custom domain) / Shared D1 (custom domain mais pas de SSL) / Basic B1-B3 (dedicated, SSL, VNet Integration, manual scale, PAS de slots ni autoscale) / Standard S1-S3 (+ Slots x5 + Autoscale + Daily backup + Traffic Manager) / Premium v2-v3 (+ Private Endpoint + Slots x20 + meilleure perf) / Isolated v2 = ASE v3 (dans TON VNet) Custom domain: enregistrer TXT (verification) + A ou CNAME (binding) chez le registrar - tier Shared D1+ requis TLS/SSL: App Service Managed Certificate (gratuit, auto-renew, single domain, pas de wildcard) / Bring Your Own / Import depuis Key Vault - SNI binding recommandé (IP-based legacy) Slots de déploiement (Standard+): staging/test/prod en parallèle, swap zero-downtime, % de traffic (canary), slot-specific settings - 5 slots Standard / 20 slots Premium Scaling: Scale UP = changer tier (plus puissant) / Scale OUT = ajouter instances (manual / autoscale rules CPU-mem-HTTP-schedule) - autoscale = Standard+ Easy Auth (Authentication / Authorization): built-in Entra ID / Microsoft / Google / Facebook / X / OpenID Connect - sans coder l'auth dans l'app Managed Identity: System-assigned (lié à l'app, supprimé avec) ou User-assigned (réutilisable) - accès Key Vault/Storage/SQL sans secrets App Settings vs Connection Strings: env vars injectées au runtime, slot-specific possible, référence Key Vault possible (@Microsoft.KeyVault(SecretUri=...)) Always On (Basic+): garde l'app warm (sinon idle après 20min sans request) VNet Integration (OUTBOUND): app accède à ressources VNet ou onprem - subnet dédié /28 min - Standard+ Private Endpoint (INBOUND): IP privée pour l'app, accès depuis VNet uniquement - Premium v2+ Hybrid Connections (via Azure Relay): outbound app → endpoint onprem TCP spécifique (host:port) - Hybrid Connection Manager installé onprem - traffic sortant via 443 - utile quand PAS de VPN/ER ASE v3 (App Service Environment - Isolated v2): déployé dans TON VNet, full isolation réseau + grande échelle, prix élevé, pour workloads sensibles/régulés WAF: PAS natif App Service - mettre derrière Application Gateway WAF_v2 OU Azure Front Door + WAF policy Diagnostic logs: Application logging (filesystem retention 12h / Blob illimité) / Web server logging (HTTP requests, IIS-style) / Detailed error messages (pages d'erreur HTML détaillées) / Failed request tracing (traces IIS détaillées, WINDOWS UNIQUEMENT) Logging levels (du moins au plus verbeux): Disabled < Error < Warning < Information < Verbose Backup: intégré (Standard+) - app + config + DB liée optionnelle (SQL/MySQL), vers Storage Account, retention configurable, partial backup possible Deployment methods: Git local / GitHub Actions / Azure DevOps Pipelines / ZIP deploy / FTP / Containers (Linux) - slots = blue-green deployment Stack: Windows (.NET, Java, PHP, Python, Node) ou Linux (idem + containers Docker natif) Quota & limits: ASP a des limites CPU/mémoire/bande - scale up si saturé, scale out pour HA

CONTAINER: ACR (Azure Container Registry): registry privée d'images Docker/OCI - SKUs Basic (dev) / Standard (anonymous pull + webhooks) / Premium (geo-replication + Private Endpoint + CMK + content trust + zone-redundant + Customer-Managed Keys) ACR auth: Admin user (legacy déconseillé) / Service Principal / Managed Identity (recommandé) / Entra ID + Azure RBAC (rôles AcrPull, AcrPush, AcrDelete) ACR Tasks: build images dans Azure depuis Dockerfile - Quick Task (ad-hoc, équivalent docker build) / Multi-step (YAML pipeline) / Triggers automatiques (git commit, base image update, schedule) ACI (Azure Container Instances): containers SIMPLES sans orchestration, pay-per-second, démarrage rapide - 2 modes: PUBLIC IP avec DNS name label (FQDN

LOAD BALANCING: Vue d'ensemble: Load Balancer L4 (régional) / Application Gateway L7 (régional) / Front Door L7 (GLOBAL + CDN + WAF) / Traffic Manager (DNS-based GLOBAL, pas dans data path) Règle d'or AZ-104: multi-region + L7 + WAF + CDN → Front Door / Single-region L7 (HTTP) → App Gateway / Trafic NON-HTTP (DB, IoT, gaming, custom TCP/UDP) → Load Balancer / Active-passive simple cross-region (DNS) → Traffic Manager Public LB vs Internal LB (ILB): Public = frontend IP publique vers Internet / Internal = IP privée dans VNet, pour traffic interne multi-tier (front → app → DB) Load Balancer (L4 TCP/UDP): Basic (retiré) vs Standard (zones, HA ports, outbound rules, SLA 99.99%, secure-by-default = NSG requis) - Frontend IP → Backend Pool via Health Probe + LB Rule LB Standard backend pool: VMs dans MÊME VNet (ou cross-VNet en region) - VMs PEUVENT être stopped/deallocated (restent dans pool) - PAS de PIP requise sur VM (l'IP publique = celle du LB) - SKU VM/NIC = Standard LB SKU rule: TOUS composants (LB + PIP + VM NIC parfois) DOIVENT MATCH en SKU (basic↔basic, standard↔standard) - sinon erreur de déploiement Inbound NAT rule: forward UN port frontend vers UN port d'une VM backend précise (ex: LB:50001 → VM1:3389 RDP) - accès individualisé sans Bastion - DIFFÉRENT de LB rule qui distribue sur le pool entier Outbound rules (Standard LB): configure SNAT outbound explicite (ports SNAT alloués par instance) - depuis sept 2025 default outbound déprécié → utiliser NAT Gateway recommandé Session persistence: None (default round-robin) / Client IP (2-tuple) / Client IP + Protocol (3-tuple) - garde session sur même VM backend Health Probe: TCP / HTTP / HTTPS - interval + threshold - VMs unhealthy retirées AUTO du pool Application Gateway (L7 régional): HTTP/HTTPS - SSL termination + end-to-end SSL, URL path-based routing, host-based routing (multi-site), rewrite URL/headers, redirect HTTP→HTTPS, cookie-based session affinity, AGIC (AKS Ingress) App Gateway SKUs: Standard_v2 (routing L7, SSL, path/host-based) / WAF_v2 (Standard_v2 + protection OWASP Top 10, SQL injection, XSS, bot manager) - choisir WAF_v2 dès que besoin de protection applicative App Gateway subnet: DÉDIÉ /24 recommandé - listener + routing rules (basic ou path-based) + backend pool + HTTP settings WAF (Web Application Firewall): protection OWASP Top 10 + custom rules + bot manager - dispo sur App Gateway (WAF_v2) ou Front Door (Premium) Front Door (L7 GLOBAL): edge distribué sur POPs Microsoft mondiaux - routing global + CDN caching + WAF + SSL offload + URL rewriting + session affinity + custom domains - anycast = faible latence Front Door SKUs: Standard (CDN + DDoS Standard) / Premium (+ WAF Managed Rules + Private Link to origin + bot protection) Traffic Manager: routing DNS-only (PAS dans data path, juste résolution DNS qui dirige le client vers le bon endpoint) - PAS de SSL (le client se connecte direct à l'endpoint après résolution) - supporte HTTP ET NON-HTTP - failover health checks par endpoint Traffic Manager routing methods: Priority (failover actif-passif) / Weighted (% load distribution) / Performance (latence min) / Geographic (par pays/région utilisateur) / MultiValue / Subnet Bastion: RDP/SSH via portail HTTPS SANS IP publique sur VM - AzureBastionSubnet /26 min - SKUs: Basic (RDP/SSH only, 2 instances scale) / Standard (file copy, IP-based connection, native client, host scaling jusqu'à 50, shareable links) Bastion scope: déployé dans 1 VNet, accessible aux VMs du VNet + VMs des VNets PEERÉS (cross-region OK via peering) Edge security combo: Front Door + WAF (global edge) / App Gateway + WAF (regional L7) / Azure Firewall (L4/L7 inside Azure perimeter) / DDoS Protection (Network ou IP, gratuit Basic auto)

GOVERNANCE: Hiérarchie Azure: Root Tenant > Management Groups (jusqu'à 6 niveaux) > Subscriptions > Resource Groups > Resources - héritage RBAC/Policy/Tags descendant Management Group: regroupe subscriptions pour appliquer policies + RBAC à grande échelle - max 10000 MGs / tenant Subscription: unit de billing + scope de quota / limits - 1 sub = 1 Entra tenant (lié) Resource Group (RG): conteneur de métadonnées + cycle de vie - resources d'un RG = MÊME tenant + RG a une région (mais resources peuvent être dans d'autres régions) Tags: paires clé-valeur appliquées à Sub / RG / Resource ET aussi Management Group (depuis 2022) - max 50 tags par resource - utilisés pour billing, automation, organisation Tag inheritance: PAS automatique - utiliser Azure Policy "Inherit tag from resource group" ou effet "Append/Modify" - différent des tags Cost Management (pour groupement billing) Locks: 2 types: ReadOnly (lecture seule, bloque modif + delete) / CanNotDelete (bloque delete seulement) - appliqués sur Sub / RG / Resource (PAS sur Management Group nativement, utiliser Policy deny pour ça) Lock inheritance: hérités du parent au child (Sub → RG → Resource) - le PLUS RESTRICTIF gagne (ReadOnly > CanNotDelete > rien) - lock parent non remplaçable par lock enfant moins restrictif Cost Management: Cost Analysis (vue spending par sub/RG/tag/service) / Budgets (alertes à seuils % - email/action group/webhook) / Cost Alerts / Exports (vers Storage Account, automatisé) Advisor: recommandations sur 5 piliers - Cost / Security / Reliability / Operational Excellence / Performance - identifie idle/unattached disks, VMs sous-utilisées, reservations à acheter, etc. Disques non attachés / VMs idle / reservations: visibles dans Advisor > Cost recommendations (PAS dans Cost Management - Cost Mgmt agrège juste l'affichage) Saving Plans vs Reservations: Reservations = engagement sur SKU spécifique 1/3 ans (-72% max) / Savings Plan = engagement $/heure flexible 1/3 ans (-65% max, plus flexible workload mix) Azure Policy: imposer règles / audit ou enforce - scope MG / Sub / RG / Resource - exemptions possibles - effets: Audit (compliance report) / Deny (bloque create) / Append (ajoute property) / Modify (modifie tag) / DeployIfNotExists (déploie ressource si manque) / AuditIfNotExists / Disabled Resource Policy Contributor: rôle dédié pour CRÉER + ASSIGNER policies (least privilege) - PAS Contributor (trop large), PAS Automation Contributor Root Management Group access: nécessite Global Admin + activer "Access management for Azure resources" dans Entra (élévation tenant root) - Owner sur subscription ne suffit PAS pour root MG Policy Initiative (Policy Set): groupe de policies (ex: ISO 27001, NIST) - assigne en bloc avec paramètres Policy Remediation: pour DeployIfNotExists / Modify - nécessite Managed Identity sur l'assignment pour déployer/modifier Policy compliance: Compliance dashboard dans Policy > scan régulier (24h) - state Compliant/Non-compliant/Exempt ARM Templates: JSON Infrastructure-as-Code natif Azure - idempotent, declarative Bicep: DSL plus lisible que JSON (compile vers ARM) - équivalent de Terraform mais Azure-only et natif Bicep modules vs Linked vs Nested Templates: Bicep module = fichier .bicep réutilisable / Linked Template = template ARM externe via URI HTTP / Nested = template inline dans parent (rare AZ-104, savoir qu'ils existent suffit) ARM/Bicep param constraints: allowedValues (liste fermée, ex SKUs) / minValue+maxValue (int) / minLength+maxLength (string, ex SA name 3-24) / defaultValue / metadata.description / secureString OU secureObject pour secrets (masqué dans logs deployment) - validation rejetée si non respectée Deployment scopes: Resource Group (default, pas besoin de location) / Subscription / Management Group / Tenant (ces 3 = need location parameter) Deployment modes: Incremental (default, ajoute/modifie sans toucher au reste) / Complete (SUPPRIME les resources du RG qui ne sont PAS dans le template) - Complete = dangereux What-If: simule un déploiement et montre les changements sans appliquer - validation préventive Template Specs: stocke un template ARM/Bicep comme resource Azure - versionning + RBAC dessus Deployment Stacks (moderne): groupe de ressources gérées ensemble en tant qu'unité - lifecycle management + deny settings + cleanup Deployment history: voir date/heure des déploiements ARM/Bicep dans RG > Deployments blade (PAS Properties, PAS Policies) PowerShell custom role from builtin: Get-AzRoleDefinition -Name | ConvertTo-Json (export en JSON pour modif) - PAS Get-AzRoleAssignment (qui liste les assignments) Move resources: cross RG / cross sub (même tenant) = supporté pour la plupart des resources (pas toutes - vérifier docs) - cross region IMPOSSIBLE nativement (utiliser Azure Resource Mover, ASR pour VMs, ou recreate manuellement) - VALIDATE move avant exécution RBAC scopes & built-in roles: Owner (full + assign rôles) / Contributor (full sans assign) / Reader (lecture) / User Access Administrator (gère seulement assignments) - scopes Mg/Sub/RG/Resource - rôle hérite du parent au child

BACKUP: Vue d'ensemble: Azure Backup (service) / Recovery Services Vault RSV (stockage VM/SQL/Files/ASR) / Backup Vault (services modernes: Disks/Blobs/PostgreSQL/AKS) / ASR (Site Recovery = DR cross-region, PAS du backup) RSV supporte: Azure VM / SQL on Azure VM / SAP HANA on Azure VM / Azure File Share / MABS / DPM / onprem via MARS agent / ASR Backup Vault supporte: Azure Disks / Azure Blob (operational + vaulted) / PostgreSQL / AKS - PAS Storage Account entier (service par service) Localisation: RSV ET Backup Vault = REGIONAL (même région que les resources protégées) Replication vault: LRS / ZRS / GRS (default, requis pour cross-region restore) Snapshot vs Backup: Snapshot = point-in-time du disque (instantané, pas de policy, dans le storage du disque) / Backup = policy + rétention + vault dédié + restore options VM Extension Backup: s'installe AUTO quand on enregistre la VM dans RSV - la POLICY (fréquence + retention) est définie sur le RSV Backup VM cohérence: app-consistent (VSS Windows) / file-consistent (Linux script pre-post) / crash-consistent (fallback) Restore VM options: Create New (nouvelle VM) / Restore Disks (juste les disques) / Replace Existing (remplace VM courante) Replace Existing détails: 1) Snapshot la VM courante en staging 2) Remplace les disques attachés par ceux du recovery point 3) Les anciens disques détachés RESTENT dans le RG (à réattacher manuellement si besoin) - PIÈGE: un disque ajouté APRÈS le backup n'est pas dans le recovery point → détaché après restore, JAMAIS le delete avant vérification (réattacher via VM > Disks > Attach existing disks) Backup Azure Files: snapshot-based stocké dans RSV (pas Backup Vault) - retention configurable MARS (Microsoft Azure Recovery Services) agent: client léger onprem - backup files/folders/system state d'UN serveur Windows directement vers RSV (sans infra intermédiaire) - PAS de backup VM (Hyper-V/VMware) - piège exam: "backup VM on-prem" → MABS ou DPM, JAMAIS MARS MABS (Microsoft Azure Backup Server): serveur backup onprem complet (VMs / SQL / Exchange / SharePoint) avec staging local + envoi vers RSV DPM (System Center Data Protection Manager): legacy enterprise, équivalent MABS dans écosystème System Center MARS vs MABS vs DPM: MARS = fichiers/system state d'UN serveur (léger) / MABS = backup apps + VMs avec staging onprem / DPM = legacy System Center App Service Backup: intégré au service (Standard+) - envoyé vers Storage Account configuré, retention configurable, app + config + DB liée optionnelle ASR (Azure Site Recovery): RÉPLICATION continue (DR) cross-region OU onprem → Azure - PAS du backup - RSV dans région SECONDAIRE - Mobility Service Agent installé sur VM source (PAS AMA) - replication policy + recovery plan ASR opérations: Failover (planifié ou unplanned) / Test Failover (DR drill sans impact prod) / Reprotect (resync après failover) / Failback (revenir primaire) ASR ordre failover réel (post-incident): 1) Verify VM protected + healthy 2) Failover 3) Reprotect - PAS Test Failover (= drill) / PAS Failback (= après recovery primaire) ASR prérequis VM: Managed Disks OBLIGATOIRES - si unmanaged: VM > Disks > Migrate to managed disks (VM stoppée requise) AVANT replication RPO (Recovery Point Objective): perte de données max acceptée (ASR ~30s pour VM Azure / Backup RPO = fréquence backup) RTO (Recovery Time Objective): temps max pour restaurer le service après incident Sécurité backup: Soft delete (retention 14j default jusqu'à 180j) / Immutable vault (lock irréversible une fois activé) / Multi-User Auth MUA (double approval pour opérations critiques) / Cross-region restore (GRS requis) / CMK / Private Endpoint Supprimer un RSV: 1) Stop backup sur tous les items 2) Delete backup items 3) Delete vault (impossible avant cleanup complet)

MONITORING: Azure Monitor: service global qui centralise Metrics + Logs + Alerts + Insights pour toutes ressources Azure / onprem / multi-cloud Types de données: Metrics (numériques time-series, ex CPU% - dashboards) / Logs (texte structuré dans Log Analytics Workspace, query KQL) / Activity Log (qui a fait quoi: audit plan de contrôle, par sub) / Diagnostic Logs (par resource, via Diagnostic Settings) Metrics: rétention 93j par défaut (gratuit), granularité 1min, dashboards + Metric alerts - custom metrics via SDK / REST API Log Analytics Workspace (LAW): conteneur des logs, retention 31j gratuit (jusqu'à 730j payant + archive 12 ans) - tables typiques: AzureActivity, AzureDiagnostics, Heartbeat, Perf, Syslog, Event, AppRequests - query KQL (where / summarize / project / top / join / extend) Diagnostic Settings: configure l'envoi des metrics + logs d'une RESOURCE vers LAW / Storage Account (archive) / Event Hub (streaming) - 1 resource = jusqu'à 5 diagnostic settings Activity Log: 90j retention auto - envoyer vers LAW via Diagnostic Settings pour rétention longue + query KQL AMA (Azure Monitor Agent): agent moderne pour collecter logs/perf du GUEST OS (VM Win/Linux) - remplace MMA/Log Analytics Agent retiré août 2024 - configuré via DCR DCR (Data Collection Rule): définit QUOI collecter (perf counters, event logs, Syslog) + OÙ envoyer (LAW/Storage/EH) - associée à une ou plusieurs VMs/scale sets DCE (Data Collection Endpoint): point d'ingestion réseau pour AMA - REQUIS pour ingestion custom logs API + scénarios Private Link / network isolation - configurer DCE EN PREMIER si compliance/private endpoint Setup AMA: 1) Créer LAW 2) Créer DCE (si Private Link) 3) Créer DCR (cibles + destinations) 4) Installer AMA extension sur VM 5) Associer DCR aux VMs Alerts: 4 types - Metric Alert (seuil numérique) / Log Alert (query KQL sur LAW) / Activity Log Alert (sur événement audit) / Smart Detection (anomalies AI) - severities 0 (critical) à 4 (verbose) Alert sur événement de log (ex: "error logged in system event log"): scope = LAW (PAS la VM directement, PAS Metric alert qui ne gère que numérique) Action Groups: actions exécutées par alerts - Email/SMS/Voice / Azure Function / Logic App / Webhook / ITSM / Runbook Service Health: pannes côté Azure (issues service, maintenance planifiée, advisories) - alertes configurables par region/service Resource Health: état d'UNE resource spécifique (Available / Unavailable / Unknown / Degraded) - différent de Service Health (= côté Azure global) Insights (solutions Azure Monitor préconfigurées, nécessitent LAW): VM Insights (perf + maps dépendances, AMA + Dependency Agent) / Container Insights (AKS metrics + logs) / Network Insights (vue centralisée TOUS network resources sans agent, recommandé pour 100s de ressources) / Application Insights (apps web + APM) Network Insights vs Network Watcher: Network Insights = monitoring CENTRALISÉ vue globale toutes ressources (NSG, LB, App GW, Firewall, etc.) sans agent / Network Watcher = diagnostic per-VNet, outils techniques détaillés Application Insights: APM pour apps (web/mobile/microservices) - métriques live, traces, dependencies, exceptions - utilisable App Service / Functions / AKS / VM Application Insights Profiler: trace les REQUÊTES LENTES dans web app (call stack + temps par fonction) - PAS Activity Log, PAS Network Watcher pour ce cas Network Watcher: outils diag réseau par région - activé auto par région à la première ressource réseau Network Watcher matrix:

  • Connection Monitor: tests CONTINUS + multi-source (hybride onprem ↔ Azure, comparaison latence)
  • Connection Troubleshoot: test PONCTUEL "pourquoi VM1 → VM2 ne passe pas" (one-shot)
  • IP Flow Verify: tester si un paquet est ALLOW/DENY par NSG sur une NIC - retourne le NOM de la règle qui bloque (diag NSG)
  • NSG Flow Logs: LOGGER tout le trafic d'un NSG (compliance, audit) - stockés en Storage Account
  • Traffic Analytics: VISUALISER + analyser les NSG Flow Logs (dashboards, top talkers, geo) - nécessite LAW
  • Next Hop: où va le trafic depuis une VM vers une IP cible (UDR vs system route vs BGP)
  • Packet Capture: capture paquets sur VM (max 5h, fichier PCAP) Choix Network Watcher: blocage trafic suspect NSG → IP Flow Verify / diag E2E VM1→VM2 → Connection Troubleshoot + IP Flow Verify / monitoring continu hybride → Connection Monitor / audit compliance trafic → NSG Flow Logs + Traffic Analytics App Service logs (rappel): Application Logging (Blob = long-terme illimité) + niveau Warning recommandé pour storage (PAS Information trop large, PAS Verbose qui log tout) Kusto KQL exemples: AzureActivity | where OperationNameValue contains "delete" / Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer

FRAGILE (À RELIRE 5 MIN AVANT L'EXAM - tes pièges récurrents):

  1. NETWORK WATCHER - choisir le bon outil:
  • Blocage NSG (un paquet passe ou pas?) → IP Flow Verify (retourne le NOM de la règle bloquante)
  • Diag E2E "pourquoi VM1 → VM2 ne marche pas?" PONCTUEL → Connection Troubleshoot (one-shot)
  • Monitoring CONTINU multi-source (hybride onprem ↔ Azure, comparer latence dans le temps) → Connection Monitor
  • LOGGER tout le trafic d'un NSG pour audit/compliance → NSG Flow Logs (stockage Storage Account)
  • VISUALISER / dashboards / top talkers à partir des NSG Flow Logs → Traffic Analytics (nécessite LAW)
  • Où va mon trafic (UDR vs system route vs BGP)? → Next Hop
  • Capturer paquets bruts PCAP sur une VM → Packet Capture (max 5h) Mnémo: "Bloque? → IP Flow / 1 fois? → Troubleshoot / Tout le temps? → Monitor / Logger? → Flow Logs / Voir joli? → Traffic Analytics"
  1. CONDITIONAL ACCESS - Grant vs Session:
  • GRANT control = exigences à la CONNEXION (MFA, compliant device, hybrid joined, approved app, terms of use, password change)
  • SESSION control = ce qui se passe DANS l'app après connexion (sign-in frequency, persistent browser, app-enforced restrictions, conditional access app control, customize continuous access evaluation)
  • MFA = TOUJOURS Grant (jamais Session) - require device compliance = TOUJOURS Grant
  • Si question parle de "fréquence reconnexion" ou "browser persistence" → Session
  • Si question parle de "exiger MFA" ou "exiger device" → Grant
  1. NSG - ordre traitement + défauts:
  • Règles processed par priorité ASCENDANTE (100 = traité avant 4096) - first match wins
  • Default rules (non supprimables): AllowVNetInBound (intra-VNet OK) / AllowAzureLoadBalancerInBound / DenyAllInBound - même en outbound
  • Trafic intra-VNet TOUJOURS autorisé par défaut entre subnets du même VNet (sauf si tu mets règle DENY explicite avec priorité < 65000)
  • NSG sur subnet ET NSG sur NIC → trafic doit passer LES DEUX
  • Pour automatiser règle NSG sur création de resource → Azure Policy DeployIfNotExists ou Modify (PAS règle manuelle, PAS NSG Flow Logs qui ne fait que logger)
  1. STORAGE REPLICATION COMPATIBILITÉ (tableau à retenir):
  • LRS → dispo PARTOUT (GPv1, GPv2, BlobStorage, Premium block/file/page)
  • ZRS → dispo GPv2 + Premium Block Blob + Premium File Share + Premium Page Blob (PAS GPv1, PAS BlobStorage legacy)
  • GRS / RA-GRS → dispo GPv2 + GPv1 + BlobStorage (PAS Premium tiers)
  • GZRS / RA-GZRS → dispo GPv2 UNIQUEMENT Pièges classiques:
  • "Veux ZRS sur un GPv1" → IMPOSSIBLE, upgrade en GPv2 d'abord
  • "Veux lecture en région secondaire SANS failover" → RA-GRS (pas GRS simple, qui n'expose pas le secondary endpoint)
  • "Veux ZRS sur Premium Page Blob" → OK depuis 2023
  • "GRS sur Premium Block Blob" → IMPOSSIBLE, utiliser Object Replication à la place
  1. CROSS-REGION / MOVE / REDEPLOY:
  • Move VM cross sub/RG (même tenant) → OK natif
  • Move VM cross REGION → IMPOSSIBLE natif → utiliser Azure Resource Mover OU ASR OU recreate manuellement
  • Redeploy VM → déplace vers AUTRE HOST PHYSIQUE dans la MÊME région (panne hardware host, NE CHANGE PAS LA RÉGION)
  • VM + NIC + VNet doivent TOUS être dans la MÊME région (impossible NIC dans region différente)
  • Change de subnet dans MÊME VNet → OK via NIC config
  • Change de VNet → impossible sans recréer la VM
  1. SERVICE ENDPOINT vs PRIVATE ENDPOINT:
  • Service Endpoint:
    • Niveau SUBNET (subnet entier accède au service PaaS)
    • Source IP vue par PaaS = IP privée de la VM
    • Service garde son IP PUBLIQUE (juste route via backbone Azure)
    • GRATUIT
    • MÊME RÉGION uniquement (sauf Storage cross-region paired)
    • NE marche PAS depuis onprem via VPN/ER
  • Private Endpoint:
    • NIC PRIVÉE dans ton VNet pour le service PaaS spécifique
    • Service a une IP PRIVÉE dans ton subnet
    • PAYANT (par PE + par GB)
    • CROSS-REGION OK
    • Marche DEPUIS ONPREM via VPN/ER
    • Intégration Private DNS Zone automatique (privatelink..azure.com) Quand quoi? Onprem ou cross-region → Private Endpoint. Subnet Azure local + gratuit → Service Endpoint.
  1. LECTURE ATTENTIVE - mots-piège Microsoft à toujours souligner mentalement:
  • "LEAST administrative effort" / "MINIMUM cost" / "MINIMIZE downtime" → la solution la plus simple gagne (souvent une feature managée vs custom)
  • "FIRST step" / "NEXT action" / "WHAT must you do FIRST" → ordre exact compte
  • "MOST cost-effective" → écarter Premium si Standard suffit
  • "Without administrative effort" → built-in role > custom role / managed service > self-managed
  • "Single point of failure" / "high availability" → AZ > AS > single VM
  • "All regions" / "global" → Front Door / Traffic Manager / Cosmos DB (PAS LB régional)
  • "On-premises" présent dans le scénario → vérifier si Private Endpoint requis vs Service Endpoint
  • "Multi-tier app" + "internal" → Internal LB (PAS Public LB)
  • "Multiple subscriptions" + "policies" → Management Group scope
  • "Audit compliance" → Azure Policy effect Audit OU NSG Flow Logs OU Activity Log
  • "Block creation if" → Azure Policy effect Deny
  1. AUTRES PIÈGES RAPIDES (vu dans tes erreurs):
  • ADE + KEK → access policy au resource provider "Azure Disk Encryption" (pas VM)
  • ASR ordre failover réel post-incident → Verify → Failover → Reprotect (pas Test Failover, pas Failback)
  • ASR prérequis → Managed Disks OBLIGATOIRES (convertir unmanaged AVANT)
  • Restore VM "Replace Existing" → JAMAIS delete les disques détachés sans vérifier (recovery point antérieur = data disk ajouté après détaché)
  • Root Management Group → Global Admin + élévation "Access management for Azure resources"
  • PowerShell custom role from builtin → Get-AzRoleDefinition | ConvertTo-Json (PAS Get-AzRoleAssignment)
  • AzCopy auth → SAS OU Entra ID (PAS Kerberos, PAS account key)
  • P2S après changement topo → REDOWNLOAD + REINSTALL VPN client config
  • DNS public zone import → CLI ou Portal UNIQUEMENT (PAS PowerShell)
  • Standard LB → NE load-balance PAS cross-VNet (même peerés)
  • Alert sur log event → scope LAW (pas la VM, pas Metric alert)
  • ACA subnet → /27 workload profiles, /23 consumption
  • Disques unattached → Azure Advisor (pas Cost Management, qui n'agrège que l'affichage)
  • Resource Policy Contributor pour gérer policies (least privilege, pas Contributor)