What you will be able to do
- Compare Unity Catalog privileges with the legacy Feature Store's metadata-only permissions
- Pick out which benefits are new with Unity Catalog and which the legacy Workspace Feature Store already had
- Describe how lineage from feature tables to models is captured and where to see it
1.Governance: Unity Catalog privileges vs legacy metadata permissions
In the Workspace Feature Store, access is split into two layers. Feature Store access control sets permissions on feature table metadata at three levels: CAN VIEW METADATA, CAN EDIT METADATA and CAN MANAGE. These control who can view a table in the UI, edit its description, manage permissions and delete it. The Delta table that holds the feature values is governed separately, by table access control. By default, the creator and workspace admins get CAN MANAGE, and other users get no permissions. Any user can create a new feature table. All of this is managed inside a single workspace.
In Unity Catalog, there is one layer. The docs state: "Access control for feature tables in Unity Catalog is managed by Unity Catalog." The legacy access-control page says the same from the other side: if your workspace is enabled for Unity Catalog, use Unity Catalog privileges instead. A feature table is an ordinary Unity Catalog table, so the same privileges that protect its data also decide who can use it as a feature table. Ownership follows the same model: only the table owner can declare primary key constraints, and that is the step that turns a table into a feature table.
Governance also reaches models. The docs say feature tables, functions and models are "all governed by Unity Catalog," and that a trained model "inherits permissions from the data it was trained on." The legacy metadata permissions have no equivalent.
Checkpoint 1 of 4· Match them up
Match each access-control item to what it governs
Tap a term, then the definition that fits it.
The legacy levels apply only to metadata, and the Delta table is governed separately. In Unity Catalog, one privilege system governs the table and the models trained on it.
“You can assign three permission levels to feature table metadata: CAN VIEW METADATA, CAN EDIT METADATA, and CAN MANAGE.”Source: docs.databricks.com
Checkpoint 2 of 4· Exam question
An ML platform lead notices that several teams across the company have independently built nearly identical customer-churn feature tables because nobody could find that the features already existed. The lead wants new feature tables to be searchable by anyone in the organization before a team starts building a duplicate. Why does creating feature tables at the account level in Unity Catalog, rather than at the workspace level, directly help with this problem?
Correct answer: B — Account-level feature tables are registered in Unity Catalog, so users can search and filter by catalog in the Features UI or Catalog Explorer, surfacing existing tables across every workspace before a team builds a duplicate.
- A. Relying on Slack messages is a manual, unreliable process that depends on everyone remembering to post and everyone else remembering to search, and it has nothing to do with Unity Catalog or feature table scope. It does not scale as a discovery mechanism.
- B. Because Unity Catalog is account-scoped, its Features UI and Catalog Explorer can list and filter feature tables across every workspace attached to the metastore, which is exactly the cross-team discoverability a workspace-level feature store cannot provide. This directly prevents the duplicate-building problem described.
- C. Markdown text in a notebook is not indexed for organization-wide search and is confined to whichever workspace hosts that notebook, so other teams would have no practical way to find it. This relies on manual convention rather than a platform capability.
- D. Workspace-level feature stores do not publish a shared searchable index to object storage, and there is no such automatic cross-workspace SQL-queryable index. This invents a mechanism that does not exist in Databricks.
2.Which benefits are new, and which the legacy store already had
Here is a common trap. The deprecated Workspace Feature Store already listed discoverability, lineage, integration with model scoring and serving, and point-in-time lookups as its benefits. A question that offers "you can search for features" or "lineage is tracked" as the benefit of Unity Catalog over workspace-level tables is giving you something both options have.
The Unity Catalog explore page lists four benefits that apply to all feature tables: feature discovery, governance, lineage and cross-workspace access. What changes is their scope. Discovery and lineage now cover every workspace on the metastore, not just one. Governance uses Unity Catalog privileges, which control the data itself and pass on to models. Cross-workspace access has no legacy equivalent.
| Benefit | Workspace Feature Store (legacy) | Feature tables in Unity Catalog |
|---|---|---|
| Discovery | Feature Store UI in the workspace | Browse and search by table name, feature, comment or tag, per catalog |
| Lineage | Data sources and consuming models, notebooks, jobs and endpoints | The same, viewable in Catalog Explorer, and covering models and functions in Unity Catalog |
| Access control | CAN VIEW METADATA / CAN EDIT METADATA / CAN MANAGE on metadata only | Unity Catalog privileges; models inherit permissions from training data |
| Cross-workspace access | Not offered | Available in any workspace that has access to the catalog |
Checkpoint 3 of 4· Check yourself
Which of these is a benefit of Unity Catalog feature tables that the legacy Workspace Feature Store did NOT offer?
The legacy store already offered discovery, lineage and point-in-time lookups. Cross-workspace access comes from Unity Catalog.
“All Unity Catalog capabilities, such as security, lineage, tagging, and cross-workspace access, are automatically available to the feature table.”Source: docs.databricks.com
3.Discovery and lineage in Unity Catalog
For discovery, any table managed by Unity Catalog that has a primary key automatically appears in the Features UI. You don't publish it there. You pick a catalog with the catalog selector and see every feature table in it, with its owner, the online stores it was published to, the last time a notebook or job wrote to it, its tags and its comments. Because the catalog lives in the metastore, a data scientist in any attached workspace sees the same list.
Lineage is recorded automatically when you log a model with FeatureEngineeringClient.log_model. The features the model used can then be viewed in the Lineage tab of Catalog Explorer. Python UDFs used to compute on-demand features are tracked too. Setting the registry URI to databricks-uc registers the model in Unity Catalog. That way the model and its feature tables live in the same governed catalog.
model_name = "fe_packaged_model"
mlflow.set_registry_uri("databricks-uc")
fe.log_model(
IsClose(),
model_name,
flavor=mlflow.pyfunc,
training_set=training_set,
registered_model_name=registered_model_name
)The same approach covers FeatureSpecs. A FeatureSpec is a Unity Catalog entity that groups feature lookups and functions for serving. Unity Catalog stores and manages it, with full lineage back to its offline feature tables and functions. At serving time, the endpoint uses Unity Catalog to trace lineage from the served model back to the features it was trained on.
Checkpoint 4 of 4· Check yourself
After training with Feature Engineering in Unity Catalog, where do you look to see which feature tables and functions a model used?
Calling log_model records the features and on-demand functions the model used, and Catalog Explorer shows them in its Lineage tab.
“the features used in the model are automatically tracked and can be viewed in the Lineage tab of Catalog Explorer.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Granting or revoking legacy Feature Store permissions controls who can read the feature data.Why is that wrong?
Legacy Feature Store permissions cover only feature table metadata. Table access control governs the Delta table separately. In Unity Catalog, one set of privileges governs the table.
Covered in Governance: Unity Catalog privileges vs legacy metadata permissions
2.Feature discovery and lineage are what Unity Catalog adds over workspace-level feature tables.Why is that wrong?
The legacy Workspace Feature Store already offered discovery and lineage within its workspace. Unity Catalog's real additions are cross-workspace access and governance through Unity Catalog privileges, including models inheriting permissions from their training data.
Covered in Which benefits are new, and which the legacy store already had
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Access control for feature tables in Unity Catalog is managed by Unity Catalog.”
↩︎ Governance: Unity Catalog privileges vs legacy metadata permissions“In addition to feature tables, Python UDFs that are used to compute on-demand features are also tracked.”
↩︎ Discovery and lineage in Unity Catalog“the features used in the model are automatically tracked and can be viewed in the Lineage tab of Catalog Explorer.”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/machine-learning/feature-store/workspace-feature-store/access-controlOfficial docs
“If your workspace is enabled for Unity Catalog, use Unity Catalog privileges instead.”
↩︎ Governance: Unity Catalog privileges vs legacy metadata permissions“Any user can create a new feature table.”
↩︎ Governance: Unity Catalog privileges vs legacy metadata permissions“Feature Store access control does not govern access to the underlying Delta table, which is governed by table access control.”
↩︎ Exam trap 1“Feature Store access control does not govern access to the underlying Delta table, which is governed by table access control.”
↩︎ Prediction“You can assign three permission levels to feature table metadata: CAN VIEW METADATA, CAN EDIT METADATA, and CAN MANAGE.”
↩︎ Checkpoint - 3.
“When you train a model, it inherits permissions from the data it was trained on.”
↩︎ Governance: Unity Catalog privileges vs legacy metadata permissions“Feature tables, functions, and models are automatically available in any workspace that has access to the catalog.”
↩︎ Which benefits are new, and which the legacy store already had“Any table managed by Unity Catalog that has a primary key is automatically a feature table and appears on this page.”
↩︎ Discovery and lineage in Unity Catalog - 4.
“Only the table owner can declare primary key constraints.”
↩︎ Governance: Unity Catalog privileges vs legacy metadata permissions - 5.https://docs.databricks.com/aws/en/machine-learning/feature-store/workspace-feature-storeOfficial docs
“Lineage. When you create a feature table in Databricks, the data sources used to create the feature table are saved and accessible.”
↩︎ Which benefits are new, and which the legacy store already had“Discoverability. The Feature Store UI, accessible from the Databricks workspace, lets you browse and search for existing features.”
↩︎ Exam trap 2 - 6.
“FeatureSpecs are stored and managed by Unity Catalog, with full lineage tracking to their constituent offline feature tables and functions.”
↩︎ Discovery and lineage in Unity Catalog“The endpoint uses Unity Catalog to resolve lineage from the served model to the features used to train this model”
↩︎ Discovery and lineage in Unity Catalog
Also cited
- https://docs.databricks.com/aws/en/machine-learning/feature-store/workspace-feature-store/feature-tablesOfficial docs
“All Unity Catalog capabilities, such as security, lineage, tagging, and cross-workspace access, are automatically available to the feature table.”
↩︎ Checkpoint