Study Databricks ML-ASSOC Feature Store and Unity Catalog: key concepts, common traps, and exam decision cues.
Feature tables are one of the most Databricks-specific parts of this exam. The point is not memorizing a method name alone. The point is understanding how governed reusable features support consistent training and scoring.
| Question | Better first instinct |
|---|---|
| reusable governed features across the account | Unity Catalog feature tables |
| use the same features for training and scoring | feature-table workflow |
| online versus offline use | serving-oriented versus training or batch-oriented feature access |
| Ask this first | Why it matters |
|---|---|
| is the question about governance scope or feature retrieval behavior? | Unity Catalog boundary and feature-usage boundary are different |
| is the feature table being used for training, batch scoring, or low-latency serving? | online and offline answers change with the access pattern |
| is the value of the table reuse, consistency, or both? | the best answer often combines governance with operational consistency |
| If the stem says… | Strong reading |
|---|---|
| “account level in Unity Catalog vs workspace level” | governance and reuse boundary |
| “create a feature table” | Databricks feature-engineering workflow, not ad hoc CSV storage |
| “train or score using features” | consistent feature retrieval path |
Feature tables are important because they reduce two common ML failures:
The stronger answer is usually the one that keeps feature logic reusable and governed instead of buried in one notebook run.
| Trap | Better rule |
|---|---|
| treating feature tables as ordinary storage only | they exist to improve consistency and reuse in ML workflow |
| mixing online and offline feature tables | serving and training needs are not identical |
| assuming features for training automatically appear in serving correctly | consistency still has to be designed intentionally |
| Scenario clue | Stronger answer shape |
|---|---|
| “multiple workspaces need the same feature definition with governance” | account-level Unity Catalog feature workflow |
| “model needs low-latency feature lookup at serving time” | online feature access |
| “training set and batch scoring job should use the same reusable features” | offline feature-table workflow |
| “team built features in a notebook and now wants shared operational reuse” | move toward governed feature tables, not more ad hoc code |
Feature-table questions usually reward consistency between training and serving. If the issue is governed reusable features, think feature-table workflows in Unity Catalog. If the issue is serving latency, distinguish online from offline feature use. The weak answer usually leaves feature logic duplicated in separate notebooks or code paths and then wonders why offline and online behavior drift apart.