8 — Data Platforms (AZ-305)

A. Vocabulaire DB cloud

A.1 SQL relationnel vs NoSQL ⭐⭐

A.2 ACID vs BASE

• ACID (Azure SQL) : transfert 100€ A→B = les 2 ops réussissent OU aucune. Jamais d'état intermédiaire incohérent.
• BASE (Cosmos) : post publié, followers Paris voient instantanément, Tokyo 200ms après. Cohérence finale.

A.3 Request Units (RU/s) — l'unité de coût Cosmos

• RU/s = la "monnaie" de Cosmos : chaque op coûte des RU (read ≈ 1 RU, write ≈ 5 RU).
• Tu paies les RU/s réservées (provisioned) ou consommées (serverless).

A.4 Partition Key (Cosmos) ⭐

Attribut qui détermine sur quelle partition physique un document est stocké. Choix critique et figé à la création.

Bonne PK = haute cardinalité (millions valeurs distinctes) + distribution équitable + souvent dans WHERE. Mauvaise PK = peu de valeurs (/status avec 5 valeurs) → hot partition.

B. Azure SQL — Famille (vue d'ensemble) ⭐⭐

Décision rapide

• Cloud-first / nouvelles apps → SQL DB
• Migration SQL Server on-prem rapide + compat features instance-level → SQL MI
• Compat 100% + control OS / agents tiers / version SQL spécifique → SQL VM

C. Azure SQL Database (PaaS)

C.1 C'est quoi

PaaS relationnel managé (single DB ou elastic pool), ~99% compat SQL Server, HA managé, scaling fin → cible apps modernes cloud-first.

C.2 Compute models

• Provisioned : capacité fixe, payé 24/7 — prod prévisible
• Serverless ⭐ : auto-pause après inactivité, billing par seconde — dev/test sporadique

C.3 Tiers vCore (3 modèles archi)

🎯 Mémo 305 :

• "Production HA" (sans précision) → BC (l'exam considère GP comme "HA avec disruption")
• "DB > 4 TB" ou "read scale-out massif" → Hyperscale
• "Budget restreint, RTO 30s OK" → GP

C.4 DTU vs vCore

C.5 Features scalabilité (awareness)

• Elastic Pools : partage capacité entre N DBs (SaaS multi-tenant, ~10× moins cher que N DBs peak séparées).
• Read Scale-out : BC + Hyperscale exposent un replica readable via ApplicationIntent=ReadOnly dans conn string. Offload reads.
• Sharding : N DBs + shard map (customerId % 10) pour scale horizontal. (utile pour donné qui doit être dans la géographie des utilisateurs)

C.6 Pièges 305

• 🚨 Hyperscale = SQL DB only (pas MI).
• 🚨 DTU model = pas d'Azure Hybrid Benefit (vCore only).
• 🚨 Elastic Pool oversize : tous tenants peak simultanément → throttling pool.
• 🚨 Read Scale-out sans ApplicationIntent=ReadOnly → reads tapent sur primary.

🚨 SQL DB — in-memory OLTP support par tier :

• Premium (DTU) et Business Critical (vCore) : FULL support in-memory OLTP + memory-optimized tables persistantes + clustered columnstore indexes.
• General Purpose : ❌ pas d'in-memory OLTP.
• Hyperscale : SUBSET only d'in-memory OLTP objects (memory-optimized table types non-persistés, table variables, native compiled modules) — PAS de memory-optimized tables persistantes complètes.

Mnémo : Premium DTU = BC vCore = full in-memory. GP = none. Hyperscale = partiel.

D. Azure SQL Managed Instance (MI)

D.1 C'est quoi

PaaS instance complète SQL Server (quasi 100% compat) — cible migrations SQL Server on-prem rapides sans refactor.

D.2 Features uniques vs SQL DB

• SQL Agent intégré (jobs)
• CLR (.NET assemblies)
• Cross-database queries
• Linked servers
• DTC (transactions distribuées)
• Service Broker

D.3 Networking

• Toujours dans un VNet (subnet dédié, délégué Microsoft.Sql/managedInstances).
• Public endpoint optionnel, recommandé privé only.

D.4 Tiers

D.5 Pièges 305

• 🚨 SQL MI = pas de Hyperscale (GP/BC only, cap ~16 TB). Scenario >16 TB → forcément SQL DB Hyperscale.
• 🚨 Subnet dédié non partageable + délégation obligatoire.
• 🚨 Déploiement long (4-6h création, 1-6h scale).

E. SQL Server on Azure VM (IaaS)

E.1 Quand l'utiliser

• Compat 100% SQL Server (toutes features incl. agents tiers).
• Control complet OS, version SQL spécifique.
• Workloads >100 TB ou non-supportés en PaaS (legacy ETL, drivers exotiques).
• Azure Hybrid Benefit (BYOL) pour réutiliser licences on-prem (-55% Standard, -85% Enterprise).

E.2 HA / DR (à ta charge)

• HA via Always On AG manuel (multi-VMs + WSFC + AD + Internal LB pour le listener) — voir fiche 11.
• DR via ASR ou Always On AG cross-region.

E.3 Pièges 305

• 🚨 SQL VM = IaaS : patch OS, HA, backups → à toi. PaaS (DB/MI) gère tout.
• 🚨 Azure Hybrid Benefit = essentiel pour rentabilité SQL VM.
• 🚨 SQL IaaS Agent Extension = à installer/enregistrer pour features Azure (backup, monitoring, AHB tracking).

🚨 SQL Server on Azure VM — tempdb placement :

• Mettre tempdb sur le disque éphémère D:\ (ephemeral local SSD) → perf I/O optimal (latence µs), data perdue au reboot (OK car tempdb se recrée auto au démarrage SQL).
• Storage Account / Premium SSD persistents pour tempdb = surcoût + latence inutile. ⚠️ Distractor exam : "tempdb sur Premium SSD persistant" = mauvaise pratique, choisir ephemeral D:\. (localstorage)

F. Azure DB for MySQL / PostgreSQL — Flexible Server

F.1 C'est quoi

PaaS managé MySQL / PostgreSQL avec Flexible Server ⭐ (successeur Single Server legacy) — zone-redundant HA + maintenance window custom + VNet injection.

F.2 Flexible Server vs Single Server (legacy)

F.3 Tiers Flexible Server

F.4 Pièges 305

• 🚨 Burstable = pas de HA. Question prod HA → GP ou Memory Optimized.
• 🚨 Single Server legacy → migrer vers Flexible Server.
• 🚨 Distractors exam : "Burstable HA" = faux | "Single Server custom maintenance" = faux.

G. Cosmos DB (NoSQL) ⭐⭐

G.1 C'est quoi

NoSQL multi-modèle, multi-region, low-latency (<10ms P99). Cœur "Design data storage" AZ-305 — schema-less + scale horizontal natif + SLA 99.999%. Gross feature: multi-region write.

G.2 Hiérarchie

Account (région primaire + N régions) → Database → Container (collection/table/graph) → Item (document/row/vertex)

G.3 APIs (façades) ⭐

🎯 Question type 305 : "Migrer app MongoDB existante avec wire protocol Mongo intact" → Cosmos DB for MongoDB API.

G.4 Throughput modes (RU/s)

Throughput scope : Database-level (RU partagées, max 25 containers) vs Container-level ⭐ (RU dédiées, recommandé prod).

G.5 Partitioning

• PK = haute cardinalité + distribution équitable + souvent dans WHERE.
• Limite 20 GB / partition logique.

G.6 Consistency Levels (5) ⭐⭐

🎯 Mémo : Strong = cher + lent multi-region. Session suffit 99% des cas prod.

G.7 Multi-Region & Replication

G.8 Backup

• Periodic (default) : 2/jour, restore via ticket
• Continuous PITR ⭐ : 7j gratuit / 30j payant, self-service portail

G.9 Quand l'utiliser

• NoSQL global low-latency schema-less (<10ms P99).
• Multi-region writes nécessaires (apps mondiales, edge).
• Charges write-heavy / IoT / catalogue / sessions / social.
• PAS : relationnel + ACID + joins → SQL DB | cache key-value → Redis | big data analytical → Synapse/Databricks.

G.10 Pièges 305

• 🚨 Mauvaise PK (/status, /region) → hot partition : 1 partition à 100% RU/s, 429 errors malgré faible utilisation totale.
• 🚨 SAS = storage only, PAS Cosmos (auth = keys / tokens / Entra RBAC).
• 🚨 Strong consistency en multi-region = très coûteux + latence writes (sync cross-region). Session suffit.
• 🚨 PK figée à la création : pas de migration sans recréer container.
• 🚨 Synapse Link : 2026 sunset → préférer Fabric Mirroring pour HTAP nouveaux projets.

H. Caching — Redis

📚 Azure Cache for Redis & Azure Managed Redis = traités dans la fiche 5 - App Integration Services (section M).

Rappel court : caching key-value in-memory pour sessions, offload DB, rate limiting, distributed lock. Azure Cache for Redis en sunset 2026-2028 → nouveaux projets = Azure Managed Redis ⭐ (Redis Enterprise multi-threaded, modules natifs, active geo-rep, zone-redundant par défaut).

I. Rappel HA/DR & Backup (détail → fiche 11)

Vite fait, le détail est dans la fiche 11 :

• HA SQL DB intra-region : GP (~30s reattach storage) / BC Always On AG 4 replicas (<10s) / Hyperscale (page servers). Option Zone-Redundant (+30% coût, SLA 99.995%).
• DR cross-region SQL DB / MI : Auto-Failover Group ⭐ (listener DNS stable + failover auto + multi-DB atomique) ou Active Geo-Replication (manuel, SQL DB only).
• Backup SQL : PITR 1-35j + LTR W/M/Y jusqu'à 10 ans + Geo-redundant default (GRS).
• MySQL/PG Flex backup : LRS / ZRS / GRS ⭐ pour DR régional + Read Replica cross-region pour DR manuel.
• Cosmos DB : Continuous Backup PITR 7d/30d + Multi-region writes pour HA globale.
• Redis : Zone-redundant intra-region (Standard+) + Active geo-rep (Enterprise / Managed Redis) pour DR.

🎯 Réflexes : "DNS stable + auto-failover" → Auto-FG · "rétention longue compliance" → LTR · "DR régional MySQL/PG" → GRS + Read Replica cross-region.

J. Decision Trees AZ-305

Par type de data

Tu as quel type de data ?
├─ Relationnel + ACID + joins                          → Azure SQL
│   ├─ Cloud-first, nouvelles apps                     → SQL Database
│   │   ├─ Mission-critical low-latency                → Business Critical
│   │   ├─ Volume >4 TB ou scale reads massif          → Hyperscale
│   │   └─ Standard prod                               → General Purpose
│   ├─ Migration SQL Server avec Agent/CLR/cross-DB   → SQL Managed Instance
│   └─ Compat 100% + control OS / agents tiers         → SQL on Azure VM (+ AHB)
│
├─ MySQL / PostgreSQL                                  → MySQL/PG Flexible Server
│   ├─ Prod HA                                         → GP ou Memory Optimized
│   └─ Dev/test                                        → Burstable
│
├─ NoSQL global, schema-less, low-latency              → Cosmos DB
│   ├─ Documents JSON natifs                           → NoSQL API
│   ├─ Migrer MongoDB                                  → MongoDB API
│   ├─ Migrer Cassandra                                → Cassandra API
│   ├─ Graphes (social, fraud)                         → Gremlin API
│   └─ App PG distribuée massive                       → PostgreSQL API (Citus)
│
├─ Cache key-value RAM (sessions, offload DB)          → Azure Managed Redis ⭐
│                                                       (ou Cache for Redis legacy si déjà déployé)
│
├─ Fichiers / blobs                                    → Storage Account (fiche 7)
└─ Big data analytical                                 → Synapse / Databricks (fiche 10)

Par tier SQL DB

Quel tier Azure SQL DB ?
├─ Production "HA" sans précision                      → Business Critical (réponse 305 par défaut)
├─ Mission-critical + read replicas inclus             → Business Critical
├─ Volume >4 TB ou jusqu'à 100 TB                      → Hyperscale
├─ Scale reads massif (30 read replicas)               → Hyperscale
├─ Budget restreint + RTO 30s OK                       → General Purpose
└─ Dev/test sporadique avec auto-pause                 → Serverless

Par consistency Cosmos

Use case ?
├─ Compteurs critiques, finance                        → Strong
├─ Tolère retard borné                                 → Bounded Staleness
├─ Read-your-own-writes (default, le + courant)        → Session ⭐
├─ Order matter, pas de gaps                           → Consistent Prefix
└─ Likes counter, no fresh required                    → Eventual

M. Pièges récurrents 305

• 🚨 OLTP vs OLAP : SQL DB / Cosmos = OLTP. Synapse Dedicated / Fabric Warehouse = OLAP (fiche 10).
• 🚨 SQL DB BC = "HA seamless" (Always On AG <10s). GP = "HA avec disruption" (~30s reattach).
• 🚨 Hyperscale = SQL DB only (pas MI).
• 🚨 SQL MI cap ~16 TB. Au-delà → SQL DB Hyperscale forcément.
• 🚨 Premium DTU = BC vCore (même archi, 2 nommages).
• 🚨 DTU = pas d'Azure Hybrid Benefit. vCore only.
• 🚨 MySQL/PG Burstable = pas de HA. Prod HA → GP ou Memory Optimized.
• 🚨 Single Server MySQL/PG = legacy → Flexible Server.
• 🚨 DR cross-region MySQL/PG : pas d'Auto-FG natif → GRS backup + Read Replica cross-region (promotion manuelle).
• 🚨 Cosmos PK figée à la création (pas modifiable).
• 🚨 Cosmos Strong consistency multi-region = très cher + lent. Session suffit 99% cas.
• 🚨 Synapse Link Cosmos = sunset 2026 → Fabric Mirroring pour nouveaux projets.).
• 🚨 SQL VM = IaaS : tout est à ta charge (patch, HA, backup). PaaS gère tout.

DEMO

Demo Portail — Create Cosmos DB account + container

💡 Serverless vs Provisioned : Provisioned = réserves RU/s (manual / autoscale), payé 24/7, charge prévisible. Serverless = pay-per-RU, max ~5k RU/s + 1 TB, pas multi-region writes, idéal dev/test.

1. Azure Cosmos DB > Create > Azure Cosmos DB for NoSQL (ou MongoDB / Cassandra / Gremlin / Table)
2. Basics tab :
   • Resource Group + Account Name : mycosmos (FQDN globalement unique)
   • Location : East US
   • Capacity mode : Provisioned throughput ou Serverless
   • Apply Free Tier Discount : Apply (1000 RU/s gratuites si dispo)
3. Global Distribution tab :
   • Geo-Redundancy : Enable (read replica paired region)
   • Multi-region Writes : Enable
   • Availability Zones : Enable
4. Networking tab : All networks / Selected networks / Private endpoint
5. Backup Policy tab : Continuous (7 days) ⭐ gratuit (PITR self-service) ou Continuous 30j / Periodic
6. Encryption tab : Service-managed key ou Customer-managed key (KV)
7. Review + create (5-10 min)
8. Après création — créer DB + container :
   • mycosmos > Data Explorer > New Container
   • Database id : mydb
   • Container id : orders
   • Partition key : /customerId (haute cardinalité, figé)
   • Throughput : Manual / Autoscale (max RU/s) / Serverless
9. mycosmos > Replicate data globally : cliquer regions sur la carte + drag Failover priorities → Save
10. Data Explorer : New Item (JSON) + New SQL Query (SELECT * FROM c WHERE c.customerId="C-001")

Demo — Cosmos Continuous Backup (PITR)

• À la création : Backup policy: Continuous (7 days or 30 days)
• Restore : Cosmos DB > Point in time restore → timestamp + nouveau account destination

Demo Portail — Cosmos Entra ID auth

1. Cosmos DB > Access Control (IAM) > + Add role assignment
2. Rôle : Cosmos DB Built-in Data Contributor → assigner à user / Managed Identity
3. (Optionnel) Cosmos DB > Settings > Features : activer Disable local auth (Entra-only)
4. Côté app : utiliser DefaultAzureCredential (MSAL) au lieu des keys

Demo Portail — Create Azure SQL DB + Entra ID auth (avec VM/SSMS)

Étape 1 — Créer VM jump avec SSMS

1. Virtual machines > + Create > Azure virtual machine
2. Basics :
   • Resource Group : rg-sqldemo
   • Virtual machine name : vm-ssms
   • Image : Windows Server 2022 Datacenter (ou marketplace avec SSMS)
   • Public inbound : Allow RDP (3389)
3. Networking : créer vnet-sqldemo + subnet snet-vm
4. Review + create → RDP, installer SSMS (aka.ms/ssmsfullsetup)

Étape 2 — Créer SQL Server + SQL Database

1. SQL databases > + Create
2. Basics tab :
   • Resource Group : rg-sqldemo
   • Database name : mydb
   • Server → Create new :
     • Server name : mysrv-demo
     • Authentication method : Use both SQL and Microsoft Entra authentication (ou Entra-only)
     • Set Microsoft Entra admin : sélectionner user/group Entra
   • Want to use SQL elastic pool? : No
   • Compute + storage > Configure database :
     • Service tier : General Purpose / Business Critical / Hyperscale
     • Compute tier : Provisioned ou Serverless (auto-pause)
     • Hardware : Standard-series Gen5 + vCores + Storage
3. Networking tab :
   • Connectivity method : Public endpoint (selected networks) ou Private endpoint
   • Allow Azure services and resources to access this server : No
   • Add current client IP address : Yes (optionnel)
4. Security tab : Microsoft Defender for SQL (recommandé) + Transparent data encryption ON (default)
5. Additional settings : Use existing data = None / Backup / Sample (AdventureWorksLT)
6. Review + create

Étape 3 — Autoriser le VNet de la VM

1. mysrv-demo > Security > Networking
2. Public network access : Selected networks
3. Virtual networks > + Add existing virtual network :
   • VNet vnet-sqldemo, Subnet snet-vm → Enable (Service Endpoint Microsoft.Sql)
4. Save

Étape 4 — Activer Entra ID auth (si pas fait à la création)

1. mysrv-demo > Settings > Microsoft Entra ID
2. Set admin → user/group DB Admins → Save
3. (Optionnel) Microsoft Entra authentication only : On → Save

Étape 5 — Se connecter via SSMS depuis la VM

1. RDP vm-ssms → ouvrir SSMS
2. Connect > Database Engine :
   • Server name : mysrv-demo.database.windows.net
   • Authentication : Microsoft Entra MFA
   • Database (Options) : mydb

Étape 6 — Créer un contained user (SQL DDL)

💡 Explication : EXTERNAL PROVIDER = principal Entra. Le user dans la DB est mappé par nom (pas de password). db_datareader/writer = rôles SQL built-in pour CRUD sans droits admin/DDL.

CREATE USER [my-app] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app];
ALTER ROLE db_datawriter ADD MEMBER [my-app];

Étape 7 — Côté app .NET (Managed Identity, zéro password)

var credential = new DefaultAzureCredential();
var sqlConn = new SqlConnection("Server=mysrv-demo.database.windows.net;Database=mydb;");
sqlConn.AccessToken = (await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "https://database.windows.net/.default" }))).Token;

📚 DEMO Azure Managed Redis = traitée dans la fiche 5 - App Integration Services.