Microsoft AZ-104: Bases de données Azure et Services de données — Guide d'étude

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Administrator Associate AZ-104 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les services de base de données et de données d’Azure couvrent les moteurs relationnels managés, le NoSQL distribué à l’échelle mondiale, la mise en cache en mémoire, l’analytique à grande échelle et l’intégration/orchestration. En tant qu’administrateur, vous devez comprendre les modèles d’achat, les niveaux de service, la topologie réseau et de sécurité, la sémantique de sauvegarde/reprise après sinistre (DR), et comment combiner les services pour optimiser la performance, le coût et la résilience. Cette section se concentre sur les choix opérationnels et les fonctionnalités de la plateforme que vous configurez au quotidien : modèles de provisionnement (DTU vs vCore), pools élastiques, sauvegarde et rétention à long terme, géoréplication et basculement, instances managées injectées dans un VNet, distribution et cohérence de Cosmos DB, réplicas en lecture/HA pour les bases de données relationnelles open-source, moteurs Synapse et runtimes Data Factory.

Bases de données relationnelles Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database propose deux modèles d’achat. Le modèle DTU regroupe le CPU, la mémoire et les IOPS en Unités de transaction de base de données (Database Transaction Units) avec les niveaux De base, Standard et Premium ; il est simple mais opaque, adapté aux charges de travail stables et prévisibles ainsi qu’au dimensionnement hérité. Le modèle vCore expose la génération/le nombre de CPU et la mémoire, associés à des contrôles de stockage et d’IOPS. Le vCore permet la transparence du dimensionnement, l’Azure Hybrid Benefit et les remises sur la capacité réservée. Au sein du modèle vCore, les niveaux de service correspondent à des profils de charge de travail et de disponibilité : le niveau Usage général utilise un stockage distant Premium SSD ou Azure Premium avec une architecture de disponibilité standard ; le niveau Critique pour l’entreprise place le calcul et le stockage sur des SSD locaux avec plusieurs réplicas, une faible latence et une mise à l’échelle en lecture (read scale-out) intégrée ; le niveau Hyperscale découple le calcul et le stockage avec des serveurs de pages pour une mise à l’échelle quasi instantanée et des bases de données de très grande taille. Pour les bases de données uniques, le niveau de calcul serverless (vCore) met à l’échelle le CPU de manière élastique et peut se mettre en pause automatiquement pour réduire les coûts d’inactivité.

Les pools élastiques partagent les ressources de calcul entre plusieurs bases de données pour absorber des charges de travail en rafale et déphasées à un coût global inférieur. Les pools sont disponibles en variantes DTU (eDTU) et vCore. Vous définissez des limites min/max par base de données pour contenir les « voisins bruyants » et un maximum pour le pool afin de contrôler les dépenses. La sur-souscription est acceptable lorsque les rafales sont courtes et non corrélées. Le dimensionnement du pool dépend de la consommation moyenne additionnée, plus une marge de manœuvre pour la simultanéité ; la surveillance des métriques par base de données et par pool est essentielle pour maintenir les SLO.

Les sauvegardes sont automatiques. Azure SQL maintient des sauvegardes complètes, différentielles et de journaux de transactions avec une restauration à un point dans le temps (PITR) à n’importe quelle seconde dans la fenêtre de rétention (généralement de 7 à 35 jours selon le niveau et la configuration du stockage). La rétention à long terme (LTR) conserve les sauvegardes complètes hebdomadaires pendant des années dans un stockage RA-GRS ; vous pouvez restaurer une sauvegarde LTR en tant que nouvelle base de données sur n’importe quel serveur dans le même abonnement et ensemble de régions, et la restauration inter-régions est disponible si le stockage de sauvegarde géo-redondant est activé. Les restaurations créent une nouvelle base de données ; elles n’écrasent pas sur place.

Les options de géoréplication incluent la géoréplication active pour les bases de données et les pools uniques (jusqu’à quatre secondaires lisibles avec réplication asynchrone) et les groupes de basculement automatique au niveau du serveur logique. Les groupes de basculement regroupent plusieurs bases de données (ou un serveur entier) avec une reprise après sinistre géographique (geo-DR), un point de terminaison d’écoute en lecture-écriture, un point de terminaison en lecture seule pour décharger les lectures, un basculement automatique basé sur l’état de santé et une redirection basée sur le DNS. Le niveau Critique pour l’entreprise fournit également une mise à l’échelle en lecture (read scale-out) via un réplica local lisible, permettant un déchargement immédiat de la charge de travail de lecture sans la complexité inter-régions.

Azure SQL Managed Instance (MI) offre une compatibilité de près de 100 % avec le moteur SQL Server, y compris SQL Agent, les requêtes inter-bases de données, CLR, les serveurs liés, Service Broker et la sauvegarde/restauration native de fichiers .bak depuis Azure Blob Storage. MI est injectée dans un VNet : vous la déployez dans un sous-réseau dédié et délégué avec des adresses IP privées et des contrôles NSG/UDR ; planifiez la taille du sous-réseau et l’espace d’adressage à l’avance, car le redimensionnement ultérieur des sous-réseaux est complexe. Les chemins de migration incluent l’Azure Database Migration Service (basculements en ligne/hors ligne), la sauvegarde/restauration native vers une URL dans MI, et la réplication transactionnelle depuis un SQL Server local vers MI. Choisissez MI lorsque vous avez besoin d’une parité de surface d’exposition ou de fonctionnalités à l’échelle de l’instance que les bases de données uniques n’exposent pas.

Azure Database for MySQL et Azure Database for PostgreSQL (Flexible Server) fournissent des moteurs OSS managés avec un contrôle sur les fenêtres de maintenance, l’arrêt/démarrage pour des économies de coûts, des capacités de calcul burstables et à usage général, la croissance automatique du stockage et l’intégration VNet. Flexible Server offre une haute disponibilité avec une réplication synchrone ; vous pouvez choisir une HA redondante interzone (zone-redundant HA) entre les Zones de disponibilité pour une meilleure isolation des pannes ou une HA dans la même zone (same-zone HA) pour une latence d’écriture plus faible. Des réplicas en lecture sont disponibles pour la mise à l’échelle des lectures et peuvent être provisionnés à l’intérieur ou entre les régions ; ils utilisent une réplication asynchrone et sont idéaux pour l’analytique, le reporting ou les microservices à forte charge de lecture. Promouvez un réplica pour le basculement ou l’expansion régionale si nécessaire, en tenant compte du retard de réplication potentiel.

Données distribuées et mise en cache (Cosmos DB et Azure Cache for Redis)

Azure Cosmos DB est une base de données multimodèle, distribuée à l’échelle mondiale, offrant des API pour Core (SQL), MongoDB, Cassandra, Gremlin (graphe) et Table. Le choix de l’API détermine la compatibilité des pilotes clients et la sémantique du modèle de données ; sur le plan opérationnel, vous gérez le débit (RU provisionnées ou mise à l’échelle automatique) et les partitions, quelle que soit l’API. Les données sont partitionnées horizontalement par une clé de partition qui doit présenter une cardinalité élevée et une distribution d’accès uniforme pour éviter les partitions surchargées (« hot partitions ») ; évitez les clés à augmentation monotone et envisagez des clés de partition hiérarchiques lorsque des modèles d’accès composés existent. Les requêtes inter-partitions sont prises en charge mais consomment plus de RU ; colocalisez les données associées par clé de partition lorsque cela est possible.

Les niveaux de cohérence sont ajustables par compte, base de données ou requête : Fort (Strong) garantit la linéarisabilité ; Obsolescence limitée (Bounded Staleness) limite l’obsolescence par le temps ou la version ; Session (par défaut) assure la lecture de vos propres écritures (read-your-writes) pour une session ; Préfixe cohérent (Consistent Prefix) garantit l’ordre sans une cohérence totale ; Éventuelle (Eventual) maximise la disponibilité et les performances. Pour les écritures multirégions, choisissez une stratégie de résolution des conflits appropriée (Le dernier rédacteur l’emporte (LastWriterWins) ou personnalisée via des procédures stockées) et définissez des priorités de basculement. La distribution mondiale ajoute des régions en un clic ; le service gère la réplication, le basculement et le routage optimisé pour la latence avec des SLA sur le débit, la latence, la disponibilité et la cohérence.

Azure Cache for Redis fournit une latence inférieure à la milliseconde, s’appuyant sur Redis. Les niveaux (Tiers) progressent en capacité : Basic (nœud unique, pour le dev/test), Standard (répliqué à deux nœuds primaire/réplica avec SLA), Premium (tailles plus importantes, clustering, persistance, injection dans un VNet, géo-réplication et modules Redis comme Bloom), Enterprise et Enterprise Flash (basés sur Redis Enterprise avec un clustering avancé, une géo-réplication active pour les écritures multi-primaires et des caches plus grands adossés à Flash). Les stratégies d’éviction définissent le comportement en cas de pression sur la mémoire : noeviction (erreurs à l’écriture), allkeys-lru/lfu/random (considère toutes les clés) et volatile-lru/lfu/ttl/random (considère uniquement les clés avec un TTL). Pour la mise en cache de session, utilisez le niveau Premium ou supérieur pour la persistance si vous ne pouvez pas vous permettre la perte de session, activez les TTL sur les clés pour limiter la croissance, et envisagez le clustering pour le débit et la mise à l’échelle. Placez le cache dans la même région et le même réseau virtuel que les serveurs d’application pour minimiser la latence ; utilisez une Identité managée (Managed Identity) ou des clés d’accès et appliquez l’isolation réseau via Private Link ou l’injection dans un VNet.

Analytique et intégration (Synapse Analytics et Data Factory)

Azure Synapse Analytics unifie l’entreposage de données (data warehousing), le big data et l’intégration de données. Le pool SQL dédié (anciennement SQL DW) est un moteur MPP (Massively Parallel Processing) avec des distributions par hachage (hash)/en tourniquet (round-robin), des tables répliquées et la mise en cache des jeux de résultats. Vous augmentez ou diminuez la capacité de calcul (scale up/down) pour respecter les fenêtres de SLA et pouvez la mettre en pause pour ne payer que le stockage. L’isolation des charges de travail (workload) peut être réalisée avec des groupes de charges de travail (workload groups) et des paramètres d’importance pour protéger les requêtes critiques. Le pool SQL serverless fournit du T-SQL à la demande sur les données dans Azure Data Lake Storage Gen2 sans provisionnement ; vous payez par To analysé et pouvez externaliser les schémas à l’aide de vues pour les couches sémantiques. Les pools Spark apportent Apache Spark à Synapse avec des clusters à mise à l’échelle automatique et à la demande, permettant l’utilisation de notebooks, de Delta Lake et du machine learning avec une sécurité et un lignage des données (data lineage) intégrés ; vous pouvez partager les données du lakehouse entre les moteurs Spark et SQL.

Azure Data Factory (ADF) orchestre le déplacement et la transformation des données. Les Pipelines coordonnent les activités telles que la Copie (Copy), le Flux de données (Data Flow) (flux de mappage basés sur Spark) et le calcul externe (Databricks, Synapse, Functions). Les Jeux de données (Datasets) définissent la forme et l’emplacement des données, tandis que les services liés (linked services) encapsulent les détails de connexion (authentification, points de terminaison) aux sources/cibles. Les runtimes d’intégration (IR) fournissent le plan de calcul et réseau : Azure IR pour le déplacement et la transformation natifs du cloud, Self-hosted IR pour les sources sur site (on-premises) ou en réseau privé via HTTPS sortant, et Azure-SSIS IR pour le lift-and-shift des packages SSIS. Les déclencheurs (Triggers) (planifié, fenêtre bascule, événementiel) permettent une orchestration reproductible ; le réseau virtuel managé et les points de terminaison privés (private endpoints) peuvent être activés pour la protection contre l’exfiltration de données et une connectivité conforme. Le paramétrage et l’intégration de Key Vault prennent en charge des modèles réutilisables et sécurisés pour la promotion entre environnements (dév/test/prod).

Continuité d’activité, géo-fonctionnalités et pools élastiques

Les stratégies de sauvegarde et de restauration diffèrent selon les services mais partagent des thèmes clés : automatiser, tester régulièrement les restaurations et séparer la restauration à un instant dans le temps (PITR) pour les erreurs opérationnelles de la rétention à long terme (LTR) pour la conformité. Dans Azure SQL, utilisez la PITR pour les suppressions accidentelles ou les mauvais déploiements ; stockez les sauvegardes complètes hebdomadaires LTR dans un stockage RA-GRS pour la rétention réglementaire et les restaurations de reprise d’activité inter-régions. Pour MySQL/PostgreSQL Flexible Server, activez les sauvegardes automatisées avec un stockage géo-redondant là où il est pris en charge, définissez la rétention selon la politique et validez les restaurations à un instant dans le temps sur des serveurs alternatifs. Les comptes Cosmos DB avec plusieurs régions activent le basculement automatique ; combinez-les avec des écritures multirégions lorsque le RPO doit être de zéro et que l’application peut résoudre les conflits de manière déterministe.

La géo-réplication et les groupes de basculement automatique dans Azure SQL fournissent la reprise d’activité (DR) et le déchargement des lectures. Utilisez la géo-réplication active pour une seule base de données ou un seul pool lorsque vous souhaitez gérer explicitement les bases de données secondaires ; utilisez les groupes de basculement automatique pour regrouper de nombreuses bases de données et obtenir des écouteurs basés sur DNS ainsi qu’un basculement automatique. Lorsque les lectures à faible latence sont importantes mais que la DR n’est pas l’objectif, utilisez la mise à l’échelle en lecture du niveau Business Critical ou les réplicas nommés Hyperscale pour maintenir l’analytique et le reporting hors de la base de données primaire. Surveillez la latence de réplication et les signaux de santé du basculement, et testez des exercices de basculement pour valider les RTO/RPO.

Les pools élastiques sont des leviers d’optimisation des coûts pour les applications SaaS multi-locataires et les flottes de petites bases de données. Dans les pools basés sur les DTU, allouez des eDTU avec des plafonds par base de données ; dans les pools vCore, allouez des vCores, de la mémoire et un débit d’E/S avec un nombre maximal de vCores par base de données et une gouvernance des E/S. Dimensionnez correctement en mesurant l’utilisation au 95e centile par base de données et en alignant la capacité du pool sur les modèles de simultanéité ; augmentez les plafonds par base de données pour les locataires ayant des SLO plus élevés et envisagez de diviser les pools par classe de charge de travail (par exemple, locataires lourds vs légers). Utilisez des alertes sur les limites du pool et par base de données pour détecter la saturation à un stade précoce. Lorsqu’une poignée de bases de données atteint constamment les plafonds maximums, déplacez-les vers un calcul dédié ou un pool séparé pour maintenir la prévisibilité.

Scénario de problème pratique

Starbucks doit moderniser sa plateforme de fidélité mondiale pour faire face aux pics de trafic pendant les promotions, réduire la charge opérationnelle et prendre en charge l’analytique sans perturber les opérations des magasins dans le monde entier.

Partitionner le magasin de données opérationnelles :

Choisir Azure Cosmos DB (API Core SQL) pour les interactions clients et les événements de récompenses afin d’obtenir une distribution mondiale à faible latence. Configurer les écritures multirégions dans des régions proches des principales populations de clients et définir la cohérence de session pour équilibrer la lecture de ses propres écritures avec les performances. Sélectionner une clé de partition à haute cardinalité telle que customerId ou une clé hiérarchique composite (customerId, eventMonth) pour distribuer le débit et prendre en charge les modèles de requêtes courants.

Implémenter les données transactionnelles de comptes et de catalogue :

Déployer Azure SQL Managed Instance pour les soldes de comptes, les échanges de points et le catalogue de références (SKU) car une compatibilité de près de 100 % avec SQL Server est nécessaire pour les procédures stockées existantes et la logique inter-bases de données. Placer l’instance managée (MI) dans un sous-réseau dédié et délégué avec des NSG et des tables de routage comme requis par l’injection dans un VNet, permettant un accès privé depuis les sous-réseaux applicatifs et ExpressRoute.

Fournir une mise à l’échelle en lecture mondiale et une reprise d’activité (DR) pour les charges de travail relationnelles :

Pour les nouveaux microservices utilisant Azure SQL Database, utiliser le niveau vCore Business Critical pour une faible latence et une mise à l’échelle en lecture. Créer un groupe de basculement automatique vers une région jumelée avec des points de terminaison d’écouteur en lecture seule pour les lectures localisées et un basculement automatique afin d’atteindre les objectifs de DR.

Ajouter une gestion de session à faible latence :

Déployer Azure Cache for Redis Premium avec mise en cluster et persistance des données pour les jetons de session web et mobiles. Définir une stratégie d’éviction allkeys-lfu pour conserver en mémoire les sessions fréquemment consultées. Intégrer le cache dans le même VNet et la même région que le niveau applicatif pour minimiser la latence.

Orchestrer le mouvement des données et construire l’analytique :

Utiliser Azure Data Factory pour copier les données opérationnelles (flux de modification de Cosmos DB et SQL MI) dans Azure Data Lake Storage Gen2. Employer un IR de VNet managé avec des points de terminaison privés pour empêcher l’exfiltration de données. Paramétrer les pipelines et utiliser des déclencheurs de fenêtre bascule pour garantir un traitement ordonné.

Activer l’analytique d’entreprise avec un contrôle élastique des coûts :

Dans Azure Synapse Analytics, utiliser un pool SQL serverless pour l’exploration ad hoc sur les données parquet et un pool SQL dédié pour les modèles BI organisés à haute simultanéité avec des performances prévisibles. Créer des pools Spark pour l’ingénierie des fonctionnalités sur le comportement de fidélité et écrire des tables Delta dans le lac de données pour l’interopérabilité entre Spark et SQL.

Gouvernance, sauvegardes et rétention :

Configurer les priorités de basculement automatique de Cosmos DB et surveiller les conflits en utilisant la stratégie LastWriterWins avec un champ d’horodatage. Pour Azure SQL Database et MI, vérifier les fenêtres PITR et activer la LTR pour respecter la rétention de conformité. Pour les instances Flexible Server prenant en charge des services OSS auxiliaires (par exemple, la télémétrie des magasins régionaux dans PostgreSQL), activer la haute disponibilité redondante interzone et configurer des réplicas en lecture pour le reporting.

Pourquoi ces services : La distribution mondiale et la cohérence réglable de Cosmos DB répondent aux interactions mondiales sensibles à la latence ; MI préserve les fonctionnalités complexes de SQL Server tout en fournissant des opérations managées ; les bases de données Business Critical fournissent une mise à l’échelle en lecture locale sans latence inter-régions ; Redis assure un accès aux sessions en moins d’une milliseconde pendant les pics de trafic ; ADF assure un mouvement de données sécurisé et gouverné depuis des réseaux privés ; Synapse combine l’analytique à la demande et provisionnée pour des informations rentables et évolutives. Cette composition respecte les SLO de performance pendant les promotions, réduit les tâches d’administration répétitives grâce au PaaS managé, et impose des limites claires de RTO/RPO et de conformité.

← Azure App Service et Calcul PaaS · Tous les domaines · Azure Monitor →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →