Data Delivery
What this domain tests
Delivery questions ask how a governed view reaches consumers and applications: which protocol, which endpoint, and which controls travel with it. You should distinguish pull-based query delivery from push-based data movement and know that delivery does not remove view-level security.
Core rules
- Publish interface views through standards-based interfaces: JDBC/ODBC/ADBC for SQL clients, REST/JSON and OData for applications, SOAP where legacy systems require it, and GraphQL in supported releases. The consumer sees the view contract, not the sources.
- Delivery can be pull-based (the consumer queries the view) or push-based (Scheduler exports, data movement, or replication to a target). Push creates a copy and therefore a new governance obligation.
- Cache can sit behind a delivery endpoint to meet latency targets, with TTL and invalidation aligned to the service-level agreement.
- Security, row filters, masking, and audit apply to the delivered endpoint. A REST or OData service is not a bypass.
- Monitor delivered services for latency, errors, and concurrency; use the query monitor and diagnostic logs.
Worked example
A Customer 360 interface view must feed Power BI and a mobile app. Power BI connects over JDBC and uses the SQL endpoint; the mobile app calls an OData endpoint with a row filter for the authenticated customer. Both are the same interface view, so column masking and row filters are consistent. A 15-minute cache supports the mobile endpoint, and the Scheduler refreshes it. The reasoning: one contract, multiple protocols, controls enforced once at the view. If the mobile team instead demanded a nightly extract, that would be push delivery and would require residency and retention review.
Traps that cost marks
- Assuming OData or REST delivery bypasses VDP security.
- Treating a data movement job as virtualization; it is replication.
- Forgetting that cache staleness is visible to consumers.
- Publishing a base view directly and exposing source schema changes.
- Ignoring concurrency and timeout settings for external apps.
Marketplace and Self-Service
What this domain tests
Marketplace and self-service questions test how governed data products are published, discovered, requested, and consumed. You should know that the marketplace is a catalog experience over views, not a separate copy of data, and that access is granted through policy, not through discovery.
Core rules
- A data product is a curated, documented interface view with an owner, description, glossary terms, tags, sample data, and service-level information. It is published into the Data Catalog marketplace for discovery.
- Self-service starts with search and browsing by domain, tag, or glossary term. Consumers preview metadata and lineage, then request access or subscribe.
- Access requests go through an approval workflow. Approval grants the appropriate role or privileges on the underlying view; publication alone does not grant data access.
- Subscriptions and notifications keep consumers informed about changes, while ratings, comments, and ownership contacts support feedback.
- Lineage and usage metadata help consumers judge fitness and help stewards find redundant or stale products.
- The marketplace should expose interface views, not base views, to keep contracts stable and prevent source schema leakage.
Worked example
A data steward publishes Customer 360 as a data product. The interface view has an owner, a glossary term for “active customer,” a region tag, and a sample. A marketing analyst finds it by searching the glossary, reviews lineage to CRM and ERP, and requests access. The steward approves a role that grants execute on the interface view, with a row filter limiting the analyst to their region. The analyst subscribes to change notifications. The reasoning: discovery is open, access is controlled, and the contract stays stable behind the product.
Traps that cost marks
- Assuming publishing a product grants access to everyone.
- Publishing a base view and leaking source schema.
- Treating marketplace metadata as enforcement rather than documentation.
- Leaving products without owners or refresh expectations.
- Ignoring access requests that accumulate without review.