Databricks AutoML trains and tunes a spread of models automatically and hands back editable notebooks, a glass box rather than a black box, while Feature Engineering in Unity Catalog stores computed features in governed Delta tables with primary keys so training and serving read identical values. Both are core to the Databricks Machine Learning Associate exam.
Last updated August 2026.
The Databricks Machine Learning Associate exam guide lists 48 objectives, and the exam runs approximately one scored question per objective. Eight of those objectives name AutoML or feature tables: two on how AutoML accelerates model and feature selection, and six on feature store tables, from creating and writing them through training and scoring to the online-versus-offline distinction. That is roughly eight questions, all inside the exam's Databricks Machine Learning section, which is the largest section of the guide.
Objective counts from the official Databricks Machine Learning Associate exam guide (1 Mar 2025 version).
Point AutoML at a table and a target column and it automates the first pass of a modeling project: it profiles the data, handles imputation and encoding, trains a spread of algorithms, distributes the hyperparameter tuning, and ranks every trial by a primary metric, logging each one as an MLflow run.
What makes it Databricks AutoML is what comes back. Most AutoML tools return a sealed model. Databricks AutoML generates the full source notebook for each trial, so a finished run leaves three artifacts:
That glass-box design is why AutoML survives audit-heavy environments, and it is exactly the advantage the exam asks about: the pipeline can be read, explained, and changed. AutoML covers classification, regression, and forecasting, trialing familiar open-source libraries (scikit-learn, XGBoost, LightGBM for the supervised tasks, Prophet and ARIMA-family models for forecasting), and you can launch it from the UI wizard or the Python API.
Problem types, libraries, and the generated-notebook behavior from the official Databricks AutoML documentation.
The problem feature stores solve is duplication and its consequence, skew. When every notebook derives its own "average spend per customer", the same idea gets implemented slightly differently in training and serving, and the model quietly sees different inputs in production than it learned on.
Feature Engineering in Unity Catalog does not bolt on a separate system: a feature table is a Delta table in Unity Catalog with a primary key constraint. The key is what lookups use to fetch an entity's features, and because the table is a normal governed Unity Catalog object, it gets the same grants, lineage, and discovery as everything else, reusable across every project in the account rather than trapped in one workspace (the advantage over the legacy Workspace Feature Store).
The workflow the exam tests is one client, three moves:
FeatureEngineeringClient.create_table defines the table with its primary key and populates it from a DataFrame.FeatureLookup joins features onto your labels by key, and create_training_set assembles the training data.score_batch takes a DataFrame of primary keys and looks the current feature values up itself.That last step is the point: training and serving read the same table, so there is no skew to debug.
The same features can be read two ways, and the exam guide asks for the difference explicitly:
| Signal | Offline | Online |
|---|---|---|
| Read pattern | Millions of rows in bulk | One row per request |
| Latency | Seconds to minutes | Milliseconds |
| Used by | Training and batch scoring | Real-time model serving |
| Storage | Delta table in Unity Catalog | Managed online store, synced from the offline table |
The offline table is the source of truth and the default; the online store exists only because a Delta table cannot serve single-row lookups fast enough for a live endpoint. One question settles every scenario: is the prediction served live, per request, or over a batch? Live points online, everything else stays offline.
They are not separate islands. AutoML can pull existing feature tables in to augment its training data, so features engineered once in Unity Catalog feed automated baselines too. In practice the pairing is a loop: AutoML gets you a strong first model fast, its data exploration notebook flags weak or problematic columns, and the features worth keeping graduate into a feature table that every later model, manual or automated, reads from the same place.
Databricks AutoML automatically prepares data, trains a spread of algorithms, and tunes hyperparameters for classification, regression, and forecasting problems. The difference is its glass-box approach: it generates the full, editable source notebook for each trial rather than returning a sealed model, so the pipeline can be audited and modified.
A primary key constraint. Any Delta table in Unity Catalog with a primary key can serve as a feature table, and the key is what feature lookups use to fetch each entity's values. There is no separate storage system to maintain.
An offline feature table is a Delta table in Unity Catalog built for bulk reads during training and batch scoring. An online store is a managed low-latency copy synced from it, serving single-row lookups in milliseconds for real-time model serving. The offline table is the default; go online only when a live endpoint needs per-request feature lookups.
Eight of the exam guide's 48 objectives name AutoML or feature store tables, which works out to roughly eight scored questions on a 48-question exam. They cover AutoML's role in model and feature selection, creating and consuming feature tables, and the online versus offline distinction.
Chapters 3 to 7 of our free ML Associate course cover AutoML, its generated notebooks, Unity Catalog for ML, and both feature table chapters, in the same order the objectives list them. Works on a phone.
Start Chapter 3: AutoML →