Describe the feature before storing it
A useful feature contract specifies an entity key, definition, unit, event and availability timestamps, update cadence, owner, access policy, and behavior for missing values. For example, a transaction count might mean the number of accepted payments for a customer in the preceding hour, computed from events available by the decision time. Two teams can use the same feature name while applying different windows or filters; a shared definition and parity tests make that mismatch visible.
Write a contract for a one-hour transaction count. State whether failed payments count, when the window ends, how duplicates are handled, and the maximum tolerated staleness.
Distinguish historical and online access
The current Google Cloud Feature Store architecture uses feature data maintained in BigQuery, including historical values, and provides online serving capabilities through feature views. Training needs the historical value appropriate to each example’s prediction time; live serving typically needs a recent value for the entity. A feature view must be synchronized before serving, and synchronization and source delays affect freshness. Check the current documentation for setup and supported serving configurations.
A model trains on examples scored at 09:00 and 15:00 for the same customer. Explain why joining both examples to the latest value at the end of the day can leak future information.
Understand registration and timestamps
Feature Registry can organize feature metadata and support reuse, but registration is not required for every direct BigQuery-source serving configuration. Product requirements differ for time-series sources and other capabilities; consult the current setup guide. A feature timestamp identifies a version of a value, but point-in-time correctness also depends on when the value became available. Preserve enough history and publication information to reconstruct what the serving system could actually have known.
An event is timestamped 10:00 but the aggregate is published at 10:10. A prediction occurred at 10:05. Explain which timestamp is needed to determine availability and why an event-time cutoff alone may be insufficient.
Test missing, stale, and inconsistent values
Verify entity lookup, expected null behavior, access control, synchronization, and the response when an entity has no eligible feature. Depending on the configuration, a serving system may return the most recent non-null value, so a newly written null does not necessarily mean the same thing as an explicit reset. Compare offline and online transformations with representative cases, monitor freshness and distribution changes, and make fallback behavior explicit. Avoid treating online and offline parity as guaranteed simply because they use the same source.
A customer’s feature changes from 5 to null. Design a test to determine whether the chosen configuration returns null or an older non-null value, and decide whether the result is safe for your model.
What should a training example use when a customer has multiple historical feature values?
Keep exploring
Use the official certification page and its linked resources to validate your coverage. For guided labs, explore the Google Skills learning path. Revisit the practical exercise and explain your decision in your own words before moving on.