Check Your Knowledge

Test your understanding of system.billing.usage, chargeback taxonomy, dashboard design, predictive optimization savings, auto-TTL, and system-table governance before moving on.

Why does computing a dollar figure from system.billing.usage alone always require a join to system.billing.list_prices?
- A. system.billing.usage records DBU quantities, not dollars, and prices vary by SKU and change over time
- B. system.billing.usage is refreshed less frequently than list_prices
- C. Unity Catalog requires all cost queries to touch at least two tables
- D. system.billing.usage does not contain a sku_name column
What is the purpose of the price_start_time/price_end_time window in system.billing.list_prices?
- A. It marks when the table itself was created
- B. It lets a query reconstruct the price that was actually in effect on the day usage occurred, rather than today’s price
- C. It defines the retention period for the pricing table
- D. It controls how often the dashboard refreshes
Which field in system.billing.usage carries the team/project/cost-center attribution that a chargeback report depends on?
- A. usage_metadata
- B. sku_name
- C. custom_tags
- D. record_id
In the attribution taxonomy, what distinguishes showback from true chargeback?
- A. Showback only works for SQL warehouses, chargeback only works for clusters
- B. Showback surfaces cost for visibility without moving budget, while chargeback debits a team’s actual budget and demands enforced, non-optional tagging
- C. Chargeback is computed monthly, showback is computed daily
- D. There is no meaningful difference; the terms are interchangeable
On the chargeback dashboard, why should the “spend by team” panel include an explicit “Untagged” bucket rather than silently dropping untagged rows?
- A. Databricks SQL requires every GROUP BY to include a null-handling bucket
- B. A growing untagged slice is itself a signal that tag enforcement is slipping, and hiding it would mask that
- C. It makes the bar chart render faster
- D. Untagged rows always represent test workloads that should be highlighted separately
What does predictive optimization actually automate?
- A. Chargeback report generation
- B. OPTIMIZE, VACUUM, and ANALYZE on Unity Catalog managed tables
- C. Custom tag propagation from clusters to jobs
- D. Budget alert thresholds
Why is “we reclaimed 40 TB this quarter” from predictive optimization an incomplete FinOps claim?
- A. It reports a storage metric, not a dollar figure, and doesn’t account for the DBU cost of running the optimization itself
- B. Predictive optimization cannot reclaim more than 10 TB per run
- C. Storage metrics are not visible in any system table
- D. VACUUM cannot run on managed tables
What is the core idea behind the “auto-TTL” pattern described as an emerging direction, given that no single built-in feature yet automates it end to end?
- A. Automatically increasing cluster size as tables grow
- B. Policy-driven expiration of data at the row or partition level, based on business-defined retention age, built today with a policy table plus a scheduled Lakeflow Job
- C. Automatically converting Delta tables to Parquet after 30 days
- D. Deleting a table entirely once its VACUUM retention window expires
Why should SELECT on system.billing tables be scoped to a FinOps role rather than granted broadly?
- A. Broad grants would exceed Unity Catalog’s row-count limits
- B. Raw usage and pricing data reveals per-workload spend at a granularity most organizations don’t want broadly readable
- C. system.billing tables are read-only and cannot be granted at all
- D. Only account admins are technically capable of running joins
What is the recommended way to give a team lead self-serve visibility into only their own team’s spend, without exposing every other team’s data?
- A. Grant them direct SELECT on system.billing.usage and trust them to filter by their own tag
- B. Front the raw system tables with a governed view that pre-joins usage and list_prices and exposes only that team’s rows
- C. Export the full table to a spreadsheet and email it to them monthly
- D. Disable custom tags so no team-level data exists to leak

Answer Key

A – system.billing.usage stores DBU quantities; only joining to the time-versioned list_prices table converts that into an accurate dollar figure for the day the usage occurred.
B – The start/end window lets a query pick the SKU price that was actually in effect when usage happened, avoiding mispricing from later price changes.
C – custom_tags is the map carrying the organization’s own attribution keys (team, project, cost center, environment) that flow from tagged resources into every usage row.
B – Showback is visibility-only reporting with a loose tagging bar; chargeback moves actual budget and requires enforced tagging to be trustworthy.
B – An “Untagged” bucket that grows over time exposes eroding tag discipline directly on the dashboard instead of quietly excluding that spend from the totals.
B – Predictive optimization automatically runs OPTIMIZE, VACUUM, and ANALYZE on Unity Catalog managed tables in place of manually scheduled maintenance jobs.
A – Bytes reclaimed is a storage metric; proving savings requires comparing it against the DBU cost of running the optimization and the downstream query-cost reduction, in dollars.
B – Auto-TTL, as described, is a policy-driven pattern for expiring data by business-defined age at the row/partition level, buildable today with a retention policy table and a scheduled job, ahead of any first-class shipped feature.
B – Per-workload billing detail at that granularity is sensitive enough that it should be limited to the FinOps role and the dashboard’s service principal, not opened account-wide.
B – A governed view that pre-joins the billing tables and filters to the requester’s own tag gives self-serve access to one team’s data without granting visibility into every other team’s spend.

| ← Previous: The System-Table Query Pack and Governance Guardrails | Next: The Migration Playbook: Sequencing the Whole Thing → | |:—|—:|