Microsoft AZ-305: Stockage de données et solutions de bases de données — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Solutions Architect Expert AZ-305 — 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

La conception du stockage de données sur Azure nécessite d’équilibrer la cohérence, la latence, la disponibilité, la complexité opérationnelle et le coût à travers de multiples options de bases de données et de stockage. La plateforme couvre des bases de données relationnelles entièrement gérées, du NoSQL distribué à l’échelle mondiale, du stockage d’objets avec gouvernance du cycle de vie des données, des lacs de données analytiques à haut débit et des caches en mémoire. Votre architecture doit commencer par les caractéristiques de la charge de travail — transactionnelle ou analytique, portée mondiale ou localité, rigidité du schéma, modèles de lecture/écriture, taille et vélocité — et sélectionner le service et la configuration qui correspondent à ces contraintes tout en répondant aux exigences de sécurité, de résilience et de gouvernance.

Services de données relationnelles sur Azure

Azure SQL Database propose deux modèles d’achat. Le modèle DTU combine le CPU, la mémoire et les E/S en une unité mixte à travers les niveaux De base, Standard et Premium ; il est simple mais opaque pour la planification de la capacité. Le modèle vCore sépare le calcul, la mémoire et le stockage, avec des choix de matériel, une mise à l’échelle prévisible et des leviers de coût tels que Azure Hybrid Benefit et la capacité réservée. Sous vCore, les principaux niveaux de service sont Usage général (calcul découplé et stockage distant, coût équilibré), Critique pour l’entreprise (SSD local avec des réplicas Always On pour des E/S à faible latence et un basculement rapide), et Hyperscale (architecture structurée en journaux avec des serveurs de pages et un stockage distribué pour une mise à l’échelle de plusieurs téraoctets et des opérations rapides basées sur des instantanés). Le mode Serverless pour Usage général met à l’échelle automatiquement le calcul entre un minimum et un maximum configurés et peut se mettre en pause automatiquement en cas d’inactivité ; vous payez par seconde de calcul et par stockage. Ceci est bien adapté aux charges de travail intermittentes ou de développement, mais entraîne un démarrage à froid et un préchauffage du cache à la reprise.

Les pools élastiques permettent à plusieurs bases de données de partager un budget de calcul et une marge de manœuvre pour les E/S, lissant les pics et réduisant les coûts pour de nombreuses petites bases de données à charge variable. Les pools existent dans les modèles DTU et vCore ; un dimensionnement correct exige de comprendre la concurrence globale et les limites de rafale par base de données pour éviter les effets de « voisin bruyant » (noisy-neighbor).

Les modèles de résilience d’Azure SQL incluent la géoréplication active et les groupes de basculement automatique. La géoréplication active maintient de manière asynchrone jusqu’à quatre bases de données secondaires lisibles dans n’importe quelle région Azure, le basculement étant initié par base de données. Les groupes de basculement automatique gèrent plusieurs bases de données comme une unité sur des serveurs logiques appairés, fournissent des points de terminaison d’écouteur en lecture/écriture et en lecture seule, et gèrent le basculement planifié ou non planifié avec des périodes de grâce configurables — idéal pour le SaaS multi-locataire. La redondance de zone est disponible dans les niveaux Critique pour l’entreprise (et Hyperscale) pour s’étendre sur plusieurs zones de disponibilité au sein d’une région, améliorant la tolérance aux pannes intra-région.

Azure SQL Managed Instance (MI) vise une compatibilité de près de 100 % avec SQL Server (SQL Agent, requêtes inter-bases de données, Linked Servers, CLR, Service Broker). Il s’exécute à l’intérieur de votre réseau virtuel sur un sous-réseau dédié et délégué (Microsoft.Sql/managedInstances). Les instances utilisent uniquement des adresses IP privées ; configurez les groupes de sécurité réseau et les tables de routage pour autoriser le trafic de gestion vers les plans de contrôle Azure et le trafic de données vers vos applications. Intégrez avec Azure Private DNS (ou un DNS personnalisé) pour que les clients résolvent le FQDN privé de l’instance managée. Pour la connectivité hybride et la migration, assurez une visibilité directe via un VPN de site à site ou ExpressRoute. Les chemins de migration incluent la sauvegarde/restauration native vers Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), des migrations en ligne ou hors ligne à l’aide de Azure Database Migration Service (DMS), et la réplication transactionnelle ou la copie des journaux de transactions (log shipping) le cas échéant. Le niveau de service Critique pour l’entreprise de MI ajoute un stockage à faible latence et une haute disponibilité ; Usage général offre un stockage rentable avec des disques distants.

Azure Database for PostgreSQL et MySQL Flexible Server offrent un contrôle précis sur les fenêtres de maintenance, l’arrêt/démarrage pour des économies de coûts, et l’isolement réseau via l’intégration VNet. Les options de haute disponibilité incluent un serveur de secours synchrone dans la même zone pour un basculement plus rapide et une haute disponibilité redondante interzone pour résister aux pannes de zone (réplication synchrone avec basculement automatique). Les réplicas en lecture (dans la région et, pour de nombreuses versions, inter-régions) déchargent les charges de travail de lecture et prennent en charge l’analytique en quasi-temps réel ; ils sont asynchrones et ne conviennent pas aux lectures strictement cohérentes. Sélectionnez les niveaux de calcul et de stockage en fonction des objectifs d’IOPS/latence, et planifiez la gestion du basculement de connexion dans les bibliothèques clientes.

Magasins non relationnels et distribués à l’échelle mondiale

Azure Cosmos DB est une base de données multimodèle, entièrement gérée et distribuée à l’échelle mondiale, avec une réplication mondiale clé en main et des lectures et écritures en quelques millisecondes au 99e centile. Choisissez l’API en fonction de l’adéquation à l’écosystème et du modèle de données : API Core (SQL) pour les documents et les requêtes de type SQL avec un support SDK riche ; API MongoDB pour la compatibilité avec le protocole filaire Mongo ; API Cassandra pour les charges de travail en colonnes larges ; API Gremlin pour le parcours de graphes ; et API Table pour les scénarios clé/attribut. Le débit est provisionné en unités de requête (RU), en utilisant des modes fixes ou de mise à l’échelle automatique ; concevez les partitions et l’indexation pour minimiser la consommation de RU.

Le partitionnement est fondamental. Sélectionnez une clé de partition à haute cardinalité qui répartit uniformément le stockage et le trafic, évite les partitions surchargées (« hot partitions ») et s’aligne sur vos modèles d’accès (par exemple, tenantId ou userId pour les écritures multi-locataires, ou une clé composite synthétique pour équilibrer les lectures). Les partitions logiques sont limitées en taille et en débit ; modélisez pour maintenir les ensembles de travail actifs (« hot working sets ») distribués. Vous ne pouvez pas modifier la clé de partition d’un conteneur après sa création ; les migrations nécessitent de nouveaux conteneurs et un déplacement des données.

La cohérence de Cosmos s’étend sur cinq niveaux réglables : Forte (linéarisable, RU/latence les plus élevées), Obsolescence limitée (« Bounded Staleness ») (décalage prévisible ou fenêtre de version), Session (centrée sur le client « reads-your-writes », défaut populaire), Préfixe cohérent (pas de lectures dans le désordre) et Éventuelle (disponibilité et performances maximales avec des anomalies potentielles). Choisissez des valeurs par défaut par compte et surchargez-les par requête si nécessaire. Les écritures multirégions permettent un véritable multi-maître pour des écritures globales à faible latence et une disponibilité plus élevée ; gérez la résolution des conflits via le Dernier rédacteur l’emporte (« Last-Writer-Wins ») (sur une propriété désignée), des stratégies personnalisées ou une logique applicative avec des procédures stockées et le flux de conflits (« conflict feed »).

Lorsque vous choisissez le bon magasin de données, faites correspondre les exigences aux capacités. L’intégrité relationnelle stricte, les jointures complexes et les garanties transactionnelles favorisent Azure SQL Database ou Managed Instance. L’échelle mondiale massive, le schéma flexible et l’accès géographique à faible latence favorisent Cosmos DB. Les problèmes de graphes (sociaux, recommandation, topologie de réseau) correspondent à l’API Gremlin de Cosmos DB ou aux fonctionnalités de graphe dans Azure SQL lorsque la colocation relationnelle est bénéfique. La télémétrie de séries chronologiques à haute ingestion, l’exploration ad hoc et l’analytique en quasi-temps réel s’alignent sur Azure Data Explorer. Les blobs non structurés, les médias et les charges utiles binaires volumineuses appartiennent à Azure Blob Storage ou ADLS Gen2, avec les métadonnées dans une base de données complémentaire.

Stockage d’objets et analytique

Azure Blob Storage est le fondement des données non structurées. Les niveaux d’accès alignent le coût du stockage sur les modèles d’accès : Chaud (« Hot ») pour un accès fréquent, Froid (« Cool ») pour un accès peu fréquent avec une rétention minimale de 30 jours, et Archive pour un stockage à froid à long terme avec une rétention minimale de 180 jours et une réhydratation de plusieurs heures. Les comptes de blobs de blocs Premium sur SSD offrent des charges de travail à faible latence et à transactions élevées, telles que les pipelines d’ingestion. Les stratégies de gestion du cycle de vie automatisent les transitions et les suppressions basées sur des règles — date de dernière modification, balises d’index de blob ou préfixes — réduisant les coûts sans intervention manuelle.

La réplication d’objets pour les blobs de blocs met en miroir de manière asynchrone les objets et leurs versions entre les comptes de stockage (dans des régions identiques ou différentes). Elle nécessite le versioning des blobs sur la source et la destination et est pilotée par une stratégie par paire de conteneurs, prenant en charge la conformité et la distribution multirégion tout en conservant l’indépendance par rapport aux choix de redondance au niveau du compte. L’immuabilité (WORM) est applicable au niveau du conteneur ou du blob via une rétention temporelle et des conservations légales (« legal holds »), avec des options comme allowProtectedAppendWrites pour les journaux en ajout seul. L’immuabilité au niveau de la version protège les états passés contre la falsification et les rançongiciels.

Azure Data Lake Storage Gen2 ajoute un espace de noms hiérarchique au stockage Blob, offrant de véritables répertoires, des renommages atomiques et des opérations de fichiers optimisées. Des ACL de type POSIX à granularité fine contrôlent l’accès aux niveaux des répertoires et des fichiers, avec des ACL d’accès et par défaut, et sont évaluées en parallèle avec Azure RBAC. Authentifiez-vous avec Azure AD et OAuth2 pour le moindre privilège et l’auditabilité. L’intégration analytique est native : Azure Synapse Analytics et Azure Databricks accèdent à ADLS Gen2 via le pilote ABFS avec un débit évolutif, tandis que des services comme Azure Data Factory, Azure Purview et Azure Machine Learning s’intègrent pour l’orchestration, la gouvernance et l’entraînement de modèles. Concevez des structures de dossiers et l’héritage des ACL pour isoler les domaines et prendre en charge la gouvernance multi-équipes, et tirez parti de fonctionnalités comme le flux de modification (« change feed ») et la suppression réversible (« soft delete ») pour la traçabilité et la récupération.

Mise en cache et accélération des performances

Azure Cache for Redis fournit un accès aux données en moins d’une milliseconde, du pub/sub et du verrouillage distribué. Les niveaux correspondent aux besoins de disponibilité et de mise à l’échelle. Basic est un nœud unique pour le dev/test. Standard ajoute un primaire/réplica à deux nœuds avec basculement automatique. Premium introduit le clustering sur plusieurs partitions (« shards »), la persistance (instantanés RDB et AOF), le support VNet et la géo-réplication dans une topologie active-passive. Enterprise et Enterprise Flash (Redis Enterprise) ajoutent la géo-réplication Active-Active utilisant des CRDT pour les écritures multirégions, des empreintes mémoire plus grandes, des performances multithread et le support de modules ; Flash augmente la DRAM avec du NVMe pour des caches massifs à moindre coût. Choisissez la politique d’éviction en fonction du TTL des clés et de la charge de travail : allkeys-lru/allkeys-random lorsque toutes les clés n’ont pas de TTL ; volatile-lru/volatile-ttl lorsque seules les clés expirant doivent être évincées ; et noeviction lorsque les échecs d’écriture sont acceptables par rapport à l’éviction. La persistance réduit la perte de données lors du basculement au prix d’une surcharge d’E/S et de latence ; ne l’activez que lorsque c’est nécessaire et ajustez les intervalles des instantanés.

Intégrez Redis comme un cache « cache-aside » pour les résultats de requêtes de base de données, l’état de session et les compteurs de limitation de débit. Assurez un remplissage idempotent, appliquez des TTL appropriés et implémentez des disjoncteurs (« circuit breakers »). Pour les caches en cluster, partitionnez les clés de manière déterministe ; pour l’Enterprise Active-Active, testez la sémantique de résolution des conflits.

Modèles de sécurité, d’accès et de résilience

La délégation d’accès à Azure Storage utilise des jetons SAS et des stratégies. Une SAS de service accorde un accès limité à une ressource spécifique (conteneur, blob, partage de fichiers, file d’attente ou table). Une SAS de compte couvre plusieurs services dans le compte et est puissante ; protégez-la soigneusement. Une SAS de délégation d’utilisateur (service Blob uniquement) dérive d’Azure AD et d’une clé de délégation d’utilisateur, permettant un contrôle d’accès par utilisateur sans les clés de compte — idéal pour les applications multi-locataires et les octrois de courte durée. Les stratégies d’accès stockées (sur les conteneurs, partages, files d’attente et tables) lient les jetons SAS à une stratégie côté serveur afin que vous puissiez révoquer ou raccourcir l’accès sans effectuer de rotation des clés de compte ; une SAS sans stratégie d’accès stockée ne peut être révoquée qu’en faisant expirer le jeton ou en effectuant une rotation des clés.

Pour le chiffrement, Azure Storage utilise par défaut le chiffrement côté service. Les clés gérées par le client (CMK) stockées dans Azure Key Vault ou Managed HSM offrent un contrôle centralisé du cycle de vie des clés et une auditabilité. Les étendues de chiffrement permettent d’utiliser différentes CMK au sein du même compte de stockage par conteneur ou par préfixe, prenant en charge le chiffrement par locataire. Pour un contrôle par blob côté client, des clés fournies par le client (CPK) peuvent être fournies lors des requêtes. Combinez les CMK au niveau du compte ou de l’étendue avec les CPK selon les besoins pour l’isolement réglementaire.

La sécurité et la résilience d’Azure SQL s’appuient sur les niveaux de plateforme et les fonctionnalités de réplication déjà décrits. Utilisez des groupes de basculement automatique pour un basculement inter-régional coordonné et des points de terminaison d’écouteur captifs, et activez la redondance de zone là où elle est disponible pour résister aux pannes de zone. Pour les données sensibles, appliquez le masquage dynamique des données pour obfusquer les PII dans les résultats de requêtes pour les utilisateurs non privilégiés, et envisagez Always Encrypted avec enclaves sécurisées pour la protection côté client des colonnes lorsque les administrateurs ne doivent pas pouvoir visualiser le texte en clair. Surveillez les objectifs RPO/RTO par rapport au comportement de réplication de votre niveau et testez le basculement régulièrement.

Lors de la planification d’architectures de bout en bout, unifiez l’identité (Azure AD pour SQL, le stockage et l’analytique), appliquez le moindre privilège avec RBAC et les ACL, utilisez Private Link ou l’intégration de VNet pour garder les données hors de l’internet public, et mettez en œuvre des stratégies de cycle de vie, d’immuabilité et de réplication pour atteindre les objectifs de rétention et de DR.

Scénario de problème pratique

Contoso Retail lance une plateforme de e-commerce mondiale avec un trafic diurne volatile, des contrôles stricts sur les PII, des médias de produits à l’échelle du pétaoctet et une personnalisation quasi en temps réel. Ils exigent des lectures à faible latence dans le monde entier, un temps d’arrêt minimal et une analytique des données gouvernée.

Placer les bases de données transactionnelles de catalogue et de commandes sur Azure SQL Database en utilisant le modèle vCore :

Sélection du niveau : Business Critical pour les commandes (stockage à faible latence et basculement rapide) et General Purpose serverless pour le catalogue (pics de trafic avec des fenêtres d’inactivité).
Pourquoi : vCore fournit un dimensionnement prévisible et l’Hybrid Benefit ; Business Critical répond aux exigences de latence/HA pour les commandes ; serverless minimise le coût de calcul pendant les périodes de faible activité.

Configurer un groupe de basculement automatique entre des régions appairées pour les deux bases de données et activer la redondance de zone :

Pourquoi : Un écouteur de lecture/écriture unifié simplifie le basculement de l’application ; la redondance de zone protège contre les pannes de zone ; les réplicas inter-régionaux répondent aux besoins de DR et offrent une mise à l’échelle en lecture pour le reporting.

Stocker les images et vidéos des produits dans Azure Blob Storage (general-purpose v2) avec gestion du cycle de vie et réplication d’objets :

Stratégie : Niveau chaud (Hot) pour les éléments actifs, froid (Cool) après 30 jours, archive (Archive) après 180 jours ; répliquer vers une région secondaire via la réplication d’objets.
Pourquoi : Minimise le coût de stockage au fil du temps tout en fournissant une distribution régionale asynchrone indépendante de la redondance du compte ; répond aux exigences de rétention avec l’immuabilité pour les actifs juridiques (WORM basé sur le temps).

Construire le service de profil client et de panier d’achat sur Azure Cosmos DB (API Core) avec des écritures multirégions et une cohérence de session (Session) :

Conception : Partitionner par userId pour distribuer les écritures ; activer les RU à mise à l’échelle automatique.
Pourquoi : Le multi-maître offre des écritures à faible latence pour une audience mondiale et une haute disponibilité ; la cohérence de session garantit la lecture de ses propres écritures (read-your-writes) par utilisateur avec de solides garanties UX et une utilisation efficace des RU.

Introduire Azure Cache for Redis Enterprise pour l’état de session, la mise en cache des détails de produits et la limitation de débit :

Mode : Clustering avec géo-distribution Active-Active pour les écritures multirégions.
Pourquoi : L’accès en moins d’une milliseconde et la résolution de conflits basée sur les CRDT maintiennent la cohérence des sessions et des compteurs entre les régions sans un maître d’écriture unique.

Déposer les journaux de parcours de navigation (clickstream) et opérationnels dans Azure Data Lake Storage Gen2 avec des espaces de noms hiérarchiques et des ACL POSIX :

Intégration : L’ingestion en flux écrit dans des dossiers organisés ; Databricks et Synapse lisent via ABFS ; activer le flux de modification (change feed) et la suppression réversible (soft delete).
Pourquoi : Les ACL précises au niveau des répertoires/fichiers prennent en charge la gouvernance multi-équipes ; l’espace de noms hiérarchique optimise les opérations sur les fichiers ; l’intégration native avec l’analytique réduit le temps d’obtention des informations.

Utiliser Azure Database for PostgreSQL Flexible Server pour le microservice de recommandation :

HA : Standby synchrone redondant interzone ; provisionner des réplicas en lecture pour l’expérimentation de fonctionnalités.
Pourquoi : Le riche écosystème d’extensions Postgres et les capacités JSONB conviennent au service ; la HA gérée maintient un RTO bas ; les réplicas déchargent les lectures.

Sécuriser l’accès avec des SAS de délégation d’utilisateur pour le téléversement temporaire de médias et des CMK avec des étendues de chiffrement par locataire :

Pourquoi : Élimine l’exposition des clés de compte et permet un isolement cryptographique et une auditabilité par locataire.

Migrer les données de commandes héritées depuis un SQL Server sur site vers Azure SQL Managed Instance pour le traitement d’archivage et les tâches pilotées par agent :

Étapes : Évaluer avec Data Migration Assistant ; effectuer une migration en ligne via DMS ; se connecter via ExpressRoute.
Pourquoi : MI préserve les travaux SQL Agent et les opérations inter-bases de données, facilitant la modernisation tout en gardant les charges de travail d’archivage proches des données cloud.

Cette conception répond aux exigences de performance mondiale via les écritures multirégions de Cosmos DB et Redis Enterprise, applique la gouvernance avec les ACL d’ADLS Gen2 et l’immuabilité du stockage, assure l’intégrité transactionnelle et un basculement rapide avec les niveaux Azure SQL et les groupes de basculement automatique, et optimise les coûts grâce au calcul serverless et aux stratégies de cycle de vie.

← Identité · Tous les domaines · Calcul et architecture applicative →

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