What you will be able to do
- Name the Unity Catalog object types a Genie space can be built on and explain how each one stores or presents data.
- Apply the 'stay focused' guidance to choose a small, purpose-specific set of data objects for a business domain.
- Decide when to prejoin tables into a view or metric view instead of attaching the raw tables.
- Explain why attaching an object is the boundary of what Genie can query, and how end-user permissions still apply.
Key concept
Attachment is the retrieval boundary — A Genie space only answers from the Unity Catalog objects you explicitly attach to it. Mentioning a table elsewhere in the space does not make it queryable. Curation therefore means deciding which objects go inside that boundary, and each user's own permissions still decide which rows and columns they can see.
1.What a Genie space can be built on
The exam guide says "Genie space". Current Databricks documentation calls the same thing a Genie Agent, and the product pages state plainly that Genie Agents were formerly known as Genie Spaces. This lesson treats the two names as one product. A Genie space is a natural-language chat surface over governed, structured data. In Chat mode Genie works with structured data only, so documents and PDFs are not candidates for curation here. That makes it a different retrieval surface from AI Search.
The first rule of curation is that the data has to live in Unity Catalog. Within Unity Catalog, Genie accepts a wider set of objects than the exam bullet lists: managed tables, external tables, foreign tables, views, metric views and materialized views. A managed table is simply the default table type. Genie does not require it.
These objects behave differently, and the differences matter when you decide what to attach. A table stores data. A view stores only a query, so it can reshape or combine tables without duplicating them. A materialized view precomputes and stores its query's result, which makes it faster to query but uses extra storage. A metric view goes further than a standard view. A standard view fixes its aggregations and groupings when it is created. A metric view defines a measure once and lets the query engine compute it correctly for whatever grouping the user asks for.
| Object | Stores data? | What it gives a Genie space |
|---|---|---|
| Managed table | Yes. It is the default table type in Databricks. | Raw or curated facts, queried directly |
| View | No. It is a virtual table defined by a query. | Simplifies complex queries and encapsulates business logic, for example a prejoin |
| Materialized view | Yes. It stores the query's precomputed result. | Faster queries over a defined result, at the cost of extra storage |
| Metric view | Defines measures separately from the fields used to group them | Metrics defined once that can be grouped by any available field |
Checkpoint 1 of 6· Match them up
Match each Unity Catalog object to its defining behaviour
Tap a term, then the definition that fits it.
Views store no data. Materialized views store results. Metric views separate measures from the fields used to group them. Managed tables are the default table type.
“A view is a virtual table defined by a query that does not store data”Source: docs.databricks.com
2.Selecting for one domain: small and focused
Start from the audience and the questions, not from the catalog. Databricks says an agent should serve one topic and one audience, not general questions across several domains. In practice, attach only the tables needed to answer the questions you expect, and aim for five or fewer. The narrower the selection, the better. That applies to columns as well as tables: limit the columns in the tables you include, and hide columns that might confuse Genie or don't matter.
Start small on purpose. The documentation calls curation iterative. Begin with the essential tables and minimal instructions, then add more based on feedback and monitoring rather than trying to make it perfect at the start. The 50-object limit is a ceiling, not a target. A space that gets close to it is usually covering more than one domain.
Prefer well-annotated objects. Genie uses Unity Catalog column names and descriptions to generate SQL, so a table with clear names and accurate descriptions makes a better candidate than an undocumented one with the same data. Also check what metadata Genie actually receives. Owner and table size are not included by default. If users will ask about them, the documentation points to the information schema views.
Checkpoint 2 of 6· Exam question
A retail analytics team is curating a Genie space so store managers can ask sales questions in natural language. The underlying data lives in a raw orders table plus separate product, customer, and store dimension tables that must be joined for every meaningful question. What should the curators do before adding assets to the Genie space?
Correct answer: B — Build a pre-joined, denormalized view combining orders with the product, customer, and store attributes, then curate it
- A. Incorrect: leaving four raw tables un-joined forces Genie to infer join logic on every question, increasing ambiguity and the chance of incorrect or missed joins.
- B. Correct: pre-joining and denormalizing removes ambiguity about which keys and columns to combine, so Genie can answer directly from one curated, business-ready asset.
- C. Incorrect: instructions are meant as a last resort for guidance, not a substitute for encoding join logic in the data itself, and this approach still leaves join ambiguity unresolved.
- D. Incorrect: a straight, unchanged copy of each raw table does nothing to resolve the underlying join complexity that store managers' questions require.
- E. Incorrect: SQL functions are best reserved for reusable calculation logic, not as a mechanism to perform structural joins across four separate raw tables on every query.
Checkpoint 3 of 6· Check yourself
You are building a Genie space for regional sales managers. Which starting selection best follows Databricks curation guidance?
The guidance is to include only what the target questions need, aim for five or fewer tables, and limit the columns.
“Include only the tables necessary to answer the questions you want the agent to handle. Aim for five or fewer tables.”Source: docs.databricks.com
3.Prejoining into views and metric views
What if a domain really does need data spread across many tables? Don't attach them all. Databricks recommends prejoining related tables into views or metric views before you add them. This keeps the space within the limit, simplifies the data model Genie has to reason over, and can improve accuracy. The best-practices blog gives the reason: pre-joining removes complexity from the generated queries and lowers the risk of a wrong join or aggregation.
Metric views are called out as particularly effective. They predefine metrics, dimensions and aggregations, so Genie inherits one approved definition of something like revenue instead of rebuilding it per query. The same blog adds a modeling rule. If certain rows or columns should never be queried, remove them during data engineering rather than relying on instructions to steer Genie away from them.
A standard view fixes its aggregation and grouping when it is created, so a question that groups the data differently needs a new view or ad hoc SQL. A metric view defines the measure once and lets the engine compute it for any available grouping, so every Genie query uses the same definition.
Checkpoint 4 of 6· Check yourself
A supply-chain domain needs data from about 70 normalized tables. What is the recommended curation move?
Instructions cannot make unattached tables queryable. The documented answer for domains over the limit is to prejoin into views or metric views.
“prejoin related tables into views or metric views before adding them to your agent”Source: docs.databricks.com
4.Attachment is the boundary, and permissions still apply
Choosing objects matters because nothing outside the selection is reachable. Genie does not query tables or Unity Catalog functions that are not attached, even when the space's instructions or metadata name them. A text instruction that says "also use the returns table" does nothing unless that table is attached under Sources.
There is a second, less obvious consequence. Genie does not suggest existing Databricks SQL queries on tables that aren't in the space. Suppose you build a joined view just for Genie, but your team's saved queries run against the original source table. Genie will not surface those queries.
Attaching an object also doesn't widen anyone's access. The warehouse credential embedded in the space grants compute only. Data access is always checked against each end user's own Unity Catalog permissions.
Checkpoint 5 of 6· Put it in order
Put the steps for creating a Genie space with its initial data selection in order
- 1.Click New in the upper-right corner
- 2.Review Genie Code's suggested context and accept what you want to keep
- 3.Click Genie Agents in the sidebar
- 4.Click Create
- 5.Choose the data sources to include
You choose the data sources before clicking Create. Genie Code then launches and suggests context for you to review.
“Choose the data sources that you want to include in your Genie Agent. Then, click Create.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A curator has already added 28 tables and views to a marketing Genie space and now wants to add three more raw tables plus two new parameterized example queries to support upcoming use cases. Given Databricks' curation limits for Genie spaces, what should the curator do?
Correct answer: A — Recognize tables and views share a combined 30-object cap; adding all three tables would exceed it, so prioritize first
- A. Correct: Genie spaces support up to 30 tables or views total, so 28 existing plus 3 new tables would exceed the cap; the curator must prioritize which tables matter most or consolidate them first.
- B. Incorrect: it is tables and views, not SQL functions, that are subject to the 30-object limit, so this reasoning is backwards.
- C. Incorrect: the 30 table/view limit is a real, documented constraint, not an unlimited allowance.
- D. Incorrect: parameterized example queries are not counted against the 30 table/view limit, so removing them would not free up capacity for new tables.
- E. Incorrect: SQL functions are not counted against the same 30-item table/view limit, so removing them would not resolve the table overage.
Sources2
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Naming a table in the space's instructions or metadata lets Genie query it even though it isn't attached.Why is that wrong?
Genie queries only the sources explicitly attached. References in instructions or metadata don't extend that boundary.
Covered in Attachment is the boundary, and permissions still apply
2.If you replace a source table with a joined view built for Genie, the team's existing SQL queries on the source table still show up as suggestions.Why is that wrong?
Genie suggests queries only on objects added to the space. Queries that run against an unattached source table are not returned.
Covered in Attachment is the boundary, and permissions still apply
3.Attaching more tables, up to the limit, makes a Genie space more accurate because it has more context.Why is that wrong?
Databricks recommends a narrow selection: only what the target questions need, ideally five or fewer tables, with column counts kept low as well.
Covered in Selecting for one domain: small and focused
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A Genie Agent is based on data registered to Unity Catalog, including managed tables, external tables, foreign tables, views, metric views, and materialized views.”
↩︎ What a Genie space can be built on“In Chat mode, Genie works with structured data only.”
↩︎ What a Genie space can be built on“Some table details, such as the owner and table size, are not included by default.”
↩︎ Selecting for one domain: small and focused - 2.
“Genie Agents were formerly known as Genie Spaces.”
↩︎ What a Genie space can be built on“Data access is always evaluated using each end user's own Unity Catalog permissions.”
↩︎ Attachment is the boundary, and permissions still apply“Genie does not suggest queries on tables that are not added to the agent.”
↩︎ Attachment is the boundary, and permissions still apply“A Genie Agent uses only the data sources explicitly attached under its Sources.”
↩︎ Key concept“Genie does not query tables or Unity Catalog functions that are not attached, even if the agent's instructions or metadata reference them.”
↩︎ Exam trap 1“Genie does not suggest queries on tables that are not added to the agent.”
↩︎ Exam trap 2“Choose the data sources that you want to include in your Genie Agent. Then, click Create.”
↩︎ Checkpoint - 3.
“The default table type created in Databricks is a Unity Catalog managed table.”
↩︎ What a Genie space can be built on“a materialized view precomputes and stores the query's result”
↩︎ What a Genie space can be built on“A view is a virtual table defined by a query that does not store data”
↩︎ Checkpoint - 4.
“Standard views lock in aggregations and groupings at creation time.”
↩︎ What a Genie space can be built on - 5.
“An agent should answer questions for a particular topic and audience, not general questions across various domains.”
↩︎ Selecting for one domain: small and focused“Hide any columns that might be confusing or unimportant.”
↩︎ Selecting for one domain: small and focused“Genie uses Unity Catalog column names and descriptions to generate responses.”
↩︎ Selecting for one domain: small and focused“Metric views are particularly effective for Genie Agents because they pre-define metrics, dimensions, and aggregations.”
↩︎ Prejoining into views and metric views“Aim for five or fewer tables. The more focused your selection, the better.”
↩︎ Exam trap 3“Include only the tables necessary to answer the questions you want the agent to handle. Aim for five or fewer tables.”
↩︎ Checkpoint“prejoin related tables into views or metric views before adding them to your agent”
↩︎ Checkpoint - 6.https://www.databricks.com/blog/data-dialogue-best-practices-guide-building-high-performing-genie-spacesSecondary source
“Pre-joining tables removes complexity from generated queries and reduces the risk of incorrect joins or aggregations.”
↩︎ Prejoining into views and metric views“Do not rely on instructions or prompts to compensate for poor modeling choices.”
↩︎ Prejoining into views and metric views