Unity Catalog Feature Tables vs Workspace Feature Store: Scope and Access

This statement creates a feature table in Unity Catalog. Which table name completes it?

CREATE TABLE  ?  (
  customer_id int NOT NULL,
  feat1 long,
  feat2 varchar(100),
  CONSTRAINT customer_features_pk PRIMARY KEY (customer_id)
);

1. recommender_system.customer_features
2. ml.recommender_system.customer_features
3. workspace.customer_features_pk
4. customer_features

Which statement correctly explains why a feature table in Unity Catalog can be reused across workspaces?

1. Every workspace in the account can see every feature table, whatever metastore it uses
2. The Features UI exports the table to other workspaces when you add a tag
3. Databricks copies the table into every workspace's local feature store each night
4. The table belongs to the Unity Catalog metastore, so every workspace assigned to that metastore can reach it

A data science team in Workspace A builds a demand-forecasting feature table for a retail company. The marketing analytics team, working in Workspace B, is attached to the same Unity Catalog metastore and wants to reuse those exact features for a promotion-targeting model instead of recomputing them. The features were originally created as an account-level table in Unity Catalog rather than in a workspace-level feature store. What is the primary benefit this gives the marketing team?

1. A.Because the feature table lives in Unity Catalog, it is accessible to every workspace attached to the same metastore, so the marketing team can read and reuse it through a normal `catalog.schema.table` reference without copying data.
2. B.Because the feature table is stored in a workspace-level Hive metastore, Databricks grants read access to any user across the entire account regardless of which metastore their workspace is attached to.
3. C.Because the feature table was registered with the legacy `FeatureStoreClient`, MLflow automatically forwards its schema to every workspace's local model registry so downstream teams inherit access.
4. D.Because the feature table was written with Auto Loader, Databricks automatically replicates the underlying files into every workspace's own DBFS mount, letting each team keep an independent physical copy of the data rather than one shared source.

A team on a workspace created in 2025 wants the workspace-level Feature Store instead of Unity Catalog. What is the correct response?

1. It is not available. The Workspace Feature Store exists only for workspaces created before August 19, 2024, and is deprecated
2. It is available if the metastore uses Privilege Model Version 1.0
3. It is available, but only on Databricks Runtime 13.2 or above
4. It is available only if they install the databricks-feature-engineering package

A bank's ML platform team must produce an audit trail showing exactly which raw source tables and transformations fed into a fraud-detection model that is currently served in production. The model was trained using a feature table built by a team in a different workspace than the one serving the model, and both workspaces attach to the same Unity Catalog metastore. Which benefit of creating the feature table at the account level directly supports this audit requirement?

1. A.Storing the feature table's files in the DBFS root gives every attached workspace direct filesystem access to the underlying Parquet files, letting auditors infer lineage by inspecting the raw data.
2. B.The Feature Store UI exports a CSV of feature names on request, which an administrator can manually cross-reference against cluster event logs to reconstruct the transformation history by hand.
3. C.Workspace-level feature stores generate an equivalent lineage graph automatically, but the graph is discarded whenever the cluster that computed the features terminates, so it must be rebuilt by rerunning the notebook.
4. D.Unity Catalog automatically captures lineage across catalogs and workspaces, tracing the served model back through the feature table to the upstream source tables that produced each feature.