Understanding the Databricks Platform practice questions

Export the dashboard as a PDF and email it directly.

Why it fails: Exporting to PDF is a manual process that lacks real-time data updates. Stakeholders would need a new file every time the underlying data changes. This approach is prone to errors, versioning issues, and does not provide the interactive capabilities required for modern data-driven decision-making within a controlled Databricks framework.

Provide credentials to a service account.

Why it fails: Sharing credentials violates fundamental security principles and Databricks compliance policies. Each user should access resources through their own identity, typically managed via SSO or SCIM. Using shared service accounts obscures audit logs, makes accountability impossible, and introduces significant risks regarding unauthorized data access or accidental modification of production assets.

Grant full workspace access to the stakeholders.

Why it fails: Granting full workspace access is a severe security risk and violates the principle of least privilege. Stakeholders only require dashboard viewing capabilities, not the ability to edit notebooks, create clusters, or access underlying storage files. Workspace access should be restricted to users who actively develop or perform complex administrative data tasks.

To install a new library on the cluster.

Why it fails: The CLI command shown is for listing workspace objects, not for managing library dependencies. Library management would involve different commands, typically targeting cluster configurations. Using the wrong command will not achieve the desired installation results and indicates a lack of understanding regarding the scope of specific CLI utility functions.

To trigger an automated job execution.

Why it fails: Triggering jobs requires the 'databricks jobs run-now' command. The 'workspace list' command is strictly for navigation and metadata discovery of files in the workspace. Using this command will not initiate any data processing workflows, as it does not reference any job definitions or execution parameters needed for automation.

To view the logs of a failed cluster.

Why it fails: Cluster logs are accessed through the cluster UI or via the 'databricks clusters' CLI commands, not the workspace list function. This command focuses on navigating the file system within the workspace, not on diagnosing infrastructure or cluster-level issues which are critical for performance and stability troubleshooting in production.

Query caching on the SQL warehouse

Why it fails: Query caching reuses results for identical queries within a cache window, which speeds up repeated execution but does not guarantee a 15-minute refresh of dashboard data. Cached results can also be stale relative to the streaming updates, so it cannot be relied on to deliver near-real-time sales figures to stakeholders.

A materialized view with automatic refresh

Why it fails: Materialized views can be refreshed on a schedule, but they persist a precomputed result set and are intended to accelerate repeated queries, not to drive dashboard dataset refresh. Choosing this adds storage and refresh management without directly controlling the dashboard's 15-minute update cadence for stakeholders.

Delta Live Tables with a continuous pipeline

Why it fails: Delta Live Tables is a declarative ETL framework for building pipelines, not a dashboard refresh mechanism. While a continuous pipeline could keep the source table fresh, it does not control how often the dashboard's query results are recomputed for viewers, so it does not satisfy the automatic dashboard refresh requirement.

The existing all-purpose cluster with a cron schedule added to the notebook

Why it fails: An all-purpose cluster is designed for interactive, collaborative exploration and is not the recommended compute target for unattended production jobs. Even if a schedule is added, the cluster still must be running or started by the job, and it lacks the SQL-optimized auto-stop and scaling behavior of a SQL Warehouse. It does not cleanly meet the no-manual-intervention requirement.

A job cluster created automatically for each scheduled notebook run

Why it fails: Job clusters are appropriate for scheduled notebooks and jobs, but the scenario is a dashboard refresh, which is a SQL analytics workload. A job cluster would run the notebook but is not the purpose-built compute for serving dashboard queries, and it would not provide the warehouse-level concurrency and auto-stop behavior expected for SQL dashboards.

A personal compute resource assigned only to the analyst's user account

Why it fails: Personal compute is tied to a single user and is intended for individual development, not for shared, scheduled production workloads. It cannot reliably serve a recurring dashboard refresh for multiple stakeholders, and it does not offer the SQL Warehouse scheduling and auto-stop controls. It also creates a single point of failure tied to one user.

Increasing the number of worker nodes on the SQL warehouse

Why it fails: Adding workers increases parallelism and can speed up a query, but it also adds compute cost and does not reduce the volume of data scanned. For a scan-bound query the same bytes are read regardless of worker count, so this does not achieve the goal of lowering data volume and cost.

Setting the SQL warehouse to auto-stop after a long idle period

Why it fails: Auto-stop shuts down an idle warehouse to avoid paying for unused compute between query bursts. It does not change how much data a running query scans, so it cannot reduce bytes read or the per-query scan cost of the large sales table; it only affects idle-time billing.

Enabling verbose query history logging for the warehouse

Why it fails: Query history records executions for troubleshooting and auditing but has no effect on the execution plan or the amount of data read. Turning on verbose logging adds observability, not scan reduction, so it does nothing to lower the cost of querying the large sales Delta table.

SQL warehouse

Why it fails: SQL warehouses are optimized for SQL workloads and are ideal for running queries, but they are managed compute resources specifically for Databricks SQL. They do not allow custom runtime or library configuration, and while they auto-stop, the analyst requires a cluster with configurable runtime and libraries, which SQL warehouses do not provide.

Job cluster

Why it fails: Job clusters are created for automated jobs and are terminated when the job finishes. They are not intended for interactive ad-hoc queries, and the analyst would not be able to run queries interactively. Additionally, job clusters do not support the same auto-termination based on inactivity; they are tied to job execution.

Instance pool

Why it fails: Instance pools provide a pool of idle instances to reduce cluster start times, but they are not a cluster type themselves. The analyst would still need to attach an all-purpose or job cluster to the pool. Using an instance pool alone does not provide the interactive query environment or the auto-termination behavior required.

Copy and paste code into a local text file.

Why it fails: Manual file management is error-prone, lacks auditability, and isolates the code from the collaborative environment. This method ignores the benefits of integrated version control systems, which track changes over time and support team-based development. Relying on local files risks losing code history and makes it difficult to synchronize changes among team members.

Create a new notebook file for every code change.

Why it fails: Creating a new notebook for every change leads to a cluttered workspace and makes tracking the evolution of code nearly impossible. It breaks the continuity of the logic and forces users to manually manage file naming conventions, which is inefficient and highly susceptible to human error during long-term analytical projects.

Download the notebook to their local machine every hour.

Why it fails: Regular manual downloads do not equate to a robust version control system. This process is time-consuming, insecure, and fails to provide a centralized history of changes. It does not facilitate collaboration or allow other team members to contribute to the code, effectively stalling development workflows and undermining the platform's collaborative capabilities.

Running automated production ETL jobs.

Why it fails: Production ETL jobs are best suited for job clusters, which are cheaper and optimized for specific tasks. All-purpose clusters are designed for interactive use, making them inefficient for recurring production workflows where cost optimization and predictability are key requirements for maintaining a healthy and cost-effective data platform architecture.

Long-running streaming data ingestion.

Why it fails: Streaming workloads require high availability and stability, which job clusters provide more effectively at a lower price point. All-purpose clusters are prone to manual intervention and termination, which can cause significant disruptions to continuous data streams, making them unsuitable for reliable, long-running production streaming ingestion tasks in Databricks.

Batch processing of large ML models.

Why it fails: While possible, batch processing is more cost-efficiently handled by job clusters, which terminate immediately upon job completion. Using an all-purpose cluster for large-scale batch model training unnecessarily increases costs due to higher DBU rates and the potential for the cluster to remain idle if not properly managed or configured.

Databricks SQL

Why it fails: Databricks SQL is a service designed for running SQL queries and creating visualizations on data lakes. While it interacts with data, it is not the governance engine itself. It relies on the governance policies defined in other platform components to restrict access to underlying data tables and schemas.

Delta Live Tables

Why it fails: Delta Live Tables is a framework for building reliable and maintainable data pipelines. It focuses on the processing, quality, and transformation of data rather than the governance, discovery, or cross-workspace sharing of data assets. It operates within the context of data engineering pipelines rather than enterprise-wide metadata management.

Compute Clusters

Why it fails: Compute clusters are the processing resources used to execute code and queries. They are the execution engine of the platform, not the governance layer. While they can be configured with specific access policies, they do not provide the centralized discovery or cross-workspace cataloging features inherent to the Unity Catalog.

Automatic data compression to non-standard formats

Why it fails: Delta Lake uses standard Parquet for data storage, not proprietary formats. While it does optimize file sizes through compaction, it does not convert data into non-standard formats. Ensuring compatibility with open standards is a key design goal of Delta Lake, allowing users to read data from other engines.

The ability to run queries without a compute engine

Why it fails: Data stored in Delta Lake still requires a compute engine, such as a SQL Warehouse or a Spark cluster, to process queries. Delta Lake defines the storage format and metadata layer, but it does not remove the necessity for compute resources to execute the actual logic and data transformations.

Increase the number of users connected to the workspace.

Why it fails: Increasing the number of users adds load to the platform and does not improve individual query performance. In fact, it might lead to resource contention, slowing down all users. Performance tuning should focus on optimizing data storage and query logic, not increasing the number of active users.

Delete the table and re-create it without Delta Lake.

Why it fails: Removing Delta Lake would forfeit critical features like ACID compliance and time travel while potentially reducing query performance. Delta Lake is specifically designed to provide superior performance over standard Parquet. Reverting to basic Parquet files would make the data harder to manage and likely slower to query.

Force the notebook to run on a single-node cluster.

Why it fails: Single-node clusters are meant for small datasets and development. For large tables, they lack the distributed computing power required to process data in parallel. Forcing a large-scale query onto a single node will lead to memory errors and extremely slow processing speeds, defeating the purpose of using Databricks.

Change the cluster configuration to use a different Spark version.

Why it fails: Access permissions in Unity Catalog are governed by authorization policies, not the Spark version. Changing the runtime will not bypass security controls. The issue is an identity and access management problem, not a software version compatibility issue. The administrator must grant the correct permissions to the user identity.

Move the data to a local file in DBFS.

Why it fails: Moving data to DBFS circumvents the governance model, which is a major security violation. It also makes the data inaccessible to other users and breaks the centralized cataloging architecture. Analysts should always work within the defined governance framework, not bypass it to circumvent errors triggered by legitimate security controls.

Re-create the table in a different schema.

Why it fails: Re-creating the table does not solve the underlying lack of permissions on the catalog itself. If the user lacks access to the parent container, they will likely encounter similar issues regardless of where they create a new table. Permission issues must be addressed through proper authorization grants, not data movement.

Create a separate view for each user group.

Why it fails: Creating multiple views leads to view proliferation and makes it difficult to maintain and audit security policies. It is an outdated, inefficient practice that is prone to human error. Unity Catalog provides native row-level security functions that are more scalable, manageable, and secure than managing custom views for every user.

Use hard-coded SQL 'WHERE' clauses in every notebook.

Why it fails: Relying on developers to remember to include security filters in their code is highly insecure and prone to failure. If a user forgets to add the clause, sensitive data is exposed. Security must be enforced at the platform level by the administrator, not left to individual developers to implement in their notebooks.

Move sensitive data to a completely separate, private workspace.

Why it fails: Isolating data into a separate workspace is an extreme and unnecessary measure that disrupts collaboration and data integration. It increases administrative overhead and creates data silos. Unity Catalog's fine-grained security policies are designed to handle this requirement within a single, unified environment, making it the preferred approach for modern data governance.

To automatically execute all notebooks in a production pipeline.

Why it fails: The Databricks Assistant is a developer productivity tool, not an automation or orchestration engine. Job scheduling and workflow orchestration are handled by the Jobs component. The Assistant provides coding help, not execution control for production-level pipelines that require rigorous monitoring, error handling, and dependency management for critical business data workflows.

To manage user permissions across the entire workspace.

Why it fails: User permissions are managed by administrators through the workspace settings or Unity Catalog interface, not through an AI coding assistant. The Assistant has no administrative capabilities regarding access control or identity management, as these are critical security functions that require explicit administrative oversight and auditing to ensure compliance.

To store and back up notebook versions automatically.

Why it fails: Version control is provided by the Git integration in Databricks Repos. The Assistant does not manage version history or backups of notebooks. Relying on an AI tool for version control is incorrect, as it lacks the necessary functionality to maintain a structured, auditable history of code changes over time.

They must be manually started every time a user runs a query.

Why it fails: SQL Warehouses support auto-start and auto-stop features, which manage compute resources dynamically based on incoming query traffic. This removes the need for manual intervention, making them highly efficient and user-friendly for BI workloads where users expect immediate responsiveness without needing to understand the underlying infrastructure state.

They support the same multi-language notebook features as all-purpose clusters.

Why it fails: SQL Warehouses are designed for SQL queries, not for multi-language notebook development. They do not support the same interactive notebook environment features as all-purpose clusters, which are intended for data science and complex, multi-language coding tasks that go beyond simple SQL-based analytical workflows and reporting.

They are only available for administrative users.

Why it fails: SQL Warehouses are intended for use by any data analyst or business user who needs to query data. Access is managed through standard workspace and Unity Catalog permissions. Restricting them to administrators would render them useless for their primary purpose of serving broad-scale business intelligence and analytical reporting.

External locations

Why it fails: External locations are used by administrators to define storage locations for the catalog, not by analysts to query data directly. While they facilitate data access, they are not the interface used for performing SQL joins between files and tables, which is the specific task the analyst needs to execute.

Databricks File System (DBFS) mounting

Why it fails: While DBFS mounting can access files, it is less secure and lacks the rich metadata and governance features of Unity Catalog Volumes. Volumes are the recommended approach for modern Databricks development, offering better integration, security, and lifecycle management compared to legacy DBFS mounting methods that are now deprecated.

Manual file upload via a web browser

Why it fails: Manual file uploading is a static process that does not support SQL-based integration or dynamic querying. It is not a scalable or repeatable method for joining data within an analytical pipeline. It is meant for one-off file transfers, whereas Volumes enable persistent, governed access to files for analytical workflows.

Databricks SQL Audit Logs

Why it fails: Audit logs record user actions and access events for security and compliance purposes. While they show who accessed what, they do not provide the structural mapping of data dependencies and lineage across tables and jobs. Lineage is a separate, more advanced feature focused on data movement and transformation dependency tracking.

Delta Live Tables Pipeline Monitoring

Why it fails: While Delta Live Tables provides excellent monitoring and observability for pipeline execution, it is focused on the health and performance of the ingestion process. It does not provide the comprehensive, end-to-end data lineage across the entire organizational data landscape that Unity Catalog offers for all platform data assets.

Cluster Event Logs

Why it fails: Cluster event logs capture hardware and software events related to cluster health and configuration changes. They are useful for troubleshooting performance or infrastructure problems, but they contain zero information about data contents, flows, or the logical dependencies between tables, which is the primary objective of data lineage analysis.

Job Compute

Why it fails: Job Compute is optimized for automated data pipelines and scheduled tasks rather than ad-hoc SQL exploration. While cost-effective, it lacks the specific query-caching and performance optimizations found in SQL Warehouses, and it does not provide the interactive user interface required for analysts to perform live exploratory data analysis.

All-Purpose Compute

Why it fails: All-Purpose clusters support interactive notebooks and multiple languages, but they are generally more expensive than SQL Warehouses for pure SQL workloads. While they can be configured to auto-terminate, they lack the query-specific performance features and the unified SQL interface that makes SQL Warehouses the standard choice for SQL-focused data analysts.

Delta Live Tables Pipeline

Why it fails: Delta Live Tables is an infrastructure service for managing complex data transformation pipelines rather than an interactive query environment. It is designed to handle ETL processes and data quality monitoring, making it unsuitable for an analyst needing to execute individual ad-hoc SQL queries to explore datasets in real-time.

SQL Warehouses must always be co-located in the same cloud region as the Delta Lake storage.

Why it fails: While regional proximity improves latency, SQL Warehouses can access data across different regions if cross-region access is configured. The compute does not strictly require co-location at the physical storage level to function, although it is recommended to minimize network latency and egress costs in production data lakehouse architectures.

Delta Lake is a compute engine that replaces the need for SQL Warehouses.

Why it fails: Delta Lake is an open-source storage layer that brings ACID transactions to data lakes. It is not a compute engine. SQL Warehouses are the actual compute resources used to process and query the data. Confusing storage formats with compute engines leads to incorrect architecture decisions for data processing workflows.

SQL Warehouses require all data to be imported into a proprietary internal database format.

Why it fails: Databricks follows the lakehouse paradigm, where data remains in open formats like Delta Lake on object storage. There is no requirement to import data into a proprietary database. This open approach prevents vendor lock-in and allows other tools to access the same underlying data files simultaneously without interference.

Restart the SQL Warehouse to refresh the user's session token.

Why it fails: Restarting the warehouse does not change the underlying permission model. Permission errors are related to identity and access management policies, not the state of the compute cluster. Re-starting the service will not grant the missing 'CAN_USE' privilege required for the analyst to access the specific compute resource.

Upgrade the user's workspace role to 'Workspace Admin'.

Why it fails: Assigning 'Workspace Admin' is an extreme and unnecessary security risk. Permissions should follow the principle of least privilege. Granting broad administrative rights to fix a specific compute access issue violates security best practices and gives the user far more control than is necessary for performing simple SQL queries.

Increase the maximum number of clusters in the SQL Warehouse configuration.

Why it fails: Scaling the number of clusters addresses performance and concurrency issues, not permission denials. The error message is explicitly related to security authorization, not capacity or resource exhaustion. Adding more clusters will simply result in the same '403 Forbidden' error for the user because their access rights remain unchanged.