Questions gratuites ANALYTICS-ENG — dbt Certified Analytics Engineer
Téléchargez gratuitement 60 questions d'entraînement pour la certification ANALYTICS-ENG proposée par dbt Labs. Toutes les questions sont accompagnées de corrections détaillées avec explications techniques.
Caractéristiques de l'examen blanc
| Code de certification | ANALYTICS-ENG |
| Éditeur | dbt Labs |
| Nombre de questions | 60 |
| Type | QCM avec 4 réponses possibles |
| Niveau | associate |
| Catégorie | Data |
| Prix | 100% gratuit |
Aperçu de 8 questions représentatives
Voici un échantillon aléatoire de 8 questions tirées de notre base d'entraînement ANALYTICS-ENG. Pour accéder aux 60 questions complètes, lancez l'examen blanc gratuitement.
Question 1
Votre entreprise possède un modèle dbt nommé fct_subscriptions matérialisé en tant que table incrémentale. Le modèle utilise la configuration suivante :
{{ config(
materialized='incremental',
unique_key='subscription_id'
) }}
SELECT * FROM {{ ref('stg_subscriptions') }}
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}
Que représente {{ this }} dans ce contexte et pourquoi ne peut-on pas utiliser ref() à sa place ?
- A. {{ this }} est un alias pour {{ ref('fct_subscriptions') }} et les deux sont interchangeables dans tous les contextes
- B. {{ this }} référence la table cible actuelle du modèle dans le data warehouse sans créer de dépendance circulaire dans le DAG, contrairement à ref() qui créerait un cycle
- C. {{ this }} référence une table temporaire créée par dbt pendant l'exécution incrémentale
- D. {{ this }} référence la version précédente du modèle stockée dans le manifest dbt
Question 2
Un ingénieur analytics doit faire référence à une table source brute dans plusieurs modèles dbt. Il hésite entre utiliser directement le nom complet de la table (database.schema.table_name) dans ses requêtes et utiliser la fonction {{ source() }}. Quel est l'avantage principal d'utiliser la fonction source() ?
- A. La fonction source() améliore les performances des requêtes en créant un cache local de la table source dans dbt.
- B. La fonction source() permet de définir la table source comme une dépendance dans le DAG de dbt, active les tests de freshness, et centralise la configuration du mapping base/schéma/table dans les fichiers YAML.
- C. La fonction source() est obligatoire dans dbt ; utiliser un nom de table en dur provoque une erreur de compilation.
- D. La fonction source() crypte automatiquement les données sensibles de la table source avant qu'elles ne soient utilisées dans les modèles downstream.
Question 3
Votre entreprise possède un modèle dbt 'fct_monthly_revenue' qui agrège les revenus mensuels. Ce modèle est référencé par 15 autres modèles downstream. L'équipe data décide de changer sa matérialisation de 'table' à 'incremental' avec une stratégie 'merge' et une unique_key. Parmi les impacts suivants, lequel est VRAI concernant les modèles downstream qui utilisent {{ ref('fct_monthly_revenue') }} ?
- A. Tous les modèles downstream doivent être modifiés pour ajouter un filtre is_incremental() dans leurs requêtes
- B. Les modèles downstream n'ont besoin d'aucune modification car ref() résout vers la relation matérialisée finale, quelle que soit la stratégie de matérialisation
- C. Les modèles downstream nécessitent un full refresh obligatoire après le changement de matérialisation du modèle upstream
- D. La fonction ref() génèrera une erreur car elle ne supporte pas la résolution vers des modèles incrémentaux avec stratégie merge
Question 4
Votre équipe utilise dbt avec un data warehouse Snowflake. Un data analyst signale que le modèle 'fct_revenue' produit parfois des montants négatifs pour la colonne 'total_revenue', ce qui est métier-impossable. Vous souhaitez créer un test singulier (singular test) qui échoue si des revenus négatifs existent, tout en stockant les résultats du test dans le schéma d'audit de dbt pour analyse ultérieure. Quelle combinaison d'actions est correcte ?
- A. Créer le fichier tests/assert_no_negative_revenue.sql contenant un SELECT des lignes en violation, et configurer 'store_failures: true' dans le fichier YAML de propriétés ou via un bloc config() dans le fichier SQL
- B. Créer le fichier tests/assert_no_negative_revenue.sql et ajouter 'store_failures: true' dans le fichier dbt_project.yml au niveau global uniquement, car les tests singuliers ne supportent pas la configuration individuelle
- C. Créer le fichier macros/assert_no_negative_revenue.sql avec un bloc {% test %} et configurer 'store_failures' via le flag --store-failures dans la ligne de commande exclusivement
- D. Créer le fichier tests/assert_no_negative_revenue.sql et utiliser la commande 'dbt test --store-failures --select assert_no_negative_revenue' car store_failures ne peut être configuré que via la CLI
Question 5
Dans un projet dbt, vous avez le modèle suivant dans models/intermediate/int_revenue_by_customer.sql : SELECT customer_id, SUM(amount) as total_revenue FROM {{ ref('stg_payments') }} GROUP BY customer_id. Vous souhaitez que ce modèle soit matérialisé comme une vue en développement mais comme une table en production. Quelle est la meilleure approche ?
- A. Créer deux fichiers SQL distincts, un pour chaque environnement, avec des materialized configs différents
- B. Utiliser une configuration conditionnelle dans le bloc config : {{ config(materialized = 'view' if target.name == 'dev' else 'table') }}
- C. Définir la matérialisation par défaut dans dbt_project.yml pour le dossier intermediate et utiliser un override par target dans le fichier de profil profiles.yml
- D. Utiliser la syntaxe Jinja dans le bloc config : {{ config(materialized=('view' if target.name == 'dev' else 'table')) }}
Question 6
Vous développez un package dbt partagé entre plusieurs équipes. Vous devez créer un test générique réutilisable qui vérifie qu'une colonne de type date ne contient jamais de dates futures. Où devez-vous placer ce test générique personnalisé et quelle signature de macro est correcte ?
- A. Dans tests/generic/no_future_dates.sql avec la signature {% test no_future_dates(model, column_name) %}
- B. Dans macros/tests/no_future_dates.sql avec la signature {% macro test_no_future_dates(model, column_name) %}
- C. Dans tests/no_future_dates.sql avec une simple requête SELECT sans macro
- D. Dans macros/no_future_dates.sql avec la signature {% macro no_future_dates(model, column_name) %}
Question 7
Votre équipe data migre d'un pipeline SQL classique vers dbt. Un analyste demande pourquoi dbt utilise des instructions SELECT plutôt que des instructions CREATE TABLE ou INSERT INTO dans les fichiers de modèles. Quelle est l'explication la plus exacte ?
- A. dbt ne supporte pas les instructions DDL et ne peut exécuter que des SELECT.
- B. dbt encapsule automatiquement les SELECT dans des DDL/DML appropriés selon la materialisation configurée, séparant ainsi la logique métier de la logique de gestion des objets.
- C. Les instructions SELECT sont converties en vues temporaires qui sont ensuite copiées manuellement dans des tables par l'administrateur de la base de données.
- D. dbt exige des SELECT pour des raisons de performance, car les instructions DDL sont plus lentes sur les data warehouses modernes.
Question 8
Dans un projet dbt, un ingénieur analytics remarque que le fichier dbt_project.yml contient la configuration suivante sous la clé models : +materialized: view pour le dossier staging et +materialized: table pour le dossier marts. Un modèle spécifique dans le dossier staging déclare {{ config(materialized='table') }} dans son bloc config. Quelle matérialisation sera appliquée à ce modèle ?
- A. view, car la configuration du fichier dbt_project.yml est toujours prioritaire sur le bloc config() du modèle.
- B. table, car le bloc config() déclaré dans le modèle lui-même a la priorité la plus élevée dans la hiérarchie de résolution des configurations.
- C. Le build échouera avec une erreur de conflit de configuration entre le fichier dbt_project.yml et le bloc config().
- D. La matérialisation par défaut de dbt (view) sera utilisée car les deux configurations s'annulent mutuellement.
Pourquoi s'entraîner avec Certifexpress ?
- Questions au format officiel dbt Labs
- Corrections détaillées avec explications techniques (200+ mots par question)
- Examen chronométré comme le jour J
- Option "Refaire les questions ratées" pour cibler vos lacunes
- Suivi de votre progression dans votre tableau de bord personnel
- Accès illimité, aucun abonnement requis