How do we implement data governance and access control within a shared Feast registry?

All answers to this question.

Since Feast is a code-first library, the best way to handle governance is through your CI/CD pipeline and Git permissions. You should treat your feature repository just like your application code. Use "Protected Branches" so that any changes to the feature registry require a Pull Request and approval from a lead engineer or data owner. For the actual data access in the online/offline stores, you should use the native IAM roles of your cloud provider (like BigQuery or Redis). This way, you don't need a separate RBAC system inside Feast; you simply leverage the mature security tools you already have in your cloud environment.

   Answered 2025-08-10 by Pamela Stewart

How do you handle "feature discovery" so that teams know what exists before they try to create a duplicate feature?

   Answered 2025-08-11 by Jeffrey Malone

• We use the Feast Web UI for that, Jeffrey. It provides a searchable catalog of all registered features, entities, and descriptions. Before anyone starts a new project, they are required to check the UI to see if a similar feature already exists. We’ve also integrated Feast with Amundsen, a data discovery platform, which allows our analysts to see the "lineage" of a feature—where the raw data comes from and which models are currently using it. This has significantly reduced redundant computation and improved our overall data consistency.

     Commented 2025-08-12 by Mitchell Reese

Tagging features with "production" or "experimental" labels in the metadata field is a simple but effective way to manage expectations.

   Answered 2025-08-13 by Cynthia Barrett

• Great tip, Cynthia. Labels help our DevOps team know which features need 24/7 monitoring and which ones are just for sandbox testing.

     Commented 2025-08-14 by Bryan Crawford