Databricks ML Professional Practice Question 9: Online Feature Store Publish
Databricks Certified Machine Learning Professional · Test 1 · question 9 of 10
A streaming pipeline writes transaction-velocity features to the Unity Catalog feature table ml.features.card_velocity. The fraud model's serving endpoint looks up these features in a Databricks Online Feature Store. New values must be available online within seconds. Last week, a one-time fe.publish_table(..., publish_mode="SNAPSHOT") of this table succeeded. Today, the same call with publish_mode="CONTINUOUS" fails before any sync starts.
What is the most likely cause?
Show answer and explanation
Answer:
FeatureEngineeringClient.publish_table() syncs an offline feature table to an online store, which is backed by Lakebase. It supports three publish modes. SNAPSHOT is a one-time full copy. TRIGGERED (the default) syncs changes incrementally, on demand or on a schedule. CONTINUOUS runs a streaming sync, so writes appear online almost immediately, which is what "within seconds" needs. TRIGGERED and CONTINUOUS read incremental changes, so both require Change Data Feed on the source table. SNAPSHOT does not, which is why last week's snapshot publish worked.
Option B names a real requirement, but it applies to every publish mode. The successful SNAPSHOT publish shows that the table already has a valid primary key.
Option C borrows a real concept but misapplies it. Online stores are sized in capacity units (CU_1, CU_2, CU_4, CU_8), but capacity governs throughput and cost, not which publish modes you can use.
Option D is not a requirement either. Any Unity Catalog Delta feature table with a primary key and Change Data Feed can be published continuously, including one that a streaming job writes to.
Reference: Databricks Online Feature Stores