Databricks Data Analyst: platform and data
Understanding of the Databricks Data + AI Platform (11%), Managing Data (8%) and Importing Data (5%) are 24% of the Data Analyst Associate exam between them — around 11 of the 45 scored questions.
These are the foundations. None is large individually, but together they are nearly a quarter of the paper, and they underpin every other section.
Understanding the platform (11%)
- The lakehouse idea — one storage layer serving analytics and engineering, rather than a warehouse kept in sync with a lake.
- Delta tables as the default format, and what that gives you: ACID transactions, schema enforcement, time travel.
- How the workspace is organised: catalogs, schemas, tables, dashboards, queries.
- Where Databricks SQL sits — the analyst-facing surface.
SQL warehouses deserve particular attention:
- They are the compute that runs your queries, distinct from all-purpose clusters.
- Size affects query speed and cost. Bigger is faster and more expensive, and not always the right answer.
- Auto-stop shuts a warehouse down when idle. A warehouse left running overnight bills for nothing, and this is a recurring exam scenario.
- Scaling handles concurrency — many users at once — rather than making a single query faster.
The distinction the exam tests: size for query complexity, scaling for concurrency, auto-stop for cost.
Managing data (8%)
- The catalog → schema → table hierarchy.
- Creating and altering tables and views.
- Managed versus external tables: managed tables have their data lifecycle tied to the table, so dropping one deletes the data. External tables point at data you manage elsewhere, and dropping the table leaves the data. This is reliably tested.
- Basic table maintenance from an analyst’s perspective.
Importing data (5%)
About two questions. Cover it briskly:
- Loading files into tables through the UI and with SQL.
- Connecting to external data.
- Basic schema handling on load.
The ingestion approaches the outline names
The first Importing Data objective asks you to explain the approaches for bringing data into Databricks: ingestion from S3 (or any cloud object storage), data sharing with external systems through Delta Sharing, API-driven intake, Auto Loader, and Marketplace. You need to know what each one is for, not how to configure it.
| Approach | What it does | Signal in a question |
|---|---|---|
| Files in cloud storage | Load files from S3, ADLS or GCS into a table, for example with COPY INTO or the add-data UI | A one-off or scheduled load of files that already exist |
| Auto Loader | Watches a storage path and loads each new file once, tracking progress in a checkpoint and adapting when new columns appear | “New files keep arriving”, “load only what is new” |
| Delta Sharing (now OpenSharing) | Another organization gives you read-only access to live tables without copying them; in a Databricks workspace they appear as a catalog you can query | “A partner already publishes the data”, “no copies, always current” |
| Marketplace | Find and get data products from providers, delivered through the same sharing protocol | “Third-party or public datasets” |
| API-driven intake | Code calls a REST API and writes the result to a table, usually in a scheduled job | A SaaS system with no file export |
Name change to know. Databricks and Microsoft Learn documentation now call Delta Sharing OpenSharing; the old /delta-sharing/ documentation addresses redirect to pages titled “What is OpenSharing?”. This exam guide still says Delta Sharing, so treat the two names as the same feature. The two flavours are Databricks-to-Databricks sharing, for recipients with a Unity Catalog workspace, and open sharing (Databricks-to-Open) for recipients on any other tool. A shared table is read-only for you as the recipient; you query it, you do not write to it.
Auto Loader at analyst level is a concept: incremental, exactly-once loading of files as they land, typically set up by a data engineer. If a question asks how new daily files should reach a table without reloading old ones, Auto Loader is the answer; the configuration belongs to the Data Engineer Associate.
Pitfall: “a partner wants to give us their sales tables” is a sharing scenario, not a file-export one. Options that copy files to storage and then load them work, but they create stale copies, which is the problem sharing removes. More detail is in the Auto Loader and Delta Sharing (OpenSharing) guides.
This exam is not about building ingestion pipelines. That is the Data Engineer Associate.
Sample questions
Question 1. A SQL warehouse is sized 2X-Large because occasionally a complex query is slow. Most of the day, thirty analysts run small queries and the warehouse sits mostly idle. What is the most cost-effective adjustment?
- A. Keep the 2X-Large warehouse running continuously for consistent performance
- B. Disable auto-stop so the warehouse is always warm
- C. Reduce the size, enable scaling for concurrency, and configure auto-stop
- D. Ask analysts to batch their queries into scheduled runs
Show answer
Answer: C
A smaller warehouse with scaling handles many concurrent small queries economically while auto-stop removes idle cost, matching the actual usage pattern. Keeping a large warehouse running wastes money, disabling auto-stop worsens it, and asking analysts to batch queries does not address the mismatch.
Want more questions like this? Full Data Analyst practice tests →
Question 2. An analyst drops a managed table, believing only the table definition will be removed. What actually happens?
- A. Both the table definition and the underlying data are removed
- B. Only the table definition is removed; the data remains
- C. The table is archived and can be restored from the UI indefinitely
- D. The operation fails because managed tables cannot be dropped
Show answer
Answer: A
Dropping a managed table removes the underlying data as well, because a managed table’s data lifecycle is tied to the table. An external table would leave the data in place, which is the distinction being tested.
Want more questions like this? Full Data Analyst practice tests →
Question 3. An organisation keeps raw files in its own cloud storage and wants a Databricks table over them without Databricks taking ownership of the files' lifecycle. What should be created?
- A. A managed table
- B. A temporary view
- C. A copy of the files imported into a managed table
- D. An external table over the existing storage location
Show answer
Answer: D
An external table references data in a location the organisation manages, so dropping the table does not delete the files. A managed table would tie the data lifecycle to the table, a temporary view does not persist, and copying the files duplicates storage.
Want more questions like this? Full Data Analyst practice tests →
Question 4. A supplier that also runs Databricks with Unity Catalog wants to give your analysts read access to its live inventory tables. Your team wants no file copies and always-current data. Which approach fits?
- A. Delta Sharing (OpenSharing) from the supplier to your workspace
- B. A nightly CSV export to your cloud storage
- C. Auto Loader over a folder the supplier writes files to
- D. A file upload through the workspace UI
Show answer
Answer: A
Delta Sharing, now called OpenSharing in the Databricks documentation, gives a recipient read-only access to live tables without copying them, and Databricks-to-Databricks sharing suits a supplier and recipient that both use Unity Catalog. A nightly CSV export creates stale copies. Auto Loader would only load the exported files incrementally, still from copies. Uploading a file through the UI is a one-off manual load.
Want more questions like this? Full Data Analyst practice tests →
What to practise
Create one managed table and one external table, then drop both and see what survives. Size a SQL warehouse down and enable auto-stop, then check what it costs you overnight.
Two short exercises covering the most testable ideas across all three sections.