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
Vous travaillez sur un projet dbt multi-source. L'équipe ingénierie charge des données dans le schéma 'raw_production' de Snowflake, mais votre environnement de développement utilise le schéma 'raw_dev'. Vous souhaitez que vos sources pointent dynamiquement vers le bon schéma selon l'environnement, sans modifier le fichier sources.yml à chaque basculement. Quelle est la meilleure approche ?
- A. Utiliser la macro generate_schema_name() pour rediriger automatiquement les sources vers le bon schéma en fonction de la target.
- B. Définir la propriété 'schema' de la source avec une expression Jinja utilisant la variable target, par exemple : schema: "{{ 'raw_production' if target.name == 'prod' else 'raw_dev' }}".
- C. Créer deux fichiers sources.yml distincts (sources_prod.yml et sources_dev.yml) et utiliser un tag conditionnel pour sélectionner le bon fichier.
- D. Définir la propriété 'database' dans le fichier sources.yml et utiliser des variables d'environnement via env_var() pour contrôler le schéma.
Question 2
Votre entreprise utilise le package dbt_utils pour enrichir ses tests de qualité de données. Vous devez vérifier que la combinaison des colonnes 'order_date' et 'customer_id' dans le modèle 'orders' forme une clé unique composite. Quel test du package dbt_utils est le plus approprié ?
- A. dbt_utils.unique_combination_of_columns
- B. dbt_utils.expression_is_true avec une expression COUNT DISTINCT
- C. dbt_utils.not_null_proportion sur les deux colonnes
- D. dbt_utils.equality comparant avec un SELECT DISTINCT
Question 3
Un ingénieur analytics découvre que le test 'relationships' échoue entre le modèle 'fact_sales' (colonne 'customer_id') et le modèle 'dim_customers' (colonne 'customer_id'). Après investigation, il constate que 15 enregistrements dans 'fact_sales' référencent des clients supprimés. L'équipe décide que ce comportement est acceptable tant que le nombre de violations reste inférieur à 50. Quelle configuration dbt permet de gérer cette situation ?
- A. Ajouter 'severity: warn' au test pour transformer l'échec en simple avertissement sans seuil
- B. Configurer le test avec 'error_if: '>= 50'' et 'warn_if: '> 0'' pour contrôler les seuils de tolérance
- C. Supprimer le test 'relationships' et le remplacer par un test singulier avec une clause HAVING COUNT(*) < 50
- D. Utiliser la macro 'accepted_values' avec un paramètre 'quote: false' pour ignorer les valeurs orphelines
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 pipeline dbt de production, vous avez un modèle 'fact_transactions' avec un test not_null sur la colonne 'transaction_id'. L'équipe souhaite que le test accepte jusqu'à 10 lignes en violation avec un simple avertissement, mais échoue en erreur à partir de 11 lignes. Quelle configuration appliquez-vous au test ?
- A. severity: warn avec limit: 10
- B. warn_if: '>10' et error_if: '>10'
- C. warn_if: '>0' et error_if: '>10'
- D. threshold: 10 et severity: adaptive
Question 6
Votre entreprise utilise dbt Cloud et vous venez de configurer 'persist_docs' dans votre dbt_project.yml. Après avoir exécuté 'dbt run', vous constatez que les descriptions des colonnes apparaissent dans le site dbt docs mais ne sont pas propagées comme commentaires dans votre data warehouse BigQuery. Quelle est la cause la plus probable ?
- A. La configuration persist_docs a été définie uniquement avec 'relation: true' mais sans 'columns: true'
- B. BigQuery ne supporte pas la propagation des commentaires de colonnes via dbt
- C. Il faut exécuter 'dbt docs persist' après 'dbt run' pour propager les commentaires dans le warehouse
- D. Les descriptions doivent être définies via des doc blocks (.md) et non directement dans les fichiers .yml pour être persistées
Question 7
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 8
Vous maintenez un projet dbt avec plusieurs sources définies. L'équipe data engineering vous informe que la table clients dans le schéma raw_crm a été renommée en customers dans la base de données source, mais vous souhaitez continuer à utiliser le nom 'clients' dans vos modèles dbt pour éviter un refactoring massif. Quelle approche est correcte ?
- A. Créer un alias dans le fichier dbt_project.yml en ajoutant source_alias: customers sous la configuration de la source raw_crm
- B. Dans le fichier sources.yml, ajouter la propriété identifier: 'customers' sous la définition de la table clients pour mapper vers le nom physique réel
- C. Renommer la table dans sources.yml de clients à customers et créer un modèle intermédiaire stg_clients qui fait un SELECT depuis {{ source('raw_crm', 'customers') }} avec un alias
- D. Utiliser la propriété table_name: 'customers' sous la définition de la table clients dans le fichier sources.yml
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