APP SERVICE & PLANS
-PaaS web apps/APIs, runtimes managés (.NET, Java, Node, Python, PHP, container)
-Plan = capacité (VMs sous-jacentes), N apps partagent un plan
-SKU: Free/Shared (dev) / Basic / Standard / Premium v3 (autoscale, slots, zone-red) / Isolated v2 (ASE, compliance, max 200 instances)
-Slots (Std+) pour blue-green deploy + swap rollback, max 5 Std / 20 Pv3 / 20 Iv2
-Always On obligatoire si trigger non-HTTP attendu
-Custom domain + cert TLS (KV import), HTTPS only, MI à activer pour KV/SQL
-Hybrid Connections = atteindre TCP host:port onprem sans VPN (445/Relay 443 out)
-VNet integration (sortant vers VNet) vs PE (entrant depuis VNet)
-HA: zone-redundant (Premium v3+ à création), DR: FD/TM + 2 régions
AZURE FUNCTION
-Code exécuté en réponse à un trigger, binding avec d'autres services (ex: lire blob, envoyer vers queue)
-Sécu HTTP Trigger (authLevel): anonymous (endpoint public, healthcheck), function (function/host key), admin (master key)
-Rajouter couche d'auth: EasyAuth (Entra/OIDC, +certificat possible)
-Hybrid Connections (Azure Relay): agent HCM onprem sort 443 vers Azure, communique host:port - 1 endpoint, sans VPN
-SKU: consumption (legacy, no vnet), flex consumption, premium (low latency, no cold start), dedicated (asp)
-Slot en Premium/Dedicated pour v1/v2 + rollback (swap)
-HA: zone redundant (default Flex, option création sinon - irréversible ; sauf consumption legacy)
-DR: pas natif, frontdoor/traffic manager + 2 funapp ; data à géo-répliquer
-Monitoring: App Insights
ASE (App Service Environment v3)
-Déployé dans VNET, isolé single-tenant, cher, compliance extrême, max 200 instances (rentable 20+ apps)
-ILB (interne) ou ELB (externe) pour inbound, SKU = Isolated v2 only
-HA: zone redundancy à la création, IRRÉVERSIBLE (min 3 instances)
-DR: pas natif, frontdoor/traffic manager + 2 ASE (cher)
AZURE BATCH
-Jobs parallèles grande échelle (ML, rendering)
-Batch Account > Pool (N VM) > Job (N) > Tasks
-Prix: Spot pour batch tolérant interruption, sinon dedicated, mix possible (garantir min + économiser)
-Embarrassingly parallel: tasks indépendantes > VM D/F/NC
-Tightly-coupled (MPI): tasks liées > VM HB/HC/ND + PPG/InfiniBand (CFD/FEA, training distribué)
CYCLE CLOUD
-Orchestration cluster HPC (Slurm, PBS, LSF, HTCondor): réutilise scripts HPC onprem sans réécrire
-Migrer HPC onprem sans toucher code (sbatch, qsub) + burst hybride
-Lift and shift HPC (vs Batch = greenfield Azure-native)
VOCAB HPC
-Multi-instance task: 1 task sur N nodes > MPI
-InfiniBand/RDMA: réseau ultra basse latence > requis tightly-coupled (avec PPG)
-Azure Managed Lustre (AMLFS): parallel file system gros HPC
CONTAINER/KUBERNETES BASE
-Cluster Kube (AKS = 1 cluster, control plane managé MS)
-Node Pool (VMSS) > Node (VM) > Pod (X containers)
-Deployment: manage N pods identiques
-Service: IP/DNS qui expose N pods (pods changent, service reste), Ingress = routing HTTP/S > Service
ACR
-Registry managé, distribue images vers AKS/ACA/ACI/WebApp Container
-ACR Task: build server-side (sans docker) - quick, trigger ou multi-step
-SKU: Basic (10gb), Standard (100gb), Premium (100TB + multi-region geo-rep + private endpoint + content trust)
-Désactiver Admin user, utiliser MI + AcrPull
ACI
-1 container ou 1 group (group = même OS ; Windows = mono-container, multi = Linux only)
-Restart policy: Always (défaut) / OnFailure / Never (job one-shot = OnFailure/Never sinon boucle)
-Virtual Nodes (burst AKS vers ACI): Azure CNI obligatoire + subnet dédié ACI + Linux only
-Public/Privé (VNET)
-Pr ponctuel/one-shot, agents CI/CD éphémères, burst AKS - PAS scale-to-zero, PAS long-running (ACA mieux)
AKS NETWORKING
-Kubenet: pods IP hors VNET, économise IP, NAT sortie, UDR routage > ~400 nodes max, legacy, Linux only
-Azure CNI flat: pods IP du VNET (routable direct, bidir peered/onprem) mais consomme bcp IP
-Azure CNI Overlay: pods IP hors VNET (économise), encapsulation (pas UDR) > scale énorme, moderne, Windows OK
-Seul CNI flat rend pod joignable DIRECTEMENT ext ; Kubenet/Overlay = inbound via Service only
-Virtual Nodes (burst ACI) > Azure CNI obligatoire + Linux only
-Service interne: ClusterIP ; Service ext: Azure LB Standard + Public IP
-NSG (subnet/nodes) ET Network Policy (pod-to-pod) = 2 couches complémentaires
-Network Policy (créa only): NPM (L4 MS CNI only) / Calico (L4 marche Kubenet) / Cilium (L7)
-Ingress: NGINX (pods cluster) ou AGIC (App Gateway + WAF, prod)
-Outbound: NAT Gateway (évite SNAT exhaustion prod gros traffic), UDR (firewall sortant) ou LB (dev/test)
-API Server: public, private endpoint, ou VNET integration (vit dans subnet, pas DNS à gérer, + rapide, pas coût PE)
AKS STORAGE
-Volume éphémère (pod) ou Persistent Volume (PV, indépendant pod, survit)
-Storage Class = modèle stockage Azure, AKS provisionne PV auto
-PVC = pod commande X Gi dans Storage Class
-Partagé > Azure Files (RWX) ; non partagé > Disk (RWO) ; gros fichiers > Blob ; perf HPC > NetApp Files
-RWO = 1 node à la fois, Disk = LRS épinglé 1 zone (cross-AZ > Storage Class ZRS)
AKS AUTOSCALE
-HPA: scale pods (replicas), trigger CPU/RAM
-Cluster Autoscaler: scale nodes (VMSS), trigger pods pending. HPA crée pods > CA crée nodes si manque place
-VPA: ajuste sizing pods (CPU/RAM requests)
-KEDA event-driven: trigger Service Bus/Storage Queue/Kafka, AVANTAGE scale-to-zero + métrique métier (HPA = min 1 pod CPU/RAM only)
-Pools: system (défaut, AKS components, Linux, ni 0 ni Spot ni suppr), user (apps), spot (-90%, éviction)
AKS IDENTITY SECU UPDATE HA/DR
-2 questions séparées: pod accède Azure = Workload Identity / humain pilote = Entra + RBAC
-Workload Identity: pod = identité Entra sans secret (= MI, à activer création)
-Auth cluster: compte local déconseillé, Entra + Azure RBAC recommandé
-Network: PE sur API server, whitelist authorized IP si public, NSG subnet
-Image: Defender for containers (scan + runtime), image cleaner, ACR Content Trust
-Update: control plane auto, node pools auto-upgrade channel + rolling max surge
-HA: zones --zones 1 2 3 à la création + storage ZRS séparément
-DR: 2 clusters + frontdoor/traffic manager, data géo-répliquée, PV via Azure Backup for AKS
AZURE ARC-ENABLED K8S
-Projeter clusters K8s hors Azure (EKS, GKE, on-prem, edge) comme ressources ARM dans Azure
-Applique RBAC, GitOps (Flux), Azure Policy, Defender for containers, Monitor de façon UNIFORME via portail Azure
-Pour magasins multi-locations, edge K8s, multi-cloud governance
-Distractors: Azure Stack Hub (full stamp on-prem, lourd), AKS (managé Azure only, ne couvre pas multi-location)
AUTRES AKS/ACA
-Dapr: boîte à outils microservices (sidecar) pour plomberie sans coder. Natif ACA (toggle), à installer AKS
-Service Connector: connecte app (ACA/AKS/WebApp/Function) à ressource Azure (SQL/Cosmos/Storage/KV) en 1 commande (crée MI + RBAC + config)
-ACA: serverless microservices (K8s caché), KEDA + Dapr intégrés, scale-to-zero natif, revisions immutables (blue-green/canary), PAS StatefulSet (stateful > AKS)
KEYVAULT
-Secret (string), keys (rsa/ec), certificates (x.509), auth RBAC idéalement MI
-SKU: Standard (FIPS lvl2) vs Managed HSM (KEYS ONLY, single-tenant, FIPS lvl3)
-Soft-delete 90j default, purge protection (obligatoire prod)
-PMK/MMK: MS gère / CMK: je gère dans KV / BYOK: j'importe
-DEK (Data Encryption Key) = chiffre DONNÉES, AES-256 (symétrique)
-KEK (Key Encryption Key) = wrappe DEK, RSA, ma clé KV = le CMK
-Tailles: mini RSA 2048 partout, SQL TDE = 2048/3072 (PAS 4096), Confidential VM = 3072 mini
-Storage: DEK AES256 wrappée KEK RSA dans KV
-Managed Disk SSE: DEK AES256 wrappée KEK via Disk Encryption Set
-SQL TDE: DEK (Database Encryption Key) wrappée TDE Protector RSA dans KV
-SQL Always Encrypted: CEK (Column Encryption Key) wrappée CMK = Column Master Key dans KV (CMK ici = Column Master pas Customer-Managed)
MANAGED IDENTITIES
-Identité Entra pr ressource Azure SANS secret stocké (token auto rotaté)
-System-assigned: lifecycle = ressource (delete VM = delete MI), 1 par ressource
-User-assigned: standalone, partageable sur N ressources (+ flexible)
-Workflow: MI sur ressource (App Service/VM/Function/AKS) > rôle RBAC sur cible (KV, SQL, Storage) > zéro secret stocké
-AKS: Workload Identity (pod = identité Entra via Federated Creds, à activer création) > remplace pod-identity legacy
-Federated Credentials (OIDC) = GitHub Actions / GitLab CI / DevOps sans secret, MI fédérée échange OIDC token
-SP avec secret = legacy à éviter (rotation à gérer, KV obligatoire)
PIM (PRIVILEGED IDENTITY MGMT)
-P2 requis, just-in-time activation rôles privilégiés Entra/Azure RBAC
-Eligible (à activer) vs Active (permanent dangereux)
-Activation: justification + MFA + approbation optionnelle + durée max (1-8h)
-Access Reviews + audit logs intégrés
-Pour Global Admin, Owner, Contributor sensible: tjr Eligible PIM, jamais Active permanent
CAE (CONTINUOUS ACCESS EVALUATION)
-Entra invalide les tokens en QUASI TEMPS-RÉEL sur événement critique (user disabled, password change, IP change, MFA fail, risk elevated)
-Via CAEP protocol push IdP > apps révoquent session instantanément (sans attendre expiration token ~1h)
-Distractors: MFA (auth initial only), Conditional Access (évalué à l'auth pas en cours session), OIDC (protocole, pas enforcement)
AUTH ENTRA
-PHS: Password Hash Sync, hash mdp synchro Entra (recommandé MS)
-PTA: Pass Through, mdp jamais cloud, Entra demande vérif AD
-ADFS: auth déléguée onprem (legacy)
EXTERNAL ID
-B2B Collab: invite partenaires (guest users)
-B2B Direct Connect: tenant to tenant, Teams shared channels, c'est tout
-External ID for customers (ex-B2C): customer grand public
-App SaaS tierce: Enterprise app
QUEUE STORAGE
-Messagerie simple, 64KB/msg, 500TB/queue, REST
-Async, consommateurs pochent (polling 30s style), ordre non garanti, no FIFO best effort
-At-least-once, PAS DLQ, PAS duplicate detect, PAS sessions, PAS transactions atomiques
-Visibility Timeout lease: worker lit msg, msg invisible 30s default (max 7j), worker plante msg réapparaît (ordre peut être cassé). Worker peut prolonger bail
-Transaction log SERVER-SIDE oui (toutes opérations queue: lecture/suppr msg, log time+ip)
-Choisir Service Bus si: FIFO garanti, doublon detect, transactions atomiques, DLQ, pub/sub, msg >64KB (inf 1MB)
-Buffer simple, queue job long durée, PAS commerce/banque
SERVICE BUS
-Broker queue + topics, fiabilité, transactions, routage
-256KB (Premium 100MB), 80GB max queue, FIFO garanti, transac, DLQ, dupli detect
-Push style API, sub rattachées à un topic (1 msg topic > N sub, chaque sub son filtre+fonction)
-Namespace contient queue+topic (endpoint monapp.servicebus.windows.net), définit capacité/scale/AZ
-Queue avec stockage redondant si zone enabled, 1 producer = 1 consumer
-Topic + N sub avec filtres SQL/Correlation/Boolean broker-side
-Features: autoforwarding (chaîner queue/topic pipeline cascade), scheduled delivery (msg à T précis), msg deferral (mettre côté revenir plus tard, diff DLQ car pas erreur), duplicate detection (MessageId fenêtre)
-Geo-DR Premium (RPO ~15min, alias DNS, failover manuel), PAS de réplication des messages en attente (juste structure queues/subs/filters)
-Tier: Basic (queues only PAS topics), Standard (queues+topics+subs+sessions partagé), Premium ⭐ (dedicated MU, VNet, JMS 2.0, Geo-DR, CMK, 100MB)
-Sessions vs Partitioning: Sessions = FIFO garanti par session key (ordre par clé, parallèle entre clés) / Partitioning = distribuer N stores pour throughput (PERD l'ordre global). FIFO order > Sessions JAMAIS Partitioning
EVENT GRID
-Routage event sur Azure Service Fabric (Msg=donnée complète vs Event=notif/ref)
-Pub/sub push delivery, latence ms, at-least-once, retry policy 24h sinon DLQ
-Non FIFO, DLQ, filtering, geo DR, AZ
-4 types topics: System (services Azure publient), Custom (mes apps), Partner (SaaS extn), Domains (multi-tenant SaaS, jusqu'à 100k sub-topics)
-Event handler: Functions, Logic Apps, Webhook, Service Bus, Storage Queue, Event Hubs
-Filtre subject/type/advanced, expiration (ex: blob conteneur X)
-Fan out: distribuer event à N sub (upload blob > resize + thumbnail + ...)
-Push (défaut) ou Pull (Namespaces mode + MQTT broker IoT)
-Payload 1MB max, PAS de filtre SQL avancé broker-side (subject/type only) - pour SQL filter complet > Service Bus Topic
EVENT HUBS
-Journal log distribué gros volume vitesse, pipeline ingestion data milliers producers/consumers, stream massif
-Namespace (management plane + réseau) > partitions (stockage ordonné, event dans ordre, partition key range bien, offset/checkpoint pour reprise)
-Nbr partition = nbr consumer max par consumer group
-Standard PAS de changement nbr partition (figé à la création) ; Premium/Dedicated oui
-Scaling TU (Standard 1MB ingress / 2MB egress, max 40), PU (Premium ram/cpu isolé), CU (Dedicated physique réservé)
-Event Hub Capture: archive stream vers Blob/ADLSv2 (Avro/Parquet)
-Kafka compat (migration sans réécrire code)
-SKU: Basic (1cg, 1j rétention, 32 part, TU, 256KB) / Standard (20cg, 1-7j, 32 part, TU, kafka, capture, geo-DR) / Premium (100cg, 90j, 100 part, PU, kafka, capture, VNet/PE, partition dynamique) / Dedicated (∞cg, 90j, 1024 part, CU, tout)
-VNet integration en Premium min
-Logs/SIEM externe temps réel > Event Hub (PAS Service Bus = queue)
APIM
-Façade qui accepte appels API, route vers gateway, configure secu/cache/monitor
-API Gateway (data plane) reçoit traffic, applique policy. Management plane (portal/REST) configure ça. Developer portal pour dev (doc, test endpoint, clés)
-Policy = règles XML par requête: inbound + backend + outbound + on-error
-Secu: JWT (token), IP filter, check-header, subscription key (chaque client a sa clé header), client certificate mTLS (B2B), Entra ID (oauth/oidc)
-Contrôle traffic: rate limit (min/s/h retourne 429), quota (longue durée mois), rate limit by key
-Transfo: set-header (add/modif), set-body, convert json/xml
-Cache pour éviter appel backend inutile
-2 modes: Gateway managed (1 GW par instance APIM, Azure gère) / Self-hosted (containerisé, onprem/autre cloud, Dev tier + Premium only, gère API onprem sans expo internet)
-SKU: Consumption (serverless test), Developer (test stable), Basic (VNet integration prod simple), Standard (Private Endpoint), Premium (SLA, VNet inject, multi-region 12, AZ, self-hosted, workspace, scale unit, cache GB, backup, cher), Standard v2/Basic v2 (modernes)
-Centralise: rate limit/auth/log/erreurs/CORS pour tous les frontends > unifie secu
-Scenario classique: Front Door devant APIM
LOAD BALANCING VOCAB
-L4 (TCP/UDP aveugle contenu) = Azure LB / L7 (HTTP voit URL/headers) = App Gateway / Front Door
-Proxy (LB/AGW/FD = traffic passe par, failover instant) vs DNS-based (Traffic Manager = client direct backend, failover LENT à cause TTL DNS)
-Anycast = 1 IP répliquée N POPs mondiaux, route le + proche (Front Door)
-Health probe (/health), Session affinity (sticky, éviter app stateless), WAF (OWASP, mode Detection puis Prevention)
AZURE LB (L4 RÉGIONAL)
-TCP/UDP ultra rapide, aveugle contenu, PAS WAF/SSL/path routing
-Pour du L4 régional simple
-Cross-region LB = Global tier du Standard LB = L4 GLOBAL (IP anycast, backend = LB régionaux, failover instant) = pendant L4 de Front Door
APP GATEWAY (L7 RÉGIONAL)
-L7 régional: path-based routing, SSL termination (cert via KV), WAF_v2 (OWASP)
-Multi-site (N domaines 1 IP), subnet dédié /27 mini, backend PAS multi-region
-Standard_v2 (sans WAF) / WAF_v2 (avec) ; v1 retire avril 2026
-Pour global > derrière Front Door
TRAFFIC MANAGER (DNS GLOBAL)
-Routage DNS: priority (active-passive), weighted, geographic (data residency), performance (latence), multivalue, subnet
-Marche backends hors Azure (onprem, autres clouds) ET non-HTTP (TCP/UDP, gaming, IoT)
-Failover LENT (limité TTL DNS), PAS proxy donc PAS SSL/WAF/CDN/affinity
-Toujours définir endpoint Default (sinon NXDOMAIN)
FRONT DOOR (L7 GLOBAL)
-LB global L7 anycast (100+ POPs) + CDN/caching edge + WAF + SSL offload
-Routing: latency (défaut), priority, weighted, session affinity
-Standard (LB+CDN+SSL) / Premium (+ WAF Premium + Private Link backend + Bot Manager)
-App multi-region latence optimale ; backend zero-public > Premium + Private Link
-Front Door Classic retire 31 mars 2027
RÈGLE D'OR LB
-Multi-region + L7 + WAF + CDN > Front Door
-Single-region L7 + WAF > App Gateway v2
-Non-HTTP ou backend hors Azure > Traffic Manager
-L4 régional simple > Azure LB Standard
-Combo enterprise: Front Door (global+WAF) > App Gateway (régional) > App/VM (PE) > DB privée
WAF
-Pare-feu L7 HTTP/S, bloque OWASP (SQL injection, XSS, RCE, bots, credential stuffing)
-Règles managées: OWASP CRS (standard) / Microsoft DRS (MS, auto-update)
-2 modes: Detection (log, tuning 1-2 sem) puis Prevention (bloque, prod)
-App Gateway WAF v2 = RÉGIONAL (VNet), body 2MB, file upload 4GB
-Front Door WAF = GLOBAL (edge), body 128KB, Premium = DRS + Bot Manager
-1 policy = 1 service (AGW OU FD), defense-in-depth = FD (edge) + AGW (régional) = 2 policies
-Single-region > AGW WAF v2 / multi-region/edge > Front Door WAF Premium
-DDoS (L3/L4) complété WAF (L7 HTTP flood / rate-limiting)
AZURE FIREWALL POLICY
-Ressource indép. (remplace classic rules), attachable 1 ou N firewalls (ALZ multi-region)
-Hiérarchie: Policy > Rule Collection Group (priority) > Rule Collection (DNAT/Network/Application) > Rules
-Ordre: Threat Intel > IDPS > DNAT > Network > Application (Network AVANT Application: App Allow n'override pas Network Deny)
-Parent/child: SecOps=parent (toujours évalué avant), app teams=child
-Standard (rules+threat intel+DNS proxy) / Premium (+TLS inspection+IDPS+URL filtering), SKU match firewall
-1 policy > N firewalls = règles cohérentes multi-region + sécurité déléguée
DDOS PROTECTION
-Infrastructure (Basic): gratuit, always-on, plateforme Azure
-IP Protection: par IP publique > PME/peu d'IP
-Network Protection: par VNet > entreprise (metrics, cost protection, DRR)
-DDoS = L3/L4, L7 (HTTP flood) = WAF rate-limiting
CONNECTIVITY DESIGN (net new, le reste = AZ-104)
-Topologie: Hub-Spoke (tu construis hub, contrôle total, peu régions) vs Virtual WAN (hub managé MS, transit global auto, branches/SD-WAN) ; Secured Hub = vWAN + Firewall
-Hybride: VPN Gateway S2S (internet/IPsec, moins cher) vs ExpressRoute (privé dédié, latence prévisible, gros débit, compliance no-internet) ; ER+VPN failover ; HA = zone-redundant
-Diag (Network Watcher): onprem↔Azure continue = Connection Monitor (agent onprem) / tunnel VPN = VPN Troubleshoot / test ponctuel = Connection Troubleshoot / routage onprem = Next hop
-Autres: failover multi-sites ER (Global Reach) = BGP / remote workers = P2S (jamais S2S)
SQL/NOSQL BASE
-Relationnel=ACID=SQL=SQLDB/SQLMI
-Non relationnel=BASE=NoSQL=CosmosDB/Table Storage
COSMOSDB
-Multi-region, low latency, plusieurs API: nosql (json), mongodb (bson), cassandra (colonne), gremlin (graph), table (keyvalue), postgresql (relationnel distribué)
-RU/s = monnaie Cosmos (read ~1 RU, write ~5 RU), throughput au niveau Database (partagé) ou Container (dédié, recommandé prod)
-Partition Key = choix CRITIQUE et FIGÉ: haute cardinalité + distribution équitable + dans WHERE (mauvaise PK = hot partition + 429). Limite 20GB/partition logique > Hierarchical PK
-Multi-region: ajout région, multi-write vs multi-region read (multi-write PAS strong consistency), failover automatique avec ordre priorité
-Cohérence: strong (read voit tjr dernier write global, incompatible multi-write, transac financière), bounded staleness (retard borné s, leaderboard temps réel tolérance), session (DÉFAUT, client lit ses propres écritures, shopping panier), consistent prefix (écriture dans ordre mais retard), eventual (ni ordre ni retard, compteur like) [strong/bounded coûtent 2x]
-SKU/throughput: provisioned manuel, autoscale, serverless
-Backup: periodic (2/j, restore via ticket), continuous/PITR (7j default gratuit, 30j payant, self-service)
-Auth: Entra+RBAC / resource tokens / keys (PAS DE SAS, SAS = storage only) ; réseau: Private Endpoint, chiffrement always-on + CMK
AZURE SQL
-SQL DB (nouveau projet) vs SQL MI (migration) vs SQL VM (legacy/contrôle complet)
SQL DB:
-Provisioned ou Serverless
-Elastic Pool: capacité partagée pour N DB
-Geo-Replication pour DR (replica only, failover manuel)
-Sharding: découper DB en plusieurs (help scale)
-DTU Basic/Standard/Premium
-vCore: General Purpose / Business Critical (HA, 3-4 replicas Always On) / Hyperscale (grosse data, jusqu'à 100TB et scale read massif)
-HYPERSCALE EXISTE QUE SUR SQL DB, PAS SUR MI NI VM
-DTU: PAS de Hybrid Benefit
-PAS DE CROSS DB QUERYSQL MI:
-PaaS, seulement General Purpose et Business Critical en SKU
-Cross DB query, SQL Agent, linked server, brokers etc
-Inférieur à 16TB (au-delà utiliser hyperscale donc SQL DB)
-Subnet dédié NON partageable + délégation Microsoft.Sql/managedInstances, toujours dans VNet
-PAS de Geo-Replication comme SQL DB > DR via Auto-failover Group (listener DNS stable, failover auto, SQL DB ET MI)SQL VM:
-Tu gères toute la VM (donc backup aussi)
SECU COMMUNE SQL
-TDE chiffrement repos
-Always Encrypted: chiffré même pour admin
-Row Level Security: filtrage ligne par user
-Dynamic Data Masking: masquer X colonnes
-Auth Entra possible
-Threat protection
MODÈLE DTU VS vCORE
-DTU combine cpu/mémoire en une unité
-vCore: on paye séparément mem + cpu
-vCore 3 modèles: General Purpose, Business Critical (HA), Hyperscale (bcp data)
-DTU/vCore = SQL DB, vCore only = MI, taille VM = SQL VM
-Hyperscale = SQL DB seulement
-Azure Hybrid Benefit: réduc en amenant sa licence (PAS sur DTU)
-Always On Availability Groups si HA sur VM (SQL DB/MI déjà géré Azure)
BACKUP SQL (PaaS vs IaaS)
-SQL DB & MI (PaaS): PITR auto par DÉFAUT (1-35j, défaut 7) + LTR à configurer (jusqu'à 10 ans) + redondance GRS par défaut (LRS/ZRS/GZRS possible)
-SQL VM (IaaS): RIEN par défaut > toi via Azure Backup for SQL VM (PITR/LTR dans Recovery Services Vault)
MYSQL/POSTGRESQL FLEXIBLE SERVER (vs Single Server legacy)
-Flexible = zone-redundant HA + maintenance window custom + stop/start + VNet injection
-Tiers: Burstable (dev, PAS de HA) / General Purpose (prod HA) / Memory Optimized
-Backup redondance: LRS/ZRS/GRS > DR régional = GRS (pas ZRS)
-Mnémo: Burstable = jamais HA
DATA PROTECTION (chiffrement SQL)
-États: at-rest (TDE/SSE) / in-transit (TLS 1.2+) / in-use (Always Encrypted enclaves, Confidential VM)
-Clé: PMK (MS) / CMK (moi dans KV, compliance) / BYOK (j'importe)
-DEK (AES-256, chiffre data) wrappée par KEK/CMK (RSA, dans KV)
-TDE: chiffre FICHIERS at-rest (mdf/ldf/backups), défaut ON, AES-256. Protège vol disque/backup, PAS les DBAs. CMK si compliance (RSA 2048/3072, KV même région)
-Always Encrypted: chiffre COLONNE côté CLIENT (driver), DB ne voit jamais clair > cache aux DBAs/insiders
- Deterministic = même clair > même chiffré > WHERE = ? OK (mais leak fréquence)
- Randomized = + sûr mais AUCUNE query
- Secure Enclaves = queries riches (=,<,>,LIKE,ORDER) sur Randomized via enclave + attestation
-DDM (Dynamic Data Masking): MASQUE à l'affichage (data clair en base) = cosmétique, PAS chiffrement, UNMASK/exempt list voient clair
-Réflexes: vol fichiers > TDE / cacher aux DBAs > Always Encrypted / masquer affichage helpdesk > DDM / mes clés > CMK
-Storage: Stored Access Policy (gérer/révoquer SAS) vs Immutable/WORM (Locked = data non modifiable même par MS, compliance SEC/FINRA)
-Defender for SQL: vulnerability assessment + ATP (SQL injection, brute force)
SAS TYPES
-Account SAS: scope = account entier (multi-services), signé avec storage key
-Service SAS: scope = 1 service (Blob/Queue/Table/File), signé avec storage key
-User Delegation SAS ⭐: signé avec Entra creds (PAS storage key) > révocable via rotation Entra creds, audit who-did-what. Scope 2026 = Blob (incl ADLS), Queue, Table, Files (élargi)
-Stored Access Policy: grouper SAS au container level > révoquer/changer perms SANS rotation storage key (impact massif évité)
-Distractors: RBAC = users Entra pas apps long-terme, ReadOnly lock = bloque modif resource pas contenu, SAS direct sans policy = révocation impossible
AZURE FILES TIERS
-≠ Blob tiers (Hot/Cool/Cold/Archive)
-Premium: SSD, low latency, transactional intense
-Transaction Optimized: HDD optimisé pour transaction-heavy (latence > Premium)
-Hot: HDD général, accès fréquent
-Cool: HDD lowest cost, infrequent access (équiv Cool Blob)
-Question "infrequent + lowest storage cost" > Cool Files (PAS Transaction Optimized qui sert transactions intensives)
ANALYTICS VOCAB
-OLTP = TRANSACTIONS temps réel (sqldb/cosmos), OLAP = analyse gros volume historique (synapse dedicated sql, databricks)
-SMP: 1 machine N cpu partagé (SQL Server) / MPP: N nodes chacun CPU+RAM (Synapse Dedicated SQL pool). 100TB scan > SMP = lent / dedicated pool synapse = parallèle
-Medallion: bronze (raw) > silver (cleansed) > gold (BI-ready), Delta Lake = ACID+time-travel sur Parquet
ADLS GEN2 (data lake)
-Storage Account + HNS activé (vrais folders, ACLs POSIX) > fondation big data (Spark/Hadoop/Databricks/Synapse)
-Renommer/déplacer/suppr = 1 req atomique (sans HNS chaque blob = 1 req), avantageux ACID/atomique pour spark/delta lake/synapse
-Activer HNS À LA CRÉATION (sinon migrer Data Factory ou AzCopy)
-RBAC + ACL POSIX (granulaire qui voit quoi vs RBAC entier conteneur)
-Hiérarchie: /bronze (raw) > /silver (cleansed) > /gold (BI-ready)
-Intégration native: Synapse (srce/dst, serverless SQL lit), Databricks (monte ADLS filesystem), Data Factory (pipeline), Stream Analytics (output), HDInsight (Hadoop natif)
-Endpoint DFS dfs.core.windows.net
-PAS augmente coût vs storage normal
-Driver ABFS (migration Hadoop), data RAW + scale + relationnel ET non-relationnel mélangés > ADLS Gen2
SYNAPSE
-Plateforme analytics intégration, fusionne big data, warehouse, unifie données
-Synapse Studio: SQL pool (serverless/dédié) + Spark pools + pipelines ETL/ELT + intégration ADLS
-SQL Pool Dedicated: PaaS datawarehouse, taille en DWU = coût, requête MPP distribuée sur nodes, PAUSE possible (économies, payé que stockage)
-SQL Pool Serverless: inclus workspace default, exploration rapide ADLS, expose data lake mini warehouse, payé par TB scanné
-Spark Pool: transformation complexe, ML, Delta Lake sur ADLS
-Synapse Pipeline: même moteur que Data Factory, intégré écosystème Synapse
-Data Explorer Pool: real-time KQL/logs
-Synapse Link: Replication realtime Cosmos/SQL vers Synapse (analytics quasi live sur OLTP), MS recommande Fabric Mirroring pour nouveaux projets 2026+
-Secu: managed VNet, PE, Synapse RBAC en + des RBAC Azure, column/row level secu sur Dedicated pool, data masking
-Spark haute perf + ML > Databricks
DATABRICKS
-Apache Spark managé, notebook collaboratif, MLflow, Delta Lake transac ACID, SaaS tier billing géré MS
-Workspace (centrale: jobs, notebooks, clusters, modèles ML, plusieurs équipes)
-Clusters moteur Spark:
- All-purpose: dev/test notebook, démarre/teste/éteint, cher
- Job cluster: créé auto pour job, détruit après
- Databricks scale auto clusters, unité conso DBU
-Delta Lake: transac ACID sur data lake, time travel (versioning)
-Unity Catalog: catalog données natif Databricks, métadonnées + contrôle accès granulaire (ligne/colonne), qui fait quoi, lineage origine données (gouvernance)
-Secu: VNet inject, MI, Unity Catalog, Private Link
-Archi type: ADLS > /silver (cleaned) > notebook Databricks transforme > Delta Lake stock > Unity Catalog gouverne > Power BI/Synapse
-Photon: ~8x plus rapide que Spark, Premium seulement
-Data realtime relationnel + non-relationnel, fichiers onprem + cloud > Databricks
DATA FACTORY (ADF)
-Orchestrateur pipeline ETL/ELT, connecte sources (onprem/Azure/SaaS), transforme et charge vers dest
-PIPELINE visuel NOCODE
-Archi: Pipeline > Activity (Copy, Data Flow, control flow), Dataset srce/dst, Linked Service connection vers srce/dst (dataset pointe dessus via connection string)
-Mapping Data Flow = transfo Spark no-code
-IR (Integration Runtime) pont entre activity et linked service:
- Azure IR (default): managé Azure, datastore public, PAS server onprem privé
- Self-Hosted IR: agent onprem/VM privée, connecte ADF à srce privée
- Azure-SSIS IR: migrer packages SSIS sans réécrire
-Trigger pipeline: schedule, storage event (upload blob), custom event (Event Grid), tumbling windows (attend pipeline fin, lance séquentiel)
-Secu: VNet, MI, PE, KV
-Schema drift / transfo data > ADF, ADF = batch (PAS temps réel)
CACHE FOR REDIS & CDN
-Cache mémoire, décharger et réduire latence (gain 800-1000% surtout BDD)
-Replication geo (minimum Premium), zone redondant par défaut, read-only secondaire, failover manuel
-CDN cache contenu (PAS données), au bord réseau pour livraison proche utilisateurs
-⚠️ Azure Cache for Redis retire 2026-2028 > Azure Managed Redis remplaçant
LOGIC APP
-Workflow orchestration low-code visuel, 1000+ connecteurs (M365, SAP, Salesforce, ServiceNow)
-Consumption (pay-per-action multi-tenant) vs Standard (single-tenant, VNet, stateful+stateless)
-vs Functions (pro-code) / Power Automate (no-code business users)
-vs Durable Functions: low-code + connecteurs SaaS > Logic Apps / code complexe/perf/latence > Durable
-PAS temps réel haute charge (préférer Function + Service Bus)
NOTIFICATION HUBS
-Push notifications mobiles cross-platform: iOS (APNs), Android (FCM/GCM), Windows (WNS), Amazon (ADM)
-1 hub > N plateformes, tags + templates pr personnalisation par device
-Backend (App Service/Function) envoie 1 message > Notification Hubs dispatch vers tous devices abonnés
-Distractor: Service Bus = backend-to-backend, PAS push mobile
APPCONFIG
-Centralise config (key-values + labels dev/prod) + feature flags + références KV
-Règle d'or: secrets > KV / config + feature flags > App Config (qui référence KV) > 1 endpoint côté app
-Feature flags: % rollout / targeting groups / time window > deploy ≠ release (activer sans redéployer)
-Free / Standard (soft-delete, SLA) / Premium (Private Link + CMK)
-Auth: MI + rôle App Configuration Data Reader
RÉFLEXES ANALYTICS (MEASUREUP)
-Data raw + scale + relationnel ET non-relationnel > ADLS Gen2
-Query fichiers data lake en T-SQL sans infra > Synapse Serverless SQL pool (built-in)
-Polybase = intégrer data externe à Synapse / Synapse Link = SQL+Cosmos (PAS spark tables)
-ETL/schema drift > ADF / ML avancé > Databricks / streaming simple > Stream Analytics / SIEM/temps réel > Event Hub
STREAMING
-Stream Analytics: SQL-like live sur stream (simple, no-code) / Databricks Streaming = complexe/ML
-IoT bidirectionnel (renvoyer aux capteurs) > IoT Hub (PAS Event Hub unidirectionnel)
-Logs/data SIEM externe temps réel > Event Hub (PAS Service Bus = queue)
GOUVERNANCE - PURVIEW VS UNITY CATALOG
-Purview = gouverne TOUT le patrimoine data (onprem, cloud, SaaS), LA réponse governance AZ-305
-Unity Catalog = gouvernance Databricks-only (catalog, schema, table, ACL, Delta Sharing)
ENTRA ID GOVERNANCE (P2 + add-on)
-Entitlement Management: self-service access packages (catalogue de ressources + policy approval + expiration)
-Access Reviews: recertification périodique (membres groupes, role assignments, guests, ML-assisted P2)
-Lifecycle Workflows (add-on Entra ID Governance, le + net new AZ-305): joiner/mover/leaver auto via triggers attributs HR (employeeHireDate, leaveDate)
-PIM (rappel AZ-104): just-in-time activation rôles privilégiés
-⚠️ Entra ID Governance for Guests add-on obligatoire janv 2026 pour governance sur guest users
AZURE BLUEPRINTS (deprecated 11 juil 2026, encore en exam)
-Package réutilisable artifacts (RG, policies, role assignments, ARM templates)
-Blueprint Definition = scope MG OU subscription (stocke template, 1 def par "modèle")
-Blueprint Assignment = SUBSCRIPTION ONLY (1 assignment par sub cible, N subs sous MG > N assignments)
-Blueprints restent CONNECTÉS aux ressources post-deploy (vs ARM templates one-shot)
AZURE POLICY REMEDIATION WORKFLOW
-Mnémo D-A-R: Definition (effet deployIfNotExists/modify) > Assignment (+ MI + role) > Remediation task
-Effects audit/deny n'ont PAS besoin de remediation
ACTIVITY LOG VS RESOURCE GRAPH
-Activity Log = HISTORY "qui a créé/supprimé/modifié quoi quand" (control plane events, 90j default, export LAW pour long terme)
-Resource Graph = INVENTAIRE current state / KQL queries "toutes mes VMs sans tag X"
-Distractor Advisor = reco optimisation pas audit
NETWORK WATCHER OUTILS
-VPN Gateway diag > VPN Troubleshoot (le seul VPN-aware)
-Traffic VM dump > Packet Capture
-Pourquoi tel traffic bloqué/permis > NSG diagnostics / IP Flow Verify
-Latence/perte E2E périodique > Connection Monitor
AVAILABILITY & RECOVERY SQL
-Auto-Failover Group ⭐ : SQL DB ET MI, async, failover auto avec grace period, listener DNS stable, group multi-DB atomique
-Active Geo-Replication: SQL DB only, async, failover MANUEL, DNS change après failover, multiple replicas possibles (jusqu'à 4)
-3 modèles HA SQL: Remote Storage Model (GP/Basic/Standard, db sur Azure Storage, disruption pendant failover) / Local Storage Model (BC/Premium, db sur SSD local, Always On AG 4 replicas, minimal disruption, read scale-out gratuit) / Hyperscale Model (page servers + log service + 4 HA replicas + 30 named read replicas, jusqu'à 100TB)
-Zone-redundant +30% coût, SLA 99.995% intra-region
ASR (AZURE SITE RECOVERY)
-DR managé: réplication VMs Azure↔Azure (cross-region), VMware/Hyper-V↔Azure, physical↔Azure
-RPO ~5 min (continuous replication), RTO selon test (min/h)
-Recovery Plan: orchestration ordre démarrage VMs + scripts custom + manual actions (RBAC dependent)
-Test failover (sandbox isolé) avant prod failover (sans impact source)
-Cross-region move VMs = ASR ou Resource Mover (pas natif)
BACKUPS (RSV + BACKUP VAULT)
-RSV (Recovery Services Vault, legacy): VM, SQL VM, Azure Files, MARS agent, DPM/MABS
-Backup Vault (moderne): Blob, Disk, PG Flex, Kubernetes (AKS PV), Azure Database for MySQL
-VM Backup policy: Standard = 1×/jour RPO 24h, Enhanced = jusqu'à 4×/jour RPO 4h (6 snapshots/j)
-Retention: daily 9999j, weekly 5163sem, monthly 1755mois, yearly 99 ans
-Soft-delete 14j default (jusqu'à 180j configurable), immutable vault pour compliance
-Cross-region restore avec GRS, cross-subscription restore moderne
CAF & MIGRATIONS
-Phases CAF: Strategy > Plan > Ready > Adopt > Govern > Secure > Manage (Migrate/Innovate sont DANS Adopt, pas phases séparées)
-Landing Zone (ALZ): MGs, subs, identity, network, monitoring, governance préparés via Bicep/Terraform officiels MS
-5R: Rehost (lift-and-shift) / Refactor (PaaS) / Rearchitect (microservices) / Rebuild (from scratch) / Replace (SaaS)
-Azure Migrate: discover + assess + migrate (appliance onprem, dependency analysis, performance-based sizing toujours)
-DMS (Database Migration Service): online/offline, SQL/MySQL/PG/Mongo/Oracle, ADF behind scene
-Azure Data Studio + extension Azure SQL Migration = recommandé MS moderne
-Storage data transfer: AzCopy (CLI rapide, Blob+File only), Storage Explorer (GUI), Data Box (disques physiques massifs), Azure File Sync (étendre file server onprem)
DATA BOX FAMILY (2026)
-Data Box Disk: SSD 35 TB max (8 TB par disque, jusqu'à 5)
-Data Box 120: 120 TB usable (next-gen, remplace 80 TB phasé out)
-Data Box 525 ⭐: 525 TB usable (next-gen, remplace Heavy RETIRÉ)
-Data Box Heavy RETIRÉ 2026, 80 TB phasé out
-Data Box Gateway: VM appliance hyperviseur, ingestion CONTINUE async SMB/NFS > Azure, cache local
-Stack Edge: appliance physique ML edge + ingest continue
-Import/Export: tes propres disques shippés au DC, SEULE option cross-géo (US↔EU), hardware customer
-Reflex 500 TB one-shot > 1 Data Box 525
AVS (AZURE VMWARE SOLUTION)
-VMware sur Azure natif (vSphere, vCenter, NSX-T, vSAN, HCX)
-Lift-and-shift centaines/milliers VMs VMware SANS re-platform, garder vCenter/NSX
-Migration via HCX (vMotion étendu cross-cloud), Azure Migrate orchestre
-Pricing à l'host (AV36/AV52/AV64), réservé MS 1-3 ans = -50%
-LE service AZ-305 pour "migrer environnement VMware entier"
APPLICATION INSIGHTS
-APM (Application Performance Monitoring) Azure Monitor, telemetry détaillée apps Web/API
-Workspace-based ⭐ (data dans LAW), Classic legacy à migrer
-3 signaux OpenTelemetry: logs, metrics, traces
-Telemetry: requests, dependencies, exceptions, traces, custom events, metrics, page views, availability tests
-Features: Application Map (deps graph), Live Metrics (1s latency debug incident), Smart Detection (ML anomalies), Profiler (CPU sampling prod), Snapshot Debugger (variables au moment exception)
-Sampling adaptive (default) obligatoire si volume élevé sinon explosion budget LAW
-Auto-instrumentation: App Service, Functions, AKS (zero code)
-Distributed Tracing W3C + OpenTelemetry
-URL ping test retire sept 2026 > migrer Standard test
VS AUTRES OUTILS MONITORING
-Azure Monitor = umbrella (metrics + logs platform-wide)
-Log Analytics = engine KQL storage
-VM Insights = perf VMs / Container Insights = AKS/ACI / Network Watcher = réseau / Activity Log = control plane / App Insights = code-level depuis l'intérieur de l'app
-"App Insights = from inside the code, others = from outside the infra"
SQL AUDIT LOGS
-Audit Azure SQL DB/Synapse/MI au niveau serveur ET db (qui logs, failed login, modif SQL)
-Destinations: Event Hub (same region only), Storage (different region OK), LAW (different region OK)
-3 simultanément possibles
DEFENDER FOR SQL
-Vulnerability Assessment + Advanced Threat Protection (SQL injection, anomalous access, brute force, exfiltration)
-Coût par DB/instance, recommandé toute DB exposée (même via PE)
-ATP toujours en mode Alert ou Alert+Deny
TABLE STORAGE (note user à compléter)
-Key-value store simple intégré Storage Account, schemaless
STREAM ANALYTICS (note user à compléter)
-SQL-like sur streams en quasi temps-réel, no-code, simple
PIÈGES EXAM CRITIQUES (récap MeasureUp + TutorialDojo)
-MySQL Flex Server Burstable = PAS de HA, pour DR régional > backup GRS (pas ZRS)
-SQL MI = PAS de Hyperscale (GP/BC only, cap 16 TB), >16 TB > SQL DB Hyperscale
-Cosmos DB auth: SAS = storage only PAS Cosmos, Entra RBAC ⭐ ou resource token (granular TTL)
-Activity Log = history / Resource Graph = inventory snapshot KQL
-Network Watcher VPN = VPN Troubleshoot (le seul VPN-aware)
-ExpressRoute Global Reach multi-site failover = BGP (static = manuel)
-Remote workers = P2S (jamais S2S, S2S = LAN-to-VNet entier)
-Azure Blueprints Definition (par MG) vs Assignment (par sub), restent connectés post-deploy
-Azure Policy remediation D-A-R: Definition > Assignment+MI+role > Remediation task
-Stored Access Policy: grouper SAS au container level > révoquer sans changer storage key
-Azure Files tiers (≠ Blob): infrequent + lowest cost > Cool Files (PAS Transaction Optimized)
-VNet CIDR overlap on-prem = peering KO silencieux, GatewaySubnet /27 mini, nom case-sensitive
-CAE = Entra invalide tokens en quasi temps-réel (user disabled, IP change, MFA fail) via CAEP
-Azure Arc-enabled K8s = gouverner clusters K8s hors Azure (EKS, GKE, on-prem) via control plane Azure
-VM Backup RPO: Standard 24h / Enhanced 4h (jusqu'à 6 snapshots/j)
-DB migration SQL Server > Azure SQL = Azure Data Studio + extension (PAS Azure Migrate IaaS)
-Function authLevel Anonymous OK pour API publique read-only (pas sur-précaution Function key)
-AKS vs VM: custom OS deps lourdes > VM, sinon AKS si containerisable + scale + control
-Oracle WebLogic on AKS via WebLogic Kubernetes Operator (partenariat MS-Oracle)
-App Reg + Conditional Access (SaaS cloud) vs App Proxy (on-prem) - combo SSO Entra + device
-Service Bus Sessions garantit FIFO par clé / Partitioning PERD FIFO (perf throughput only)
-ExpressRoute "Premium Direct" = combo SKU Premium (global) + modèle Direct (sans provider)
-Multi-tenant Entra: 1 role assignment par tenant minimum (pas cross-tenant inheritance)
-Azure Batch parallel: default 1 task/node, config explicite taskSlotsPerNode requise
-GZRS = option Storage Account (PAS backup MySQL/PG Flex qui supporte LRS/ZRS/GRS only)
-BC read scale-out gratuit (4 replicas inclus) vs GP (PAS de read replica)
-Cosmos Strong + multi-write IMPOSSIBLE (Strong = single-write only)
-Hyperscale = 128 TB single DB (100 TB = elastic pool Hyperscale limit)
-Data Box Heavy RETIRÉ 2026, SKUs actuels = Data Box 525 (525 TB) et Data Box 120 (120 TB)
-User Delegation SAS scope élargi 2026: Blob+ADLS+Queue+Table+Files
-AE Secure Enclaves = vrai in-use server-side (VBS/SGX) vs AE base = client-side only
-Kubenet retraite 31 mars 2028 > Azure CNI Overlay recommandé
-PITR SQL RPO ≈ 10 min (log backups 5-10 min, approximatif selon activité)
-HCX migration AVS: Bulk = parallèle gros parc (≥50 VMs), vMotion = série 1à1 (<30 VMs), RAV = bulk+cutover live zéro downtime, Cold = VM éteinte
-SQL VM tempdb: disque ephemeral D:\ (perf µs, recréée reboot), PAS Premium SSD persistant
-SAS + Storage Firewall = defense-in-depth (token + IP whitelist / VNet rules), SAS seul vulnérable si vol token
-Diagnostic Settings cross-subscription OK (LAW Sub B, ressources Sub A, même tenant Entra obligatoire, même région recommandée)
-ADF Mapping Data Flow + Allow schema drift = colonnes auto-propagées Source+Sink, use case CSV partenaire évolutif
-SQL DB in-memory OLTP: FULL Premium DTU = BC vCore (memory-opt tables persistantes), NONE GP, SUBSET Hyperscale (PAS memory-opt tables persistantes full)