Security, Governance, and Monitoring
This domain tests who can see and do what, how governance metadata and policies attach to lakehouse objects, and how you detect failures and abuse.
Access and security
watsonx.data uses instance-level roles plus granular grants on engines, catalogs, schemas, and tables. Give users the least privilege: a viewer who runs SQL does not need administrator rights. Store source credentials in connections and secrets, not in scripts. Object storage encryption and TLS protect data at rest and in transit; platform audit logs record control-plane actions.
Governance
Integration with IBM Knowledge Catalog lets you catalog lakehouse assets, attach glossary terms, view lineage, and apply data protection policies such as masking. Governance is only as good as the metadata: table and column descriptions, ownership, and classification must be maintained.
Monitoring
Watch query history for long-running or failed queries, engine health and utilization, ingestion job status, and storage growth. Audit logs answer "who deleted the table?" and metrics answer "is the engine saturated?" Alerts should target failed ingestion jobs and engines near capacity. In the IBM Cloud deployment, Activity Tracker supplies audit events.
Worked example
A contractor needs read access to one schema for two weeks. Grant the user access to the engine and viewer access on that schema only; do not grant catalog-wide or instance admin. Verify by running a sample query in that schema and a query against another schema, which should fail. Set a review date and revoke. Reasoning: engine access without table grants yields a connection but no data; schema-scoped grants limit blast radius; time-bound review prevents privilege accumulation.
Traps
- Granting administrator to avoid permission troubleshooting.
- Granting engine access and assuming it grants table access.
- Leaving credentials in ingestion scripts or notebooks.
- Monitoring only engine CPU and missing failed ingestion jobs.