Microsoft AZ-204: Stockage Azure et Stockage Blob — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — 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.

Aperçu

Azure Storage fournit un stockage cloud durable et massivement évolutif pour les données non structurées et structurées. Pour le développement d’applications, il est essentiel de sélectionner le bon type de compte de stockage, de configurer la redondance pour atteindre les objectifs de RTO/RPO, de choisir le bon type de blob et le bon niveau d’accès pour optimiser les coûts/performances, et de sécuriser l’accès avec Azure AD et les SAS. Utilisez des politiques de cycle de vie pour automatiser le déplacement des données entre les niveaux, hébergez des sites web statiques directement depuis le stockage Blob lorsque c’est approprié, et utilisez Azure Files et Queue Storage lorsque la sémantique de fichier ou un découplage basé sur des messages est requis.

Types de comptes de stockage et principes fondamentaux de la redondance

Le type de compte Usage général v2 (GPv2) est le type de compte standard pour la plupart des charges de travail. Il prend en charge les blobs, les fichiers, les files d’attente et les tables, tous les niveaux d’accès, la gestion du cycle de vie et les fonctionnalités les plus récentes. Les anciens comptes BlobStorage n’exposent que le service Blob et la hiérarchisation, mais ils ne disposent pas de l’étendue des fonctionnalités et des optimisations de coûts que l’on trouve dans GPv2 ; les nouveaux déploiements devraient préférer GPv2. Les comptes FileStorage sont des comptes premium, basés sur des SSD, dédiés à Azure Files, offrant des IOPS et un débit constants à faible latence pour les charges de travail de fichiers d’entreprise (par ex., partages de profils, applications métier). Choisissez FileStorage lorsque vous avez besoin de performances premium pour les partages SMB/NFS ; sinon, GPv2 est le choix par défaut.

Les choix de redondance déterminent la durabilité et la disponibilité des données à travers les domaines de défaillance :

LRS (Stockage localement redondant) stocke de manière synchrone trois copies au sein d’un seul centre de données. Coût le plus bas, aucune protection zonale ou régionale. À utiliser pour le dév/test, les charges de travail éphémères ou lorsque vous disposez d’une réplication de couche supérieure.
ZRS (Stockage redondant interzone) réplique de manière synchrone entre les zones de disponibilité d’une région, protégeant contre une panne de zone avec une haute disponibilité et un RPO nul. À choisir pour la production dans les régions zonales nécessitant une résilience intra-régionale.
GRS (Stockage géo-redondant) stocke trois copies synchrones dans la région primaire (comme LRS) et réplique de manière asynchrone vers une région secondaire jumelée (LRS là-bas). Le RPO typique est inférieur à 15 minutes ; la région secondaire n’est pas lisible par défaut. À sélectionner pour la reprise après sinistre lorsque vous n’avez pas besoin d’un accès en lecture.
RA-GRS (Stockage géo-redondant avec accès en lecture) ajoute un accès en lecture à la région secondaire via des points de terminaison -secondary. À utiliser lorsque vous avez besoin d’une tolérance aux pannes inter-régions et de charges de travail principalement en lecture lors d’incidents primaires, ou pour des lectures de proximité géographique où la cohérence à terme est acceptable.

Lorsque vous avez besoin à la fois d’une protection contre les pannes de zone et d’une reprise après sinistre (DR) inter-régions, envisagez de coupler ZRS localement avec un modèle de compte géo-répliqué supplémentaire au niveau de la solution. Planifiez les tests de basculement de compte, comprenez les basculements de points de terminaison DNS et validez les politiques de nouvelle tentative de l’application pour gérer la cohérence à terme et le décalage d’horloge lors d’événements géographiques.

Modèle de données Blob, niveaux et gestion du cycle de vie

Il existe trois types de blobs avec des sémantiques distinctes. Les blobs de blocs sont optimisés pour le streaming et la lecture aléatoire de gros objets tels que des images, des vidéos et des sauvegardes. Les téléversements sont découpés en blocs et validés, ce qui permet des téléversements parallèles et des nouvelles tentatives efficaces. Les blobs d’ajout sont optimisés pour les charges de travail en ajout seul, comme la télémétrie et la capture de logs ; seules les opérations d’ajout sont autorisées, ce qui simplifie la concurrence. Les blobs de pages exposent des pages alignées sur 512 octets pour les E/S de lecture/écriture aléatoires et servent de support aux disques durs virtuels Azure (VHD) utilisés par les disques des machines virtuelles Azure ; ils sont le seul type de blob pris en charge pour les disques IaaS et les charges de travail avec d’importantes E/S aléatoires.

Les niveaux d’accès aux blobs contrôlent les coûts et les performances. Le niveau Chaud est optimisé pour un accès fréquent avec la latence de lecture/écriture la plus faible et le coût de stockage le plus élevé. Le niveau Froid cible les données rarement consultées et conservées pendant au moins 30 jours, avec un coût de stockage plus faible mais des coûts de transaction/lecture plus élevés et des frais de rétention minimale. Le niveau Archive est le niveau le moins cher pour la conservation à long terme ; les objets sont hors ligne et doivent être réhydratés vers le niveau chaud ou froid avant d’être lus. La réhydratation peut être demandée avec une priorité standard ou élevée, en arbitrant entre le coût et la vitesse. Vous pouvez définir un niveau d’accès par défaut au niveau du compte (chaud ou froid) et le remplacer pour chaque blob ; le niveau archive ne peut être défini que par blob.

Les politiques de gestion du cycle de vie automatisent le déplacement et la rétention des données pour contrôler les coûts et répondre aux exigences de gouvernance. Au niveau du compte, définissez des règles qui :

Font passer les blobs ou les versions/instantanés de blob au niveau froid ou archive après N jours depuis la dernière modification
Suppriment les blobs, les instantanés ou les versions après des seuils d’âge
Filtrent par préfixe de conteneur et par balises d’index de blob pour cibler des ensembles de données spécifiques (par exemple, balise env=prod et policy=retention-7y) Combinez les règles de cycle de vie avec le versioning et la suppression réversible (soft delete) pour vous protéger contre les suppressions accidentelles tout en appliquant la rétention. N’oubliez pas que le niveau archive a une durée de rétention minimale et des frais de suppression anticipée ; concevez des politiques pour minimiser les réhydratations inutiles.

Pour le suivi des modifications et le traitement en aval, activez le flux de modification (change feed) du compte de stockage pour consommer un journal ordonné et immuable des opérations de création, de mise à jour, de suppression et de copie de blobs. Cela prend en charge la conformité et les processeurs asynchrones qui nécessitent une sémantique de type exactly-once ou at-least-once avec création de points de contrôle (checkpointing).

L’hébergement de sites web statiques dans le stockage Blob expose un conteneur spécial $web servi via un point de terminaison web dédié. Configurez les documents d’index et d’erreur et publiez directement les ressources statiques. Le point de terminaison du site web statique fournit un accès en lecture anonyme au contenu du site, indépendamment du paramètre d’accès public du blob ; l’accès via le point de terminaison du blob peut rester désactivé. Pour les domaines personnalisés et l’accélération globale, placez le point de terminaison derrière Azure Front Door ou Azure CDN. Les points de terminaison privés ne sont pas pris en charge pour le point de terminaison du site web statique ; utilisez un service en périphérie (edge service) pour sécuriser et accélérer la livraison lorsque l’accès privé est requis.

Sécurité, identité et contrôle d’accès aux données

Azure Storage chiffre les données au repos par défaut avec AES 256 bits en utilisant des clés gérées par Microsoft. Pour un contrôle plus strict, activez les clés gérées par le client (CMK) stockées dans Azure Key Vault ou Managed HSM pour régir la rotation des clés et la séparation des tâches ; accordez à l’identité managée du compte de stockage les autorisations d’encapsulation/désencapsulation (wrap/unwrap). Pour les charges de travail hautement réglementées, activez le chiffrement d’infrastructure pour appliquer une seconde couche de chiffrement indépendante. Associez le chiffrement côté serveur au chiffrement côté client si un contrôle cryptographique de bout en bout est requis.

L’autorisation Azure AD intègre le plan de données avec le RBAC pour les services Blob et Queue ainsi que pour l’API REST de Files. Attribuez des rôles de moindre privilège tels que Storage Blob Data Reader ou Storage Blob Data Contributor à des identités managées, des utilisateurs ou des groupes. Dans le code, utilisez DefaultAzureCredential pour acquérir des jetons OAuth 2.0 et éviter d’incorporer des clés. Pour l’accès SMB à Azure Files, activez l’authentification basée sur l’identité en utilisant Active Directory : joignez le compte de stockage à un AD DS sur site (via Azure AD Kerberos pour les identités hybrides) ou à Azure AD DS, et utilisez les listes de contrôle d’accès (ACL) NTFS et le RBAC (par ex., Storage File Data SMB Share Contributor) pour l’autorisation au niveau du partage. Assurez-vous d’utiliser SMB 3.x avec le chiffrement en transit et envisagez d’utiliser des Points de terminaison privés (Private Endpoints), un VPN ou ExpressRoute pour traverser les réseaux qui bloquent le port 445.

Les Signatures d’accès partagé (SAS) délèguent un accès limité dans sa portée et dans le temps sans exposer les clés du compte. Une SAS de service accorde l’accès à un service et une ressource spécifiques (par ex., un seul blob ou conteneur) avec des autorisations précises et des heures de début/d’expiration. Une SAS de compte fonctionne au niveau du compte, couvrant plusieurs services (blobs, files, queues, tables) et des API de service telles que la liste ou la création. Une SAS de délégation d’utilisateur est spécifique à Blob storage et est signée avec une clé de délégation d’utilisateur obtenue via Azure AD pour un principal disposant du RBAC approprié ; elle supprime la dépendance à la clé et centralise le contrôle d’accès dans Azure AD. Appliquez des contraintes, notamment des plages d’adresses IP, des protocoles autorisés (HTTPS uniquement) et des durées de vie courtes. Les stratégies d’accès stockées centralisent les contraintes des SAS et permettent la révocation en mettant à jour ou en supprimant la stratégie ; elles s’appliquent aux SAS de service et aux SAS de compte. La SAS de délégation d’utilisateur n’utilise pas de stratégies d’accès stockées ; la révocation s’effectue en faisant expirer la clé de délégation d’utilisateur ou en supprimant les attributions de rôles Azure AD. Préférez toujours les SAS aux clés de compte, et privilégiez les SAS de délégation d’utilisateur lorsque votre application peut acquérir des jetons Azure AD.

Essentiels d’Azure Files et de Queue Storage

Azure Files fournit des partages SMB entièrement gérés et une option NFS pour les scénarios POSIX. Utilisez les partages SMB pour les migrations lift-and-shift et la compatibilité des applications. Les comptes Premium FileStorage offrent des performances prévisibles à faible latence, tandis que les partages standard sont économiques pour les données de fichiers à usage général. Gérez les partages et les fichiers via des clients SMB ou l’API REST/les SDK. Azure File Sync permet des services de fichiers hybrides en mettant en cache un partage cloud sur Windows Server, offrant des performances locales et hiérarchisant les données froides vers le cloud, une synchronisation multi-site, et une sauvegarde/reprise après sinistre hors site sans les cycles de renouvellement traditionnels des NAS. Combinez l’identité basée sur Azure AD avec les ACL NTFS pour appliquer le moindre privilège, et utilisez des points de terminaison privés (Private Endpoints) pour contenir le risque d’exfiltration de données.

Azure Queue Storage permet des flux de travail applicatifs découplés et résilients. Chaque message peut atteindre 64 Ko (les charges utiles plus volumineuses doivent référencer des URI de blob). La durée de vie du message (TTL) détermine son expiration automatique ; spécifiez une valeur positive allant de quelques secondes à sept jours, ou -1 pour aucune expiration. Lorsqu’un worker récupère un message, celui-ci devient invisible pendant son délai de visibilité. Si le traitement échoue et que le message n’est pas supprimé avant l’expiration du délai, il réapparaît pour un autre consommateur. Ajustez le délai de visibilité pour qu’il dépasse le temps de traitement dans le pire des cas, et utilisez des gestionnaires idempotents ainsi qu’un backoff exponentiel pour réduire la contention. Suivez le nombre de retraits de la file d’attente (dequeue count) pour détecter les messages empoisonnés ; lorsqu’il dépasse un seuil, déplacez le message vers une file d’attente dédiée aux messages empoisonnés pour la mise en quarantaine et l’analyse. Les déclencheurs de file d’attente Azure Functions implémentent ce modèle automatiquement avec une file d’attente -poison. Pour des besoins de débit plus élevé ou FIFO avec des garanties d’ordre, envisagez les files d’attente Service Bus ; sinon, Azure Queue Storage est léger et rentable.

Scénario de problème pratique

National Geographic doit publier un microsite de photographie à fort trafic avec un traitement d’images serverless, un stockage optimisé en termes de coûts et un accès hybride pour un outil éditorial sur site. Ils ont également besoin de liens de partage sécurisés et à durée limitée pour les agences partenaires, ainsi que d’une gestion robuste des messages pour le traitement en arrière-plan.

Créez un compte de stockage GPv2 avec RA-GRS

Pourquoi : GPv2 débloque les services Blob, Files et Queue avec des fonctionnalités de cycle de vie et de hiérarchisation. RA-GRS offre une tolérance aux pannes interrégionales et un accès en lecture aux points de terminaison secondaires pour la continuité des ressources principalement lues lors d’incidents régionaux.

Activez l’hébergement de site web statique et déployez les ressources du site dans le conteneur $web

Pourquoi : Les sites web statiques Blob éliminent la gestion des serveurs web, fournissent des lectures à faible latence depuis le niveau d’accès chaud (Hot) et s’adaptent à l’échelle mondiale. Associez-le plus tard à Azure Front Door pour les domaines personnalisés, le WAF et la mise en cache en périphérie.

Stockez les images RAW originales en tant que blobs de blocs ; la télémétrie à écriture unique en tant que blobs d’ajout

Pourquoi : Les blobs de blocs prennent en charge les chargements volumineux et parallèles ainsi que la livraison efficace de dérivés optimisés pour le web. Les blobs d’ajout simplifient les écritures de journaux simultanées à partir des pipelines de traitement sans conflits.

Définissez des stratégies de cycle de vie pour déplacer les originaux vers le niveau d’accès froid (Cool) après 30 jours et vers l’archive (Archive) après 180 jours ; supprimez les versions de plus d’un an

Pourquoi : La hiérarchisation automatisée réduit les coûts de stockage en fonction des modèles d’accès tout en conservant les copies de conformité. Le nettoyage des versions et des instantanés (snapshots) contrôle l’encombrement sans intervention manuelle.

Sécurisez l’accès aux données avec Azure AD et une SAS de délégation d’utilisateur pour les partenaires

Pourquoi : Attribuez le rôle Lecteur des données Blob du stockage (Storage Blob Data Reader) à une identité managée dans le service de partage, obtenez des clés de délégation d’utilisateur et créez des jetons SAS éphémères, uniquement HTTPS, avec des restrictions d’adresse IP. Cela évite de distribuer les clés de compte et lie l’autorisation à Azure AD.

Activez les clés gérées par le client avec Key Vault et le chiffrement d’infrastructure

Pourquoi : Les clés CMK (Customer-Managed Keys) satisfont aux exigences de conformité et de rotation plus strictes, tandis que le double chiffrement offre une défense en profondeur pour les médias sensibles.

Intégrez Azure Queue Storage pour le traitement d’images en arrière-plan avec un déclencheur de file d’attente Azure Functions ; définissez le délai de visibilité pour qu’il dépasse le temps de traitement maximal et configurez la gestion des messages empoisonnés

Pourquoi : Les files d’attente découplent le chemin de chargement du calcul. Le délai de visibilité empêche le travail en double, et le runtime Functions achemine automatiquement les éléments ayant échoué vers une file d’attente -poison pour investigation.

Publiez l’outillage éditorial via Azure Files en utilisant un compte Premium FileStorage et Azure File Sync vers un Windows Server sur site

Pourquoi : Les éditeurs bénéficient d’un accès SMB à faible latence avec des ACL NTFS et une authentification basée sur l’identité via AD, tandis qu’Azure File Sync fournit une mise en cache locale et une hiérarchisation cloud. Le niveau premium garantit des performances constantes pour les charges de travail interactives.

Placez le site web statique derrière Azure Front Door et activez la mise en cache et le HTTPS personnalisé

Pourquoi : Les POP en périphérie (Edge POPs) réduisent la latence à l’échelle mondiale, les domaines personnalisés répondent aux exigences de marque, et le WAF ajoute de la sécurité sans modifier le backend de stockage.

Activez le flux de modification (change feed) du compte de stockage et archivez-le dans un magasin de conformité

Pourquoi : Un journal immuable et ordonné des modifications de blobs prend en charge l’analytique en aval, l’audit et la relecture pour des pipelines de contenu reproductibles.

← Azure Functions et Informatique sans serveur · Tous les domaines · Azure Cosmos DB →

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