AZ104, A retenir:

ENTRA ID -Tiers licence: -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 PTA, pas Federation), SUPPORTE password writeback + group writeback + Exchange hybrid attributes, MAIS pas de device sync (Hybrid Azure AD Join), agent léger sans SQL, limite ~150k objets/domaine -ConnectSync = full features (PTA, Federation, device writeback, filtrage avancé) mais lourd (SQL) -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) -Devices: -Entra Registered: BYOD/perso (settings > accounts > access work or school) -Entra Joined: cloud-only, login via Entra -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é -External ID: -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 -Bulk operations users: create/invite/delete/restore via CSV (~50k lignes/op, async) -App Registration = 2 objets: App object (home tenant) + Service Principal (par tenant, visible Enterprise Apps) -App Reg = TU définis l'app, Enterprise App = TU utilises l'app -App auth: Client secret (string, expire ~2 ans, visible 1x) vs Certificate (recommandé prod, clé publique uploadée) -API permissions: Delegated (app agit AU NOM du user connecté, ex User.Read) vs Application (app agit seule sans user, ex User.Read.All, exige Grant admin consent) -Redirect URI: doit MATCHER exactement -App roles: rôles métier exposés par l'app dans le token -Supported account types: single tenant / multi-tenant / multi-tenant + comptes perso (hotmail) -M365 group policies tenant-LEVEL (pas par groupe): Expiration policy (renouvellement, récup 30j) + Naming policy (préfixe/suffixe + blocked words) -Restricted Management AU: même Global Admin ne peut PAS modifier les objets sans rôle explicite dessus (protège break-glass/VIP) - case IRRÉVERSIBLE à la création -Groupe assignable rôles Entra ("Entra roles can be assigned to the group"): cochable UNIQUEMENT à la création, irréversible, P1 requis -Deny assignments: bloque même un Owner (Deny > Allow), NON créable manuellement -Azure les crée dans 3 cas: Deployment Stacks (denySettings) / Azure Blueprints (déprécié 11 juil 2026) / Managed Apps (RG mc) -NotActions ≠ deny rule: juste exclusion de l'allow - autre role assignment couvrant l'action l'autorise quand même -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) -SSPR scope tenant-wide: None / Selected (1 groupe) / All - PAS de scoping par AU - user hors du groupe Selected ne peut PAS reset -SSPR détails: -Number of methods required (1 ou 2 = 2 méthodes DIFFÉRENTES) -Default admin policy toujours active (admins = méthodes fortes) -modifier méthodes MFA d'un user = Global Admin requis (User Admin ne peut pas) -SSPR writeback supporté par Connect Sync ET Cloud Sync (depuis ~2023) -Auth methods legacy (Per-user MFA + SSPR Authentication methods) déprécié 30 sept 2025 → migrer vers Protection > Authentication methods > Policies -EXCEPTION: Security questions pas encore migrables (restent en legacy SSPR) -Méthodes auth (force): -FIDO2/Passkey + Win Hello + Cert (très fortes, phishing-resistant) -Authenticator (forte, number matching) -TAP (temporaire onboarding) -OATH (moyen) -SMS-voice (faible, SIM swap) -Email (SSPR only) -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) -Eligible (peux activer à la demande) vs Active (appliqué direct, permanent ou time-bound) -approver = n'importe qui désigné (pas de rôle prérequis), via groupe recommandé -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" -Identity Protection legacy policies (User risk / Sign-in risk / MFA registration) RETIRÉES 01/10/2026 → moteur de détection reste, actions migrées vers CA - reports Risky users/sign-ins/detections toujours actifs -App Proxy: agent onprem + relai cloud pour publier apps internes via Entra (auth Entra + SSO) - publié en Enterprise App -connector = "Microsoft Entra private network connector" sur serveur Windows on-prem (PAS sur le serveur de l'app) - outbound 443 only, AUCUN port inbound -Connector Groups = HA + routing géo -pre-auth: Entra ID (recommandé, applique CA/MFA sur app legacy) vs Passthrough (app fait son auth) -Internal URL (LAN) → External URL (msappproxy.net public) -Access Packages (P2 - Entitlement Mgmt): catalog → ressources (GROUPS + APPS + SharePoint, PAS de resources Azure RBAC) → packages (qui demande, qui valide, expiration) - self-service -EM hiérarchie: Resource (plat) → Catalog (carte) → Access Package (menu) - user demande un PACKAGE pas une ressource -EM rôles: Identity Governance Admin (boss, crée catalogs) / Catalog Owner (1 catalog précis) / Access Package Manager (1 package précis) - Catalog Owner doit être owner de la ressource pour l'ajouter -EM approbation: Aucune / Simple (manager/user/sponsor) / Multi-stage -Expiration: durée fixe / never / access reviews - portail user myaccess.microsoft.com -Entra ID Governance (add-on payant, exige P2): Lifecycle Workflows + EM/Access Reviews avancés + ML recommendations (≠ P2 de base) -Access Reviews (P2): revue périodique des accès (rôles, groups, packages, guests) -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É - nouveaux VNets créés via API APRÈS 31 mars 2026 = subnets PRIVÉS par défaut, plus d'accès sortant implicite; VNets existants non impactés) - 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 -default outbound: AllowVNetOutBound (65000) / AllowInternetOutBound (65001) / DenyAllOutBound (65500) -default inbound (non supprimables): AllowVNetInBound / AllowAzureLoadBalancerInBound / DenyAllInBound -règles processed par priorité ASCENDANTE (100 traité avant 4096) - first match wins -trafic intra-VNet TOUJOURS autorisé par défaut entre subnets du même VNet (sauf règle DENY explicite) -NSG sur subnet ET NSG sur NIC → trafic doit passer LES DEUX -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) -ASG: regroupement de NICs MÊME VNet (même région), utilisé dans règles NSG (source/dest) - PAS de nesting - 1 NIC peut être dans plusieurs ASG -Service Tags: plages IP de services Azure gérées par MS, auto-update (Storage, Sql, AzureKeyVault, AzureBackup, etc.) - PAS de Service Tag custom -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 -limite: 500 peerings max/VNet → au-delà = Virtual WAN (transitivité native) -Disconnected (1 lien supprimé) → delete + recréer les 2 côtés -Disconnected ou LocalNotInSync après modif address space → Peering > Sync (pas de delete) - ne pas confondre -désactiver "Allow VNet access" = aucun trafic VM↔VM dans les 2 sens (cas: peering uniquement pour gateway transit) - blocage 1 sens = NSG pas peering -gateway sharing: "Allow gateway transit" côté HUB (partage VPN GW) + "Use remote gateways" côté SPOKE -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 -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 - BGP obligatoire -billing: Metered (forfait + trafic sortant) / Unlimited (fixe) / Local (moins cher, régions proches) -variantes: Direct (sans partenaire 10/100G) / Global Reach (interconnecte 2 sites onprem) / FastPath (bypass GW pour latence) -Service Endpoint Policy (optionnelle): restreint le Service Endpoint à des comptes Storage spécifiques -Resource public network access (Storage/SQL/KV): Disabled (PE only) / Selected VNets+IPs / All networks - PE marche même si public disabled -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 Link Service (côté PRODUCER): expose TON service à des clients tiers via Standard LB privé - eux créent un PE chez eux vers ton alias (CIDR overlap clients OK) - activer Proxy Protocol v2 pour vraie source IP - max 8 frontend IPs, 1000 PE/LB -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 -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: 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 / Basic ~250Mbps pas d'IDPS -Policy (héritable parent→enfant) > Rule collections: DNAT rules (inbound forward) / Network rules (L3-L4 IP/port) / Application rules (L7 FQDN/FQDN tags/web categories) - priority 100-65000, default Deny -FQDN Tags (Standard+): WindowsUpdate, AzureKubernetesService, etc. (équiv L7 des Service Tags) -Threat Intel modes: Off / Alert only / Alert and deny -TLS inspection (Premium): KV + cert root + Managed Identity du firewall -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é -Run Command: exécution interactive PS/Bash sans RDP/SSH (via Agent VM) - recommandé ops ad-hoc / cloud-init = Linux 1er boot via customData / CSE = post-deploy one-shot -Spot eviction TYPE: Capacity only (Azure récupère capacité) / Capacity or Price (aussi si prix > max) - eviction POLICY: Deallocate (garde disks) / Delete (cleanup) - max price -1 = jusqu'au PAYG -AS FD/UD ARM: platformFaultDomainCount / platformUpdateDomainCount - si FD=1 alors UD=1 obligatoire / "2 VMs dispo pendant maintenance planifiée" → UD≥3 -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 - mode immuable (figé à création) -autoscale profiles priorité: dates spécifiques > jours récurrents > default / multi-rule scale-out: la règle qui ajoute LE PLUS de VMs gagne -CSE dans VMSS = déclarer l'extension dans extensionProfile du template → chaque nouvelle instance l'exécute auto au scale-out -Trusted Launch (Gen2 only): Secure Boot (refuse code non signé) + vTPM (TPM 2.0 virtuel) + Boot Integrity Monitoring - prérequis Confidential VMs (AMD SEV-SNP / Intel TDX) -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 -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), PAS GPv1, PAS BlobStorage legacy -GRS + RA-GRS dispo GPv2 + GPv1 + BlobStorage (pas Premium) -GZRS + RA-GZRS dispo GPv2 UNIQUEMENT -"ZRS sur GPv1" → IMPOSSIBLE, upgrade en GPv2 d'abord -"lecture région secondaire SANS failover" → RA-GRS (pas GRS simple qui n'expose pas le secondary endpoint) -"GRS sur Premium Block Blob" → IMPOSSIBLE, utiliser Object Replication à la place -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 1-15h) -early deletion fee si suppr avant min retention -Types blobs: Block Blob (fichiers/backups, le + courant) / Append Blob (logs append-only, PAS de tiers→delete only) / Page Blob (disques VM non managés, random R/W) -Blob Index Tags: clé-valeur indexées au SA (max 10/blob), recherche cross-container, utilisables en lifecycle/SAS - GPv2+Premium Block, PAS avec HNS - rôle Storage Blob Data Owner ou Tag Contributor -Last-Access Time Tracking: à activer sur SA pour règles lifecycle daysAfterLastAccessTime (sinon condition jamais évaluée) - maj lastAccessTime max 1x/24h -Static website: $web container, endpoint .z??.web.core.windows.net -Lifecycle Management: policy automatique pour move blob entre tiers ou delete selon âge/modification -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 - MAX 5 par container/share/queue/table (au-delà = HTTP 400) -Shared Key (Access Keys): 2 clés primary/secondary, accès COMPLET au SA - désactiver "Allow Shared Key access" recommandé (si compromise = full access) -Point-in-time restore blob: nécessite versioning + change feed + soft-delete activés -NetApp Files hiérarchie: NetApp Account → Capacity Pool (4-500 TiB, service level fixé ici) → Volume - subnet délégué Microsoft.NetApp/volumes obligatoire - protocoles NFSv3/4.1/SMB/dual -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: 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) -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 -modes: Require authentication (refuse anonyme, redirige provider) / Allow unauthenticated (passe + inject claims) -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) -levels (du moins au plus verbeux): Disabled < Error < Warning < Information < Verbose -niveau Warning recommandé pour storage long-terme (Blob illimité) - PAS Information trop large, PAS Verbose qui log tout -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) / Run From Package (mount .zip read-only, rapide) - slots = blue-green deployment - Deployment Center = blade unifiée -Static Web Apps (service SÉPARÉ): sites statiques (SPA) + APIs Functions intégrées + CI/CD GitHub natif + preview par PR + CDN global - SKU Free (100GB/mois) / Standard (custom auth, PE, SLA, BYOF) - staticwebapp.config.json (routes/auth) -Access restrictions (INBOUND): whitelist IP/VNet/Service Tag, allow-deny par règle par slot, évalué avant le code - PE pas sur les slots (prod only) -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) -auth: Admin user (legacy déconseillé) / Service Principal / Managed Identity (recommandé) / Entra ID + Azure RBAC (rôles AcrPull, AcrPush, AcrDelete) -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) -SKU modifiable à chaud - mais Premium → Standard/Basic exige d'abord supprimer geo-replications + private endpoints - repository-scoped tokens (Premium) -ACI (Azure Container Instances): containers SIMPLES sans orchestration, pay-per-second, démarrage rapide -2 modes: PUBLIC IP avec DNS name label (FQDN ..azurecontainer.io) OU PRIVÉ dans VNet (IP privée seulement, PAS de FQDN public) -restart policy: Always / OnFailure / Never - Hyper-V isolation par défaut -Container Groups: plusieurs containers sur MÊME host (partagent network + storage local), ~équivalent d'un pod K8s - TOUS containers du group = MÊME OS (Linux OU Windows, PAS de mix) - 4 images mix Linux+Windows = besoin de 2 groups séparés -storage persistant: mount Azure File Share UNIQUEMENT (pas de volume natif type emptyDir persistant) -use cases: jobs ponctuels / batch / dev-test - PAS d'autoscale, PAS de rolling update, PAS de HA native -ACA (Azure Container Apps): containers serverless managés (built on AKS + KEDA + Dapr + Envoy) - tu déploies un container sans gérer K8s -environment = cluster (1 env = 1 VNet + 1 LAW) / Revision = version immutable / type environment FIGÉ à création (Consumption ↔ Workload profiles = recréer) -features clés: SCALE TO ZERO (économie), scaling HTTP-based ou event-driven (KEDA: queue, Event Hub, etc.), Ingress interne OU externe (HTTP/TCP), Dapr microservices natif, Revisions (blue-green), VNet integration possible -subnet sizing: Workload profiles env = /27 minimum / Consumption-only env = /23 minimum (si /27 absent du QCM → prendre le suivant immédiat /26) -AKS (Azure Kubernetes Service): K8s managé - control plane GRATUIT, tu paies les nodes / SKU Free (no SLA) ou Standard (99.95% SLA control plane) -Node Pools: System (kube-system, OS Linux, min 1 node, taints CriticalAddonsOnly) + User (workloads, Linux ou Win, autoscale) -Networking modes: Kubenet (legacy, pods NATés, RETIRÉ 31 mars 2028 → migrer CNI Overlay one-way) / Azure CNI (chaque pod = IP du subnet, gros subnet) / Azure CNI Overlay (pods réseau séparé, économise IPs, recommandé MS) / Cilium (eBPF) -scaling: HPA = scale les PODS (nécessite Metrics Server, installé par défaut) / Cluster Autoscaler = scale les NODES / VPA = ajuste CPU/RAM des pods - "scale les pods" → HPA -auto-upgrade channels: none / patch / stable / rapid / node-image - control plane et nodes upgradés séparément -Storage: Azure Disk = ReadWriteOnce (1 node à la fois) / Azure Files = ReadWriteMany (multi-nodes) -Auth: Local K8s accounts OU Entra ID integration + Azure RBAC for Kubernetes (recommandé) -Ingress: AGIC (App Gateway Ingress Controller, managé) / NGINX / Traefik - TLS via cert-manager + Let's Encrypt ou Key Vault -Web App for Containers: App Service héberge ton image container (depuis ACR ou DockerHub) - mêmes features App Service (slots, scale, custom domain, SSL managé), Linux UNIQUEMENT -TLS par service: ACR = HTTPS par défaut / ACI = TLS DOIT être géré dans ton container (pas natif) / ACA = TLS built-in au niveau Ingress (managed cert auto) / AKS = via Ingress Controller + cert-manager / Web App for Containers = TLS managé par App Service -Choix container AZ-104: job ponctuel/batch → ACI / microservices serverless avec scale-to-zero → ACA / orchestration complexe + custom → AKS / image dans App Service ecosystem → Web App for Containers

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 -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 -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 -distribution: 5-tuple hash (default) / Source IP affinity 2-tuple (Client IP) ou 3-tuple (Client IP+Protocol, sticky) / HA Ports (Standard, tous ports, pour NVA active-active) -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) -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 -subnet: DÉDIÉ /24 recommandé (/27 min) - listener + routing rules (basic ou path-based) + backend pool + HTTP settings - Standard/WAF v1 RETRAITE 28 avril 2026 → v2 -mode INTERNE (Frontend IP privé) = ILB L7 pour apps LOB internes (VNet/peered/onprem via VPN-ER) sans expo publique -features: SSL termination + end-to-end re-encrypt / multi-site (host header) / rewrite headers-URL / cookie affinity / HTTP→HTTPS redirect / WebSocket + HTTP/2 -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 -SKUs: Standard (CDN + DDoS Standard) / Premium (+ WAF Managed Rules + Private Link to origin + bot protection) -+ Private Link (Premium): atteindre backend privé (App Service PE, Storage PE, ILB) sans l'exposer publiquement + approval workflow -archi: Endpoint (azurefd.net) → Origin group (pool) → Origin (backend) → Route (pattern → origin group) -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 -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: Developer (gratuit partagé, 1 conn, dev) / Basic (2 instances fixes, ~20 RDP/40 SSH par instance, pas de scaling) / Standard (host scaling 2-50, native client, file copy, IP-based, shareable links) / Premium (+ session recording, private-only) ->40 RDP simultanés: 1) upgrade Basic→Standard (IRRÉVERSIBLE) 2) increase instance count (~20 RDP/instance) - auth Entra ID (rôles VM Administrator/User Login) ou local -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 - 6 niveaux sous root, Tenant Root Group créé auto - 1 sub = 1 MG à la fois -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 -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) -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é) -Budgets: scope Sub/RG/MG/billing - période monthly/quarterly/annually - type Cost (€) ou Usage - 5 niveaux d'alerte - N'ARRÊTE RIEN (alerte seule, stop = Action Group → Logic App/Function) -Advisor: recommandations sur 5 piliers - Cost / Security / Reliability / Operational Excellence / Performance - identifie idle/unattached disks, VMs sous-utilisées, reservations à acheter, etc. -scope: Advisor > Configuration > Resources → décocher RG/subs pour cibler (PAS Cost Management, PAS Billing Admin role, PAS Monitor log query) -disques non attachés / VMs idle / reservations: visibles dans Advisor > Cost recommendations (PAS dans Cost Management qui 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 / Manual (attestation humaine) -remediation (Modify/DINE): n'agit que sur NOUVELLES ressources - existantes = Remediation Task (Managed Identity sur assignment requise) -exemptions: Waiver (accepté tel quel) ou Mitigated (compliant via autre moyen) + justif + expiration / compliance scan ~24h (états Compliant/Non-compliant/Conflict/Exempt) -Initiative (Policy Set): groupe de policies (ex: ISO 27001, NIST) - assigne en bloc avec paramètres -compliance: Compliance dashboard dans Policy > scan régulier (24h) - state Compliant/Non-compliant/Exempt -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 -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 -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 -Key Vault objets: Secret (string chiffrée) / Key (RSA/EC/sym) / Certificate (X.509, auto-renew) - SKU Standard (software) / Premium (HSM FIPS L2) / Managed HSM (FIPS L3 single-tenant séparé) -access models: Vault Access Policy (legacy) vs Azure RBAC (rôles standards, scope par secret/key) - depuis API 2026-02-01 nouveaux KV = RBAC par défaut / API control plane 2026-02-01 retirées 27 fév 2027 -rôles data plane: Administrator (full data) / Secrets Officer (RWD) / Secrets User (R) / Crypto Officer-User / Certificates Officer-User / Purge Operator - Owner/Contributor = control plane PAS accès data en mode RBAC -Soft-delete: 7-90j (default 90), TOUJOURS activé non désactivable depuis 2020 / Purge protection: optionnel, IRRÉVERSIBLE une fois ON (même GA ne peut purger) -networking: Public/Selected/Disabled + PE + "Trusted Microsoft services" (laisse passer Disk Encryption/Backup même firewall ON) -Cloud Shell: Bash/PS navigateur, auth auto (pas az login), Storage Account requis pour persistance (clouddrive 5GB), timeout 20min inactivité, outils pré-installés (az/kubectl/terraform/bicep) -Azure Resource Graph: requête KQL sur l'ÉTAT (config) des ressources cross-sub (inventaire) - ≠ Log Analytics (interroge logs) - az graph query

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) - NON modifiable une fois un item protégé -Vault redundancy & immutable: Immutable Vault (Enabled = désactivable / Locked = irréversible) anti-ransomware - MUA (Multi-User Auth via Resource Guard) = double approbation ops critiques -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 -détails: auth = vault credentials file + passphrase de chiffrement (chiffré côté client, MS ne lit pas) - PERDRE la passphrase = backups irrécupérables (stockable en Key Vault) - 3 backups/jour max, retention jusqu'à 99 ans -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 -Backup Policy VM: frequency Daily/Weekly/Hourly (Enhanced) + retention GFS (daily/weekly/monthly/yearly) - Standard = 1×/jour RPO 24h, Enhanced = jusqu'à 4×/jour RPO 4h (6 snapshots/j) -File Recovery (item-level VM): download script → mount recovery point comme drive → copier fichiers -Cross Region Restore (CRR): restore depuis région secondaire (vault GRS requis) - utile si région primaire down -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 -opérations: Failover (planifié ou unplanned) / Test Failover (DR drill sans impact prod) / Reprotect (resync après failover) / Failback (revenir primaire) -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) -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 / AMA - Metrics Explorer + multi-resource + Splitting (par dimension, ex CPU par VM) -Log Analytics Workspace (LAW): conteneur des logs, retention 31j gratuit (jusqu'à 730j payant + archive 12 ans, queries via Search Jobs/Restore) - tables typiques: AzureActivity, AzureDiagnostics, Heartbeat, Perf, Syslog, Event, AppRequests - query KQL (where / summarize / project / top / join / extend) - pricing PAYG ou Commitment Tiers -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) -Alert state: New→Acknowledged→Closed (manuel) / Monitor condition: Fired/Resolved (auto) -Action Groups: actions exécutées par alerts - Email/SMS/Voice / Push mobile / Azure Function / Logic App / Webhook / ITSM / Runbook / Event Hub - 1 AG réutilisable sur N alertes -Alert Processing Rules: modifient comportement global des alertes (Suppress pendant maintenance / Apply Action Groups) - scope sub/RG/type - NOTE: Service Health alerts ne supportent PAS les Alert Processing Rules -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+ACA metrics + logs) -Network Insights (vue centralisée TOUS network resources sans agent, recommandé pour 100s de ressources) -Storage Insights / SQL Insights -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 -Profiler: trace les REQUÊTES LENTES dans web app (call stack + temps par fonction) - PAS Activity Log, PAS Network Watcher pour ce cas -Agent (auto-instrumentation, ZÉRO code change) vs SDK (code requis, custom events) - "monitor perf minimal code changes" → Agent -Smart Detection: anomalies ML auto sans seuil manuel -DDoS: Infrastructure Protection (gratuit auto sur toutes Public IPs) / Network Protection (scope VNet, payant) / IP Protection (scope 1 Public IP, payant) -Network Watcher: outils diag réseau par région - activé auto par région à la première ressource réseau -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/18000s, fichier .cap PCAP, nécessite Network Watcher extension) -NSG Diagnostic: affiche toutes les règles s'appliquant à une NIC (successeur Effective Security Rules) -Topology: carte visuelle VNet / VPN Troubleshoot: diag VPN Gateways -NSG Flow Logs RETRAITE 30 sept 2027 (création bloquée 30 juin 2025) → migrer vers VNet Flow Logs (capture niveau VNet, plus complet) - Connection Monitor Classic retiré 29 fév 2024 -Traffic Analytics prérequis (3): NSG/VNet Flow Logs + LAW + DCR - permissions Network Contributor+ - PAS Sentinel/Policy/Alerts -KQL search: search in (Table) "error" (ciblé rapide) vs search "error" (toutes tables, lent) -exemples: AzureActivity | where OperationNameValue contains "delete" / Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer -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

PIÈGES EXAM (À RELIRE 5 MIN AVANT - tes pièges récurrents) -Network Watcher: bloque? → IP Flow Verify (nom règle) / 1 fois? → Connection Troubleshoot / tout le temps? → Connection Monitor / logger? → NSG Flow Logs / visualiser? → Traffic Analytics / où va le trafic? → Next Hop / paquets PCAP? → Packet Capture (max 5h) -CA Grant vs Session: MFA + device compliance = TOUJOURS Grant / "fréquence reconnexion" ou "browser persistence" = Session -NSG: priorité ASCENDANTE first-match-wins, intra-VNet autorisé par défaut, subnet ET NIC doivent passer les deux, auto-règle = Policy DeployIfNotExists/Modify (pas manuel, pas Flow Logs) -Storage replication: ZRS impossible sur GPv1 (upgrade GPv2) / lire secondaire sans failover = RA-GRS / GRS sur Premium Block Blob impossible = Object Replication / GZRS = GPv2 only -Cross-region/Move/Redeploy: Move VM cross region IMPOSSIBLE natif (Resource Mover/ASR/recreate) / Redeploy = autre host physique MÊME région / change VNet = recréer VM / change subnet même VNet OK via NIC -Service Endpoint vs Private Endpoint: onprem ou cross-region → Private Endpoint / subnet Azure local + gratuit → Service Endpoint -Mots-piège MS à souligner: "LEAST effort/MINIMUM cost/MINIMIZE downtime" → solution la plus simple (managé > custom) / "FIRST/NEXT step" → ordre exact / "without admin effort" → built-in > custom / "single point of failure/HA" → AZ > AS > single VM / "all regions/global" → Front Door/Traffic Manager/Cosmos (pas LB régional) / "on-premises" → vérifier Private Endpoint / "multi-tier + internal" → Internal LB / "multiple subscriptions + policies" → Management Group scope / "audit compliance" → Policy Audit ou NSG Flow Logs ou Activity Log / "block creation if" → Policy Deny -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)

TABLE STORAGE (note à compléter) -Key-value store simple intégré Storage Account, schemaless

STREAM ANALYTICS (note à compléter) -SQL-like sur streams en quasi temps-réel, no-code, simple