Practice Test #1

This is incorrect because Workflows is a job orchestration feature, not the standard mechanism for establishing a partner integration with Fivetran. While SQL warehouses can be created in Databricks, Workflows does not represent the intended setup path for external partner connectivity. The question asks for an approach used to connect Databricks to Fivetran, and Partner Connect is the purpose-built feature for that use case. Therefore this option mixes the wrong service with the wrong setup model.

This is incorrect because Delta Live Tables is used to build and manage declarative ETL pipelines inside Databricks. It is not a feature for provisioning external access points or configuring third-party ingestion tools like Fivetran. Even though DLT may use compute under the hood, it does not serve as the connection mechanism for partner integrations. As a result, this option confuses internal pipeline tooling with external connectivity setup.

This is incorrect because although Partner Connect is the right integration mechanism, the SQL warehouse portion does not match the expected setup pattern for this question. The exam framing distinguishes the Fivetran connection from Databricks SQL analytics endpoints used by BI tools. Fivetran is being tested here as a partner ingestion integration rather than a SQL client connection. Therefore the cluster-based Partner Connect option is the better answer.

This is incorrect because Workflows is intended to schedule and orchestrate Databricks jobs, not to create a partner integration endpoint for Fivetran. Starting or managing a cluster through Workflows does not by itself establish the Databricks-to-Fivetran connection. The question is specifically about how to connect Databricks to Fivetran, and Partner Connect is the dedicated feature for that purpose. Thus this option uses the wrong Databricks service even if it mentions a cluster.

Incorrect. Databricks SQL overlaps with BI tools (dashboards, visualizations, sharing), but it is not an exact substitute with the same breadth of functionality. Enterprise BI platforms typically provide richer semantic modeling, advanced formatting, extensive visualization customization, and mature distribution/reporting workflows. The exam expects you to recognize Databricks SQL’s strengths while acknowledging it doesn’t fully match dedicated BI suites feature-for-feature.

Incorrect framing. While Databricks SQL may have fewer presentation/reporting features than some BI tools, describing it as merely a “substitute with less functionality” misses the intended positioning. Databricks SQL adds unique value by being native to the lakehouse (governed data access, minimal data movement, tight integration with SQL Warehouses). The relationship is complementary rather than a downgrade substitute.

Incorrect. Databricks SQL is not generally positioned as a complete replacement for Tableau/Power BI/Looker with additional functionality. Those tools often remain preferred for enterprise reporting, semantic layers, and polished executive dashboards. Databricks SQL can reduce reliance on external BI for some use cases, but the typical best practice is coexistence and integration, not wholesale replacement.

Not the best choice. External BI tools are usually the go-to for professional-grade presentations and pixel-perfect reporting. Databricks SQL can produce shareable dashboards, but the exam typically distinguishes it as better suited for quick, collaborative, in-platform analytics rather than being the primary tool for high-polish presentation deliverables across the organization.

Separate endpoints (SQL warehouses) control where queries run (compute), not how a dashboard is labeled or visually organized. You could run different queries on different warehouses, but that does not place section header text on the dashboard. This option confuses execution infrastructure with dashboard presentation features.

Separate queries can power different charts/tables, but queries themselves do not provide a way to display section header text unless you create a visualization that renders text (which is not the standard approach). The question specifically asks for a tool to designate sections using text, which is a dashboard layout feature, not a query feature.

Databricks dashboards do not typically support “direct text written into the dashboard” as freeform typing on the canvas without using a widget. Text must be added via a text/Markdown widget. This option sounds plausible if you assume a slide-editor style interface, but Databricks uses widgets for dashboard elements.

Separate color palettes can help visually distinguish sections, but they do not “designate using text,” which is explicitly required. Colors are a styling choice and may not be accessible for all users (e.g., color vision deficiencies). The question asks for a text-based designation tool, making this insufficient.

A is not the best answer because it is only one of several required considerations when handling PII. Organization-specific best practices are important, but analysts must also account for applicable legal and regulatory requirements tied to where the data was collected and where it is processed. Choosing A alone ignores the broader compliance landscape that governs PII use. On exams, when multiple listed factors are all relevant, the more complete 'all of these considerations' option is preferred.

B is not the best answer because legal requirements in the area where the data was collected are only part of the picture. PII obligations may also be affected by the jurisdiction where the analysis or processing occurs, as well as by internal organizational policies and controls. Selecting B alone would be too narrow for a comprehensive governance question. The exam is testing awareness that PII handling usually involves multiple overlapping obligations.

C is incorrect because PII always requires governance, security, and compliance consideration. Analysts must think about internal handling standards, access restrictions, and applicable privacy laws before using such data. Ignoring these factors can create regulatory, contractual, and security risk. Therefore, 'None of these considerations' is clearly wrong.

D is not the best answer because the legal requirements where analysis is performed are relevant, but they are not the only factor analysts should consider. PII handling also depends on the jurisdiction of collection or data subjects and on organization-specific policies for secure use and access. Choosing D alone would omit other important obligations. The most complete and accurate choice is the option that includes all relevant considerations.

Incorrect. Data Explorer is not the feature that “runs UPDATE queries.” DML (UPDATE/DELETE/MERGE) is executed through the SQL editor (or notebooks/jobs) against supported tables (commonly Delta tables) and subject to permissions and warehouse capabilities. Data Explorer may help you locate the table, but it is not the mechanism that provides UPDATE execution.

Incorrect. Producing dashboards for data exploration is a Databricks SQL dashboard capability, not a Data Explorer capability. Dashboards are built from queries and visualizations and then arranged into dashboard pages with filters and parameters. Data Explorer supports discovery of data assets, not dashboard authoring.

Incorrect. Creating and sharing visualizations is done from query results in the SQL editor and then shared directly or embedded into dashboards. Data Explorer can help you find the underlying tables, but visualization creation/sharing is not its primary function.

Incorrect. Connecting to third-party BI tools is enabled via Databricks SQL warehouses and supported connectors (e.g., JDBC/ODBC, partner integrations). Data Explorer does not provide BI connectivity; it is an internal UI for discovering and governing data objects within Databricks.

Incorrect. Ownership cannot be set by simply “removing” the current owner from an Owner field. A Unity Catalog object must always have exactly one owner principal. While you can remove your own privileges, that does not transfer ownership. In the UI, changing ownership requires explicitly selecting a new owner, not deleting the existing one.

Incorrect. “All Users” is not a valid single owner principal for Unity Catalog objects. Even if “all users” can be granted privileges, ownership is not a privilege grant and cannot be assigned to a broad collective principal. The question specifically requires transferring ownership to a single other user.

Incorrect. Ownership cannot be assigned to a group such as “Admins.” Groups are used to manage privileges (GRANT SELECT, MODIFY, etc.) across many users, but the owner must be a single user or service principal. Admins can still manage objects via metastore admin rights, but that is not the same as being the owner.

Incorrect. Removing all access (revoking privileges) does not change the owner. Ownership is a separate attribute from permissions. Even if you revoke privileges from everyone, the table still has an owner, and the current owner remains unless explicitly changed to another principal.

This describes LEFT OUTER JOIN behavior (return all customers plus matching orders, filling missing right-side values with NULL) and then swaps tables for the second statement. LEFT SEMI/ANTI joins do not return right-table columns and do not produce NULL-extended rows. So A is incorrect for both statements.

Incorrect. The two join types are opposites: semi keeps matching left rows; anti keeps non-matching left rows. Unless the data is degenerate (e.g., all customers match and none match simultaneously, which cannot happen), the result sets will differ in general.

Incorrect. Databricks SQL supports LEFT SEMI JOIN and LEFT ANTI JOIN as part of Spark SQL. These join types are commonly used for EXISTS/NOT EXISTS style filtering and are valid syntax in Databricks SQL.

Incorrect. It correctly states the anti join behavior for statement 2, but it incorrectly claims statement 1 returns all customers and only customer_id from orders. LEFT SEMI JOIN does not return any right-table columns and does not return all customers—only those with matches.

Incorrect. This option uses invalid SQL function-call syntax: "SELECT PRICE customer_spend, customer_units" omits parentheses and a comma-separated argument list. It also would select two columns (or mis-parse entirely) rather than compute a single derived value. Correct SQL requires price(customer_spend, customer_units) to pass both arguments to the UDF and then alias the result.

Incorrect. "SELECT price - FROM customer_summary" is syntactically invalid and does not pass any arguments to the UDF. The hyphen appears to be mistakenly copied from the function definition (RETURNS DOUBLE - RETURN ...), but that hyphen is not part of valid Databricks SQL UDF syntax. A scalar UDF must be invoked with parentheses and required parameters.

Incorrect. Databricks SQL does not require (or generally support) wrapping a UDF call in a function(...) construct. The correct approach is to call the UDF directly as an expression. This option also suggests a misunderstanding of higher-order functions or function references; scalar SQL UDFs are invoked directly with their name and arguments.

Incorrect. While explicit casting can be done in SQL (e.g., CAST(expr AS DOUBLE) or DOUBLE(expr) in some dialects), it is unnecessary here because the UDF already returns DOUBLE. More importantly, the cast syntax shown (double(price(...))) is not the standard Databricks SQL cast form; Databricks SQL commonly uses CAST(... AS DOUBLE). Even if accepted, it’s not the best/expected answer.

Incorrect. COUNT(*) does not inherently “count all customers no matter the region” when used in a grouped query; it counts rows within each group. The real issue is that the query is not grouped at all, so it cannot produce per-region counts. With a proper GROUP BY region, COUNT(*) is exactly the right function to count customers per region.

Incorrect. ORDER BY is allowed with aggregation; it is evaluated after the aggregation step. You can sort aggregated results by region, by the aggregate alias, or by an expression. The presence of ORDER BY is not the problem—missing GROUP BY is.

Incorrect. The query will fail in Databricks SQL because region is selected without being aggregated or grouped. Even if some SQL dialects have non-standard behaviors, Databricks SQL follows standard aggregation semantics and will raise an error rather than returning arbitrary region values.

Incorrect. region should appear in the SELECT list because the requirement is to count customers “in each region,” meaning region must be part of the output. It is also valid to use region in ORDER BY. The mistake is not selecting region; it is failing to group by region.