Microsoft Azure Cosmos DB Developer Specialty
225 questions de pratique
Dernière révision : April 2026
Notes personnelles et liens de ressources pour votre parcours d'étude
Filtrer par Certification
Le DP-420 est la certification spécialisée de Microsoft pour les développeurs qui créent des applications sur Azure Cosmos DB pour NoSQL. Il valide la capacité à concevoir et implémenter des modèles de données, à planifier la stratégie de partitionnement et de distribution, à intégrer Cosmos DB avec les services Azure environnants, à optimiser les performances et les coûts, et à maintenir les solutions Cosmos DB en production. L'audience cible est composée de développeurs professionnels et d'ingénieurs de données qui écrivent du Python, du .NET ou du JavaScript / TypeScript en utilisant le SDK Cosmos DB. L'examen est fortement axé sur le code et la modélisation : attendez-vous à 40–60 questions en 100 minutes, y compris des glisser-déposer de complétion de code (extraits de SDK, requêtes SQL API), des éléments de scénario et au moins une étude de cas.
Le domaine le plus vaste, représentant 37 %. Modélisation de documents pour les charges de travail NoSQL (dénormalisation, embedding vs référencement), conception de clés de partition, modèles de flux de modifications, politiques d'indexation (chemins inclus/exclus, index composites, index spatiaux) et configuration de TTL.
Environ 8 %. Réplication multi-région, écritures multi-région, compromis des niveaux de cohérence (forte / obsolescence liée / session / préfixe cohérent / éventuelle), politiques de résolution des conflits et modèles de distribution globale.
Environ 8 %. Processeur de flux de modifications, déclencheurs Azure Functions Cosmos DB, intégration Event Hubs / Kafka, magasin analytique Cosmos DB avec Azure Synapse Link et intégration avec Azure AI Search.
Environ 17 %. Dimensionnement et ajustement des unités de requête (RU), débit automatique vs manuel, optimisation de l'indexation, performances des requêtes et analyse des coûts avec le calculateur de capacité.
Environ 30 %. Sauvegarde et restauration (continues et périodiques), reprise après sinistre, sécurité (authentification Microsoft Entra, RBAC, clés gérées par le client, pare-feu IP, Private Endpoint), surveillance (Azure Monitor, journaux de diagnostic) et gestion des erreurs/tentatives du SDK.
Les services que vous rencontrerez à l'examen et pourquoi chacun compte.
API de document JSON native (anciennement API SQL) avec syntaxe de requête SQL-like, procédures stockées côté serveur, déclencheurs, UDFs et surface canonique pour les scénarios DP-420.
Pourquoi il est à l'examen : Le Domaine 1 (Conception et implémentation de modèles de données) est dominé par la modélisation de documents NoSQL-API, le choix des clés de partition et les compromis intégrés vs. référencés.
API MongoDB compatible avec le protocole filaire sur l'infrastructure Cosmos DB — prend en charge les modes vCore et basés sur les RU, ainsi que les pilotes Mongo standard et les opérateurs de pipeline d'agrégation.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 3 (Intégrer) testent la sélection de l'API — l'API Mongo est le choix favorisant la migration lorsque l'application utilise déjà Mongo.
API de colonne large compatible CQL sur Cosmos DB — keyspaces, tables, clés primaires avec colonnes de partition + de clustering et compatibilité avec les pilotes Cassandra.
Pourquoi il est à l'examen : Le Domaine 1 attend que vous mappiez la conception des clés primaires Cassandra (partition + clustering) sur le partitionnement Cosmos, et le Domaine 3 couvre les scénarios de pilotes/migration.
Postgres distribué (basé sur Citus) — fragmente les tables relationnelles entre les nœuds via des colonnes de distribution, avec des tables de référence et un routage de requêtes HTAP.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 2 (Distribution) testent les compromis relationnels/distribués — Cosmos pour PostgreSQL est la réponse pour les charges de travail SQL nécessitant une mise à l'échelle horizontale.
API Graph sur Cosmos DB — sommets et arêtes avec traversées de graphes de propriétés via le langage de requête Gremlin, avec écritures multi-régions et cohérence ajustable.
Pourquoi il est à l'examen : Le Domaine 1 couvre la modélisation de données de graphe (cardinalité des sommets/arêtes, stratégie de partition pour les graphes) comme cas d'utilisation canonique pour l'API Gremlin.
Surface d'API Table clé-valeur de niveau Premium — remplacement direct d'Azure Table Storage avec distribution globale, index secondaires et débit dédié.
Pourquoi il est à l'examen : Le Domaine 1 distingue l'API Table de NoSQL pour les charges de travail simples PartitionKey/RowKey où un modèle de document plus riche serait une suringénierie.
Journal ordonné et persistant des insertions et mises à jour par partition logique, consommé via la bibliothèque du Change Feed Processor ou le déclencheur Azure Functions Cosmos DB.
Pourquoi il est à l'examen : Le Domaine 3 (Intégrer) ancre l'intégration événementielle sur le Change Feed — distribution vers des vues matérialisées, des indexeurs de recherche et des services en aval.
Bibliothèques clientes natives avec exécution en masse, politiques de nouvelle tentative automatiques, opérations ponctuelles, lots transactionnels, requêtes LINQ + paramétrées et transport TCP en mode direct.
Pourquoi il est à l'examen : Le Domaine 3 (Intégrer) teste les modèles du SDK — options de requête, lectures ponctuelles vs requêtes, surcharges de ConsistencyLevel et concurrence PartitionKey + ETag.
Programmes JavaScript côté serveur limités à une seule partition logique — écritures par lots transactionnelles, déclencheurs pré/post et fonctions définies par l'utilisateur invocables depuis des requêtes SQL.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 4 (Optimiser) testent quand pousser la logique côté serveur pour l'atomicité vs la latence — la portée mono-partition est un élément perturbateur récurrent.
Bibliothèque d'importation/mise à jour en masse à haut débit qui maximise les RU provisionnés en regroupant par partition, en distribuant sur les connexions côté serveur et en exerçant une contre-pression sur les limites de débit.
Pourquoi il est à l'examen : Le Domaine 3 + le Domaine 4 citent Bulk Executor pour la migration initiale des données et les tâches de retraitement volumineuses — la réponse canonique pour "ingérer rapidement des millions de documents".
Cache de lecture intra-régional devant Cosmos DB via une passerelle dédiée — mise en cache des lectures ponctuelles et des requêtes avec contrôle `MaxIntegratedCacheStaleness` par requête.
Pourquoi il est à l'examen : Le Domaine 4 (Optimiser) désigne le Cache Intégré comme l'optimisation côté lecture pour réduire la consommation de RU/sec sur les chemins de lecture fréquents sans couche Redis externe.
Liaison serverless qui consomme le Change Feed à grande échelle — avec checkpoint via un conteneur de bail, et liaisons d'entrée/sortie pour une distribution entre conteneurs.
Pourquoi il est à l'examen : Le Domaine 3 (Intégrer) teste le déclencheur Functions Cosmos DB comme le chemin de moindre résistance pour les projections événementielles du Change Feed.
Magasin analytique HTAP (orienté colonne) synchronisé automatiquement depuis le magasin transactionnel, interrogé depuis Synapse Spark / SQL Serverless sans consommer de RU transactionnels.
Pourquoi il est à l'examen : Le Domaine 3 + le Domaine 4 s'attendent à Synapse Link lorsque les requêtes analytiques satureraient autrement la charge de travail transactionnelle — zéro-ETL est la réponse canonique.
Conteneurs de projection alternatifs maintenus automatiquement, construits à partir du Change Feed — pré-agrègent ou re-partitionnent les données pour des modèles de requête qui ne correspondent pas au conteneur de base.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 4 citent les vues matérialisées comme la réponse lorsqu'un conteneur ne peut pas satisfaire plusieurs modèles d'accès sans des requêtes coûteuses inter-partitions.
Débit par conteneur ou base de données partagée qui s'adapte entre 10 % et 100 % d'un maximum de RU/sec configuré, facturé à l'heure au pic observé chaque heure.
Pourquoi il est à l'examen : Le Domaine 4 (Optimiser) oppose le provisionnement manuel au provisionnement en autoscale pour les charges de travail en dents de scie — l'autoscale l'emporte lorsque le rapport pic/creux dépasse environ 5×.
Surface d'indexation définie en JSON — chemins inclus/exclus, index composites, index spatiaux et modes d'indexation cohérents vs paresseux pour les compromis requête/écriture.
Pourquoi il est à l'examen : Le Domaine 4 (Optimiser) teste fortement le réglage de la politique d'indexation — l'exclusion des chemins inutilisés permet des économies de RU et les index composites débloquent les requêtes ORDER BY.
Annuaire d'identité cloud ; les RBAC du plan de contrôle et du plan de données de Cosmos DB sont liés aux principaux Entra via des définitions de rôles intégrées et personnalisées et des attributions de rôles.
Pourquoi il est à l'examen : Le Domaine 5 (Maintenir) cite Entra ID + le RBAC du plan de données Cosmos comme le chemin recommandé pour s'éloigner de l'authentification par clé principale pour les charges de travail de production.
Magasin de clés géré prenant en charge le chiffrement des clés gérées par le client (CMK) de Cosmos DB au repos, avec versioning des clés, suppression logicielle et accès basé sur l'identité gérée.
Pourquoi il est à l'examen : Le Domaine 5 teste la rotation des CMK, le double chiffrement (géré par le service + CMK) et l'impact opérationnel de la révocation d'une clé gérée par le client.
Pipeline de télémétrie pour Cosmos DB — RU/sec, latence, consommation de RU normalisée, limitation et requêtes de journaux de diagnostic (DataPlaneRequests, QueryRuntimeStatistics) via KQL.
Pourquoi il est à l'examen : Le Domaine 5 (Maintenir) est dominé par l'alerte sur les erreurs 429, la consommation de RU normalisée et la mise en évidence des requêtes coûteuses à partir des journaux de diagnostic.
Couche de détection des menaces qui signale les accès anormaux au plan de données, les schémas d'exportation suspects et les tentatives d'injection SQL contre l'API NoSQL de Cosmos.
Pourquoi il est à l'examen : Le Domaine 5 fait référence à Defender pour Cosmos DB comme complément de surveillance de sécurité au RBAC + les ACLs réseau — lecture obligatoire pour tout scénario de détection de menaces.
$110k–$150k–$210k USD annuel
Cette fourchette couvre les développeurs backend de niveau intermédiaire à senior basés aux États-Unis pour lesquels la maîtrise de Cosmos DB est requise. Les ingénieurs seniors qui construisent des applications distribuées mondialement chez FAANG / dans la fintech dépassent souvent 230 000 $ en rémunération totale (TC). Les données salariales spécifiques à Cosmos DB sont plus rares que pour les rôles Azure généraux, étant donné le vivier de talents plus restreint ; les chiffres s'appuient sur des rôles adjacents de développeurs NoSQL / cloud.
Source : Rôles de développeurs backend / cloud sur levels.fyi 2025, U.S. BLS OEWS May 2024 (15-1252 software developers, 15-1242 database administrators), Glassdoor 2025. Les chiffres sont approximatifs ; la rémunération réelle dépend du rôle, de la région et de l'expérience.
Le DP-420 s'inscrit dans une niche plus étroite mais bien rémunérée — les applications qui nécessitent réellement un stockage NoSQL distribué mondialement, à faible latence et multi-API. La demande est concentrée dans les entreprises de jeux, les plateformes IoT, le commerce de détail / e-commerce à grande échelle et les cabinets de conseil partenaires de Microsoft. Les recruteurs l'utilisent comme un signal fort d'une compétence approfondie en modélisation et en réglage de Cosmos DB, ce qui confère une prime compte tenu du bassin limité de candidats qualifiés. Il s'associe naturellement à l'AZ-204 (Developer Associate) pour les développeurs Cosmos full-stack et aux rôles d'ingénierie AI-102 / AI où Cosmos DB sert de magasin de vecteurs et de données opérationnelles pour les architectures RAG. La demande a été stable, avec une croissance modeste due à l'expansion de Cosmos DB en tant que magasin de vecteurs pour les applications GenAI de 2024 à 2026.
Il n'y a pas de prérequis formels. Microsoft recommande une expérience de développeur de niveau praticien (un à deux ans de développement professionnel) ainsi qu'une familiarité pratique avec Cosmos DB. Les candidats sans exposition préalable à Cosmos DB nécessitent généralement un temps supplémentaire significatif. Les certifications AZ-900 et DP-900 sont des points d'entrée conceptuels utiles pour les candidats qui débutent avec Azure ou les plateformes de données NoSQL ; l'AZ-204 est hautement complémentaire, étant donné que le DP-420 suppose une maîtrise de niveau développeur Azure des modèles de SDK, de l'authentification Microsoft Entra et des identités gérées.
La maîtrise du C#, de Python ou de JavaScript / TypeScript est essentielle : les glisser-déposer de complétion de code montrent de véritables extraits de SDK Cosmos DB, les exemples .NET étant les plus représentés dans le matériel d'étude de Microsoft. Le parcours officiel Microsoft Learn couvre les cinq domaines en environ 30 à 40 heures. Une pratique concrète est indispensable — un abonnement Azure personnel avec un petit compte Cosmos DB (ou le niveau gratuit Cosmos DB) permet aux candidats de s'exercer à la conception de clés de partition, aux politiques d'indexation et aux scénarios de flux de modifications.
Le DP-420 se situe dans le niveau Spécialité et est généralement considéré comme modérément à très difficile — comparable à l'AZ-204 en termes de difficulté de complétion de code, avec une surface d'examen spécifique à Cosmos DB plus étroite mais plus approfondie. Prévoyez 70 à 110 heures d'étude sur 8 à 12 semaines pour les candidats ayant une expérience préalable de Cosmos DB ; beaucoup plus longtemps autrement. L'examen dure environ 100 minutes et comprend 40 à 60 questions sous forme de choix multiples, de réponses multiples, de glisser-déposer (y compris la complétion de code), de zones cliquables et d'études de cas. Les études de cas sont chronométrées séparément et ne peuvent pas être revisitées.
L'obstacle le plus courant est le choix de la clé de partition — l'examen présente systématiquement des modèles de charge de travail nuancés et attend des candidats qu'ils identifient la clé de partition qui distribue la charge uniformément tout en conservant les requêtes courantes sur une seule partition. Les questions sur la politique d'indexation (chemins inclus/exclus, index composites, analyse des coûts des requêtes) sont une autre zone de piège récurrente. En tant qu'examen de spécialité, le matériel d'étude tiers est plus rare ; reposez-vous principalement sur Microsoft Learn et la documentation de Cosmos DB.
Mise à jour la plus récente des compétences mesurées. Ajout de la couverture de la recherche vectorielle pour les charges de travail d'IA, extension du cadre de sauvegarde continue, modernisation du contenu Microsoft Entra et des clés gérées par le client. Microsoft actualise le DP-420 moins fréquemment que les examens basés sur les rôles, compte tenu de son statut de spécialité — généralement tous les 18 à 24 mois.
Restructuration selon la disposition actuelle en cinq domaines, extension de la couverture du flux de modifications et de Synapse Link, et intégration du contenu de sauvegarde continue.
Disponibilité générale initiale en tant que première certification Microsoft dédiée aux développeurs Cosmos DB. Le plan original se concentrait uniquement sur l'API SQL (Core) et mettait l'accent sur le partitionnement, le dimensionnement des RU et les modèles de SDK.
DP-420 (Microsoft Azure Cosmos DB Developer Specialty) est un examen de niveau Specialty un examen profondément spécialisé couvrant des sujets avancés dans un domaine étroit — attendez-vous à ce que l'expérience pratique soit un prérequis. La plupart des candidats ont besoin de 100 à 200 heures d'étude réparties sur 2 à 4 mois pour les examens de spécialité. Ceux-ci supposent une expérience pratique dans le domaine de spécialité. La plupart des candidats qui obtiennent des scores constamment supérieurs au seuil de réussite lors des examens pratiques réussissent dès leur première tentative.
La plupart des candidats ont besoin de 100 à 200 heures d'étude réparties sur 2 à 4 mois pour les examens de spécialité. Ceux-ci supposent une expérience pratique dans le domaine de spécialité. Le temps nécessaire pour réussir varie considérablement en fonction de l'expérience antérieure. Les ingénieurs ayant une expérience pratique en production avec la technologie sous-jacente en ont généralement besoin de moins ; les candidats novices sur la plateforme devraient viser la limite supérieure de cette fourchette.
DP-420 est une certification reconnue dans l'écosystème Azure et signale des connaissances validées aux employeurs, recruteurs et clients. Sa valeur en termes de temps et de coût dépend de votre rôle et de vos objectifs — elle est la plus avantageuse pour les ingénieurs cloud, architectes et consultants qui travaillent quotidiennement avec Azure ou souhaitent évoluer vers des rôles similaires.
Le score de réussite pour le DP-420 est de 700 / 1000. L'examen contient 50 questions et dure 1 h 40 min.
Les frais d'examen DP-420 sont de $165 USD. Les frais sont fixés par Azure et peuvent varier selon la région ; confirmez toujours le prix actuel sur la page de certification officielle de Azure avant de réserver.
Les certifications Microsoft basées sur les rôles expirent après 1 an mais peuvent être renouvelées gratuitement via une évaluation en ligne non supervisée sur Microsoft Learn, à partir de 6 mois avant l'expiration.
Oui. Vous pouvez passer l'examen en ligne (supervisé via le navigateur sécurisé du fournisseur, disponible 24h/24 et 7j/7 dans la plupart des régions) ou dans un centre de test Pearson VUE en personne pendant les heures ouvrables. Les deux formats utilisent les mêmes questions, la même limite de temps et le même score de réussite.
CertLabPro propose 15 modes d'étude à travers la banque de questions pratiques pour le DP-420. Le mode de simulation d'examen reproduit l'examen réel : 50 questions en 1 h 40 min, avec le même seuil de réussite de 700 / 1000. Le mode navigation vous permet de lire chaque Q&A de manière statique.