Home / data-analytics / Databricks Certified Data Analyst Associate / Cheat Sheet
Databricks Certified Data Analyst Associate

Databricks DA Assoc Cheat Sheet

Databricks DA Assoc Tests SQL, Dashboards and Genie on Unity Catalog — Not Spark Pipelines

The October 2026 refresh targets analysts who query, visualise and share governed data in Databricks SQL. Think like a consumer of curated tables: warehouses, AI/BI Dashboards, Genie and grants, not pipeline engineering.

Check Your Readiness →
Among the harder certs
Avg: Not published by Databricks
Pass: 750 / 1000
Most candidates understand Databricks Certified Data Analyst Associate concepts — and still fail. This exam tests how you apply knowledge under pressure.

Data Analyst Associate Domain Map (October 2026 guide)

Nine sections, with weights confirmed on the certification page. Expect SQL-reading items where you predict output (watch NULLs, join types and UNION versus UNION ALL) alongside design choices about which object, warehouse setting, dashboard feature or grant fits a reporting need.

  1. 01
    Executing Queries with Databricks SQL and SQL Warehouses (20%) — joins, set operations, materialized views, federation, time travel, Genie Code
  2. 02
    Dashboards and Visualizations (16%) — AI/BI Dashboards, parameters vs filters, sharing, schedules, alerts, chart choice
  3. 03
    Analyzing Queries (15%) — Photon, query profile, Query Insights, caching, Predictive Optimization, liquid clustering
  4. 04
    AI/BI Genie Agents (Genie spaces) (12%) — instructions, trusted assets, benchmarks, permissions and distribution
  5. 05
    Data Intelligence Platform (11%) — Lakebase, Lakeflow, metric views, certified tables, Marketplace
  6. 06
    Managing Data (8%) — governed tags, lineage including external lineage, SQL cleaning with COALESCE and TRY_CAST
  7. 07
    Securing Data (8%) — USE CATALOG, USE SCHEMA and SELECT, group ownership, column masks, row filters
  8. 08
    Importing Data (5%) — Auto Loader, COPY INTO, Lakeflow Connect, Delta Sharing, workspace file upload
  9. 09
    Data Modeling with Databricks SQL (5%) — star, snowflake and data vault mapped to medallion layers

Wrong instinct vs correct approach

An expensive three-table join feeds a dashboard every few minutes; hour-old results are acceptable
✕ Wrong instinct

Create a standard view or a streaming table

✓ Correct approach

A materialized view stores the precomputed join and aggregation and refreshes on a schedule, matching the one-hour tolerance. A standard view recomputes on every read, and streaming tables suit append-only ingestion, not heavy aggregates.

An analyst must find who deleted 4,000 rows from a managed table last night and show prior totals
✕ Wrong instinct

Search warehouse query history for DELETE statements

✓ Correct approach

Run DESCRIBE HISTORY on the table to see the operation, user and version, then query VERSION AS OF the previous version for the earlier totals. Query history lists queries run, not the table's committed changes.

All customers must appear in a report, including those without orders, with one order status highlighted
✕ Wrong instinct

LEFT JOIN orders, then WHERE orders.status = 'X'

✓ Correct approach

A WHERE condition on the right table discards rows whose right columns are NULL, silently turning the left join into an inner join. Move the status condition into the ON clause to keep unmatched customers.

Support agents may see only the last four phone digits while compliance sees full numbers
✕ Wrong instinct

Create a second redacted copy of the customers table

✓ Correct approach

Apply a column mask function to the phone column that checks group membership with is_account_group_member. Everyone queries the same table; a row filter would be wrong because it hides whole records, not values.

Know these cold

  • ▸ UNION removes duplicate rows; UNION ALL keeps every row and runs faster
  • ▸ WHERE filters rows before grouping; HAVING filters aggregates; QUALIFY filters window function results
  • ▸ Column = NULL never matches; use IS NULL, and COALESCE to fill gaps without dropping rows
  • ▸ TRY_CAST returns NULL on bad strings, whereas CAST under ANSI mode fails the whole query
  • ▸ Dropping a managed table removes its data; dropping an external table leaves files at LOCATION
  • ▸ Metric views define measures once and are queried with the MEASURE function
  • ▸ Predictive Optimization and automatic liquid clustering work only on Unity Catalog managed tables
  • ▸ Delta Sharing and Marketplace give live read-only access; nothing is copied into your storage
  • ▸ Genie users need space access, CAN USE on the warehouse and SELECT on curated tables
  • ▸ Star schemas belong in gold; data vault hubs, links and satellites belong in silver

Can you answer these without checking your notes?

In this scenario: "An expensive three-table join feeds a dashboard every few minutes; hour-old results are acceptable" — what should you do first?
A materialized view stores the precomputed join and aggregation and refreshes on a schedule, matching the one-hour tolerance. A standard view recomputes on every read, and streaming tables suit append-only ingestion, not heavy aggregates.
In this scenario: "An analyst must find who deleted 4,000 rows from a managed table last night and show prior totals" — what should you do first?
Run DESCRIBE HISTORY on the table to see the operation, user and version, then query VERSION AS OF the previous version for the earlier totals. Query history lists queries run, not the table's committed changes.
In this scenario: "All customers must appear in a report, including those without orders, with one order status highlighted" — what should you do first?
A WHERE condition on the right table discards rows whose right columns are NULL, silently turning the left join into an inner join. Move the status condition into the ON clause to keep unmatched customers.

Common Exam Mistakes — What candidates get wrong

Making a warehouse larger when users are queuing at peak

Warehouse size speeds individual heavy queries; the max cluster count absorbs concurrency. When the query profile shows high queue time with many users, raise max clusters. When it shows few files pruned, fix layout with liquid clustering rather than buying compute.

Using a dashboard filter when the value must change the calculation

Filters narrow rows a dataset already returned. A parameter such as :lookback_days is substituted into the dataset SQL, so it can change aggregation windows or logic. Date-range parameters filter before aggregation; field filters never alter the computed numbers.

Expecting row filters to apply per viewer on a dashboard with embedded credentials

Published with embedded credentials, every query runs as the publisher, so all viewers see the publisher's rows and need no table grants. For managers to see only their region, publish without embedded credentials so each viewer's own identity and row filter apply.

Granting SELECT on a table and forgetting the parent privileges

A user needs USE CATALOG on main and USE SCHEMA on main.sales before SELECT on main.sales.orders works. Grants on a catalog or schema also cover tables created later, so choose the narrowest container that meets the request.

Adding every schema table to a Genie space to improve answers

More tables give Genie more ambiguous choices. Accuracy improves with a small set of documented tables, column comments, instructions, and trusted assets for exact business definitions. Prove a change worked by rerunning benchmarks, not with a handful of spot checks.

Resources to help you pass Databricks Data Analyst Associate on your first attempt

Test your SQL output reading, dashboard sharing and Genie curation against the October 2026 outline.