L’examen de certification Analytics Engineering dbt est plus étendu qu’il n’est approfondi. Se préparer requiert d’explorer des domaines de dbt que les praticiens configurent une fois puis ignorent, ainsi que des fonctionnalités exclusives à dbt Cloud même si elles ne sont pas utilisées au quotidien.
Ce que l’examen couvre
Le guide d’étude (mis à jour régulièrement par dbt Labs) couvre l’ensemble du périmètre : structure et configuration du projet, tous les types de matérialisation y compris les stratégies incrémentales, l’architecture en couches, les approches de test à chaque niveau, les conventions de documentation, les différences dbt Cloud vs Core, les packages, Jinja, les macros, la configuration des environnements et les patterns de déploiement.
Les questions ciblent fréquemment des configurations que les praticiens mettent en place une fois et revisitent rarement : les options de dbt_project.yml, le fonctionnement de profiles.yml entre les environnements, le comportement exact de on_schema_change pour les modèles incrémentaux, et la manière dont dbt Cloud gère les environnements par rapport à Core auto-hébergé. Les praticiens n’ayant d’expérience que sur un ou deux projets ont tendance à présenter des lacunes dans ces domaines.
L’expérience pratique
L’expérience en production est une préparation plus efficace que la lecture de documentation, car les décisions de déploiement sont retenues différemment des faits lus isolément. Choisir entre dbt Core et dbt Cloud, déboguer un modèle incrémental qui duplique silencieusement des données faute de unique_key, et restructurer un projet après que la logique métier s’est infiltrée dans les modèles de base produisent chacun une compréhension concrète de la raison d’être des couches que la documentation seule ne transmet pas.
Pour les praticiens sans beaucoup d’expérience en production, monter un vrai projet avec un jeu de données public — structure en trois couches, modèles incrémentaux avec différentes stratégies, tests à chaque couche, documentation générée et hébergée — expose les cas limites que l’examen teste.
Les points de blocage réels
Quelques domaines reviennent fréquemment comme pièges :
Comportement des modèles incrémentaux : Pas seulement « qu’est-ce qu’un modèle incrémental » mais ce qui se passe dans des scénarios précis. Que fait unique_key et que se passe-t-il si on l’omet ? Quand is_incremental() retourne-t-il true ? Quelle est la différence entre merge, insert_overwrite et delete+insert ? L’examen attend de la précision ici, pas seulement de la familiarité. La note Modèles incrémentaux dans dbt couvre le comportement au niveau des stratégies à connaître.
Stratégie de tests par couche : Des questions portent sur l’endroit où placer des tests spécifiques et pourquoi. Comprendre la stratégie de tests par couche est important, pas seulement savoir quels tests existent. Les tests de sources diffèrent des tests de modèles. Les tests génériques diffèrent des tests singuliers. Pourquoi utiliser la sévérité warn plutôt qu’error. L’examen teste le jugement, pas seulement la connaissance des fonctionnalités.
Décisions d’architecture de projet : Des questions portent sur le moment d’utiliser quelle structure de dossiers, comment organiser les modèles entre domaines, les conventions de nommage, et quand les modèles intermédiaires apportent de la valeur versus de la surcharge. Ces décisions sont faciles à rater quand on lit de la théorie sans avoir eu à les prendre sous de vraies contraintes.
Fonctionnalités spécifiques à dbt Cloud : Même si vous utilisez exclusivement dbt Core en pratique, l’examen couvre les fonctionnalités Cloud. Slim CI, la couche sémantique, Mesh, l’isolation des environnements, l’IDE web. La couverture est suffisamment large pour qu’on ne puisse pas l’esquiver.
Débogage et dépannage : Des questions portent sur la lecture des messages d’erreur, la traçabilité des problèmes de lignage, et la compréhension des causes de défaillance d’un modèle. C’est là que le temps passé dans le terminal paie. On développe des instincts sur ce qu’une erreur cryptique du warehouse dit réellement. Si vous n’avez pas passé de temps à déboguer des défaillances dbt, exercez-vous délibérément.
Ressources d’étude
La documentation officielle dbt est la ressource d’étude principale. Beaucoup de questions de certification vérifient si des pages de documentation spécifiques ont été lues attentivement — le comportement de full-refresh, les options exactes de on_schema_change, le fonctionnement de dbt source freshness, la hiérarchie de configuration de dbt_project.yml jusqu’aux configs de modèles individuels. Ces éléments sont documentés avec précision, et l’examen récompense la précision.
Les ressources communautaires (le forum Discourse dbt et Slack) sont utiles pour l’intuition et la reconnaissance de patterns réels, mais ne doivent pas être traitées comme des spécifications faisant autorité pour les besoins de l’examen.
Gestion du temps pendant l’examen
Gérez votre rythme. L’examen comporte suffisamment de questions pour que rester bloqué cinq minutes sur l’une d’elles ait un coût réel. Si une question est véritablement floue ou si vous n’êtes pas sûr, signalez-la et passez à la suivante. Revenez aux questions signalées à la fin avec le temps restant. Cela semble évident mais il est facile de se laisser entraîner à relire une question délicate quatre fois alors qu’il serait plus judicieux d’engranger d’abord les questions plus faciles.
Valeur de la certification
Le processus de préparation fait émerger des lacunes de connaissance que le travail en production seul peut ne pas exposer — des domaines où un modèle mental fonctionnel est légèrement erroné, ou où des approches habituelles diffèrent des approches recommandées. L’examen fournit également une raison concrète de lire la documentation officielle de manière approfondie, ce qui est utile en soi compte tenu de la précision requise pour de nombreuses décisions de configuration.