Databricks-ML-Assoc Model Development Practice Question
A data scientist is building a feature pipeline and wants to avoid recomputing expensive aggregations on every run. They need the computed feature table to be queryable by other notebooks and jobs, refreshed on a schedule, and stored in Delta Lake. Which Databricks capability should they use to define and materialize these features?
⚠ Common exam trap
The trap here is conflating any Delta storage or pipeline tool with a feature store, when only feature tables provide keys, time columns, and point-in-time joins.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Feature Store feature tables created with FeatureStoreClient.create_table.
Reusable, scheduled, queryable features in Delta format are the core purpose of the Databricks Feature Store. Feature tables are Delta tables with declared primary keys and timestamps, enabling point-in-time lookups and training-serving consistency. Other options either provide generic storage or pipeline tooling without the feature-management semantics the scenario calls for.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A Unity Catalog volume holding Parquet files of the computed features.
Why it's wrong here
Volumes store arbitrary files and are not tables, so other notebooks cannot query them with SQL or join them directly without reading and parsing files. They also lack schema enforcement, primary-key semantics, and time-travel features that Delta tables provide. This approach adds manual file management and does not deliver the scheduled, queryable feature table the scenario requires.
- ✓
Feature Store feature tables created with FeatureStoreClient.create_table.
Why this is correct
The Databricks Feature Store is designed exactly for this: you compute features once, write them as Delta tables with a primary key and timestamp column, and consumers join them at training or inference time. It supports scheduled refreshes through jobs and lineage back to the source data, satisfying discoverability, reuse, and Delta storage in one mechanism.
- ✗
A Delta Live Tables pipeline with expectations defined on each feature.
Why it's wrong here
Delta Live Tables is a pipeline framework for building reliable data transformations, and expectations enforce data quality, but it is not a feature catalog. It does not provide point-in-time joins, feature discovery by name, or the training-serving consistency guarantees of the Feature Store. Using it here would reinvent feature management primitives that the platform already provides.
- ✗
An MLflow experiment with logged artifacts containing the feature vectors.
Why it's wrong here
MLflow experiments track runs, parameters, metrics, and artifacts for model development, not reusable feature datasets. Artifacts are files attached to runs and are not queryable tables, so other jobs cannot join them efficiently. This would duplicate feature data per run and provide no refresh schedule or feature discovery, entirely missing the requirement.
About these practice questions
One of 319 original Databricks-ML-Assoc practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-ML-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-ML-Assoc exam.