Explanations

Question 1

• E. A data lakehouse enables both batch and streaming analytics.

Explanation:

A significant advantage of a data lakehouse over a traditional data warehouse is its ability to handle both batch and streaming analytics. Traditional data warehouses were primarily designed for batch processing, and they might struggle with real-time data ingestion and streaming analytics. On the other hand, a data lakehouse can accommodate both without any significant performance impact. The other options either are capabilities of both systems or don’t accurately describe the features of a data lakehouse.

Question 2

• A. Data plane

Explanation:

The Data Plane in Databricks hosts the driver and worker nodes of a Databricks-managed cluster. It is responsible for the execution of jobs and computation tasks. The Control Plane, on the other hand, is where the user interface, REST API, job launching, and cluster management operations take place. The Databricks Filesystem, JDBC data source, and Databricks web application are not physical locations, so they don’t host driver or worker nodes.

Question 3

• D. A data lakehouse stores unstructured data and is ACID-compliant.

Explanation:

A data lakehouse, such as Delta Lake, can meet the needs of both workloads because it can handle unstructured data (like video files for machine learning workloads) and is ACID-compliant (which is a key requirement for highly audited batch ETL/ELT workloads). ACID compliance ensures transactional reliability, which is essential for ETL/ELT processes.

The other options do not fully capture the dual functionality that a data lakehouse can provide for both types of workloads. Option B and C are incorrect because even though they are features of a data lakehouse, they do not directly address the needs of both machine learning and ETL/ELT workloads. Option A is incorrect because data lakehouses do require data modeling. Lastly, option E is also incorrect because a data lakehouse does not have to fully exist in the cloud - it can be implemented on-premises or in a hybrid environment as well.

Question 4

• C. An automated workflow needs to be run every 30 minutes.

Explanation:

Job clusters are specifically designed for running scheduled or automated tasks, like an automated workflow that needs to run every 30 minutes (option C). They are spun up when the job starts and are terminated when the job finishes, thus providing efficient use of resources for tasks that do not require a constantly running cluster.

On the other hand, all-purpose clusters are meant for interactive analysis and collaboration - they are not the best choice for running scheduled jobs, as they are not automatically terminated when a task finishes and therefore could incur unnecessary costs if not manually shut down. This is why options A, B, D, and E are not the best use cases for job clusters.

Question 5

• C. Data Explorer

Explanation:

Data Explorer in Databricks is the place where data engineers or data scientists can manage the permissions on tables. You can grant, revoke, or list permissions on your Delta tables for individual users or groups. In this scenario, the data engineer would use Data Explorer to give SELECT permission on the Delta table to the data analysts.

Other Options Explanation:

• A. Repos: Databricks Repos are used for version control and collaboration on code in notebooks, not for managing permissions on Delta tables.

• B. Jobs: The Databricks Jobs service is used for scheduling and running jobs, not for managing permissions on Delta tables.

• D. Databricks Filesystem: Databricks Filesystem (DBFS) is a distributed file system installed on Databricks clusters. It’s used for storing data, not for managing permissions on Delta tables.

• E. Dashboards: Dashboards in Databricks are used for visualizing and sharing results, not for managing permissions on Delta tables.

Question 6

• B. Databricks Notebooks support real-time coauthoring on a single notebook

Explanation:

Databricks Notebooks support real-time coauthoring, which allows multiple users to simultaneously work on the same notebook, thus enhancing collaboration. Each user can see the other’s updates in real time. This feature makes it more efficient for the two junior data engineers to collaborate on the same notebook compared to working on separate Git branches and subsequently merging changes. Options A, C, D, and E, while true capabilities of Databricks Notebooks, do not directly address the specific collaboration scenario in question.

Question 7

• E. Databricks Repos can commit or push code changes to trigger a CI/CD process.

Explanation:

Databricks Repos can be used to connect a notebook to a Git repository, which facilitates version control and continuous integration/continuous delivery (CI/CD) workflows. When changes are committed or pushed to the Git repository, this can trigger a CI/CD process, such as automated testing or deployment. While Databricks Repos does interact with Git branches (Option B) and serves as a link between Databricks and your Git repositories (Option D), it doesn’t facilitate the pull request, review, and approval process (Option A), merge changes (Option B), or trigger Git automation pipelines (Option C).

Question 8

• B. Delta Lake is an open format storage layer that delivers reliability, security, and performance.

Explanation:

Delta Lake is an open-source storage layer that brings ACID (Atomicity, Consistency, Isolation, Durability) transactional capabilities to Apache Spark and big data workloads. It provides capabilities such as schema enforcement and evolution, data reliability, and high performance, allowing for more reliable and performant big data processing and analytics. While it does store data (Option D), it is not just a data storage format, it enhances data reliability and performance. It is not an analytics engine (Option A), a platform for managing machine learning lifecycles (Option C), nor does it directly process data (Option E).

Question 9

• B. CREATE OR REPLACE TABLE table_name ( id STRING, birthDate DATE, avgRating FLOAT )

Explanation:

In this case, the correct answer is B because it correctly uses the CREATE OR REPLACE TABLE command and includes the column names and data types within parentheses. The other options either use the wrong keywords or incorrect syntax. Note that the USING DELTA keyword is not required here because the question doesn’t specify that a Delta table is needed. However, if a Delta table was required, the USING DELTA keyword could be added to the end of the command.

Question 10

• C. INSERT INTO

Explanation:

The “INSERT INTO” statement is used in SQL to insert new records in a table. This is true for both traditional SQL databases and Delta Lake tables in Databricks.

The other options are not used for appending new rows to a table:

• UPDATE: This is used to modify existing records in a table.

• COPY: This is not a standard SQL command to insert new records into a table.

• DELETE: This is used to remove records from a table.

• UNION: This is used to combine rows from two or more tables based on a related column between them, not to append new records into a single table.

Question 11

• B. Z-Ordering

Explanation:

Z-ordering is a technique in Delta Lake that co-locates related information in the same set of files. Z-ordering maps multidimensional data to one dimension while preserving the locality of the data points. A primary use-case for Z-ordering is for queries that contain a filter on the dimension columns. In such cases, reading the table causes only a minimum amount of data to be read thus improving the query’s performance.

• Data skipping is an optimization where a query skips over files whose metadata indicate they don’t match a query’s predicate.

• Bin-packing is an optimization that combines small files into larger ones for more efficient reads.

• Writing as a Parquet file is not an optimization technique, it is a file format.

• Tuning the file size, while it can improve the query performance, it would not help in this case as the data that meets the condition is scattered throughout the data files. So, considering all options, Z-Ordering is the most suitable answer.

Question 12

• C. CREATE DATABASE IF NOT EXISTS customer360 LOCATION ‘/customer/customer360’;

Explanation:

In Databricks, databases are used to organize tables into logical groups. The statement CREATE DATABASE IF NOT EXISTS creates a database with a specified name if it doesn’t already exist. The LOCATION clause is used to specify the DBFS path where the database is stored. Here, the requirement is to create a database named customer360 at the location /customer/customer360, and to avoid an error if the database already exists. Thus, the SQL command that fulfills this requirement is CREATE DATABASE IF NOT EXISTS customer360 LOCATION ‘/customer/customer360’;.

The other options do not satisfy all of these conditions. Specifically, options A and E will cause an error if the database already exists, and options B and D don’t specify the correct location. The DELTA keyword in options D and E is not used in the CREATE DATABASE statement in Databricks.

Question 13

• E. CREATE TABLE my_table (id STRING, value STRING);

Explanation:

In Databricks, if you don’t specify a LOCATION when you’re creating a table, it becomes a managed table by default and its data and metadata are stored in the Databricks Filesystem (DBFS). This is true even if you don’t explicitly use the term “MANAGED” in your CREATE TABLE command.

So, the command CREATE TABLE my_table (id STRING, value STRING); will create a managed table with the data and metadata stored in DBFS, satisfying the requirements.

Question 14

• A. View

Explanation:

A View in SQL is a virtual table based on the result-set of an SQL statement. A view contains rows and columns, just like a real table. The fields in a view are fields from one or more real tables in the database. It does not store physical data and is used to simplify complex queries, secure data, and present exactly the data that users are authorized to see.

On the other hand, a Temporary View is a view that is visible only to the current session, so it won’t be available to other data engineers in other sessions. Delta Tables, Databases, and Spark SQL Tables involve storing physical data.

Question 15

• A. The tables should be converted to the Delta format

Explanation:

Delta Lake, a storage layer that brings ACID transactions to Apache Spark and big data workloads, would indeed help in this situation.

When using Delta Lake, you can leverage features such as upserts and deletes to modify data, schema evolution to easily add/remove/change a column’s type, and a history of operations performed on a table for auditability.

Furthermore, Delta Lake supports automatic statistics collection which helps with data skipping and improves the performance of queries. Delta Lake also maintains a transaction log that efficiently tracks changes to a dataset. This allows queries to always have a consistent view of the data, even while it is being modified. So, converting the tables to Delta format would ensure up-to-date data in the scenario given.

Question 16

• A. CREATE TABLE AS SELECT statements adopt schema details from the source table and query.

Explanation:

CREATE TABLE AS SELECT statements adopt schema details from the source table and query. In this SQL command, the new table’s schema is automatically determined based on the result of the SELECT statement. The types and number of columns in the new table will be derived from the SELECT statement used to populate it. In this case, the new table will have two columns: “country” and “customers”. The “country” column type would be the same as the corresponding column in the original table, and “customers” would be of type INT, as it’s a result of the COUNT function.

Question 17

• B. Overwriting a table results in a clean table history for logging and audit purposes.

Explanation:

Overwriting a table does not result in a clean table history for logging and audit purposes. In fact, Delta Lake’s versioning capabilities (known as “Time Travel”) keep a record of every transaction made to the table. This includes overwrites, which can be queried and examined at any point in time. Therefore, overwriting a table does not remove prior versions or create a fresh history. It rather adds a new version to the existing history, enabling users to “travel back in time” and access previous versions of the data. The other statements correctly describe some of the advantages of overwriting a table instead of deleting and recreating it.

Question 18

• C. SELECT DISTINCT * FROM my_table;

Explanation:

The SQL command SELECT DISTINCT * FROM my_table; is used to return unique records from a table, effectively removing duplicates. DISTINCT is a clause in SQL that allows you to eliminate duplicates from the result set of a query. It can work on a single column or multiple columns to find unique tuples (rows) in your table. The other options either do not use valid SQL commands (A, B) or don’t inherently remove duplicates from a result set (D, E).

Question 19

• A. INNER JOIN

Explanation:

The SQL command INNER JOIN is used to combine rows from two or more tables based on a related column between them, which meets the requirement of only including rows whose value in the key column is present in both tables.

OUTER JOIN would include records from both tables, even if there is no match in the key column in one of the tables. LEFT JOIN would return all records from the left table, and the matched records from the right table. MERGE is used to combine rows from two tables based on a related column between them, especially when you want to update or insert data in bulk. UNION is used to combine the result-set of two or more SELECT statements.

Question 20

• D. SELECT cart_id, explode(items) AS item_id FROM raw_table;

Explanation:

In Apache Spark SQL, the explode function is used to create a new row for each element in the given array or map column. Here, the explode function will create a new row for each item_id in the items array for each cart_id, which results in the desired schema with cart_id and item_id as separate columns.

The other options (filter, flatten, reduce, slice) are not suitable for this task. They perform different functions and would not result in the desired schema.

Question 21

• B. SELECT transaction_id, payload.date FROM raw_table;

Explanation:

In this case, the payload is an array of structures (each structure contains customer_id, date, and store_id). To access individual fields in the structure, the “.” (dot) notation is used. So, payload.date will extract the date of each transaction from the payload array.

The SELECT statement in option B retrieves the transaction_id and the date from each record in the raw_table, which results in the desired schema.

The other options would not result in the correct schema because they either attempt to use functions or notations incorrectly (e.g., explode, array index notation), or they don’t attempt to extract the date from the payload structure at all.

Question 22

• A. They could wrap the query using PySpark and use Python’s string variable system to automatically update the table name.

Explanation:

The best way to automate this process would be to use PySpark and Python’s string variable system to update the table name dynamically. By using Python’s date and time functionality, the team could automate the insertion of the current date into the query.

The other options either involve manual intervention (Option B), are unlikely to meet the data analyst’s needs (Option C), or don’t address the requirement of updating the table name with the current date (Options D and E).

Question 23

• A. raw_df.createOrReplaceTempView(“raw_df”)

Explanation:

The method createOrReplaceTempView creates (or replaces if that view name already exists) a lazily evaluated “view” that can be used like a table in Spark SQL. It does not persist to memory and is only available in this Spark session. This makes it ideal for temporary data sharing or examination. The other options don’t create a temporary view or are not valid methods for a DataFrame. Option E is incorrect as Spark SQL and PySpark can share data through views or tables.

Question 24

• D. f”{region}{store}sales{year}”

Explanation:

In Python, f-strings are a method of string interpolation. They allow expressions to be embedded inside string literals, using curly braces {}. The expressions will be replaced with their values when the string is created. The f-string syntax f”{region}{store}sales{year}” will replace {region}, {store}, and {year} with the values of those variables, resulting in a string like nyc100_sales_2021. The other options will not correctly format the string. For instance, option A, C and E will not replace the variables with their values, and option B will include unnecessary ‘+’ characters in the output string.

Question 25

• A. The .read line should be replaced with .readStream

Explanation:

Spark offers two kinds of data processing operations: batch and streaming. The .read operation is used for batch processing, where data is read from a static source. The .readStream operation, on the other hand, is used for real-time processing, where data is continuously read from a streaming source.

Therefore, if a data engineer wants to perform a streaming read from a data source, they should use the .readStream operation instead of the .read operation. The corrected code block would look like this:

(spark
.readStream
.schema(schema)
.format("cloudFiles")
.option("cloudFiles.format", "json")
.load(dataSource)
)

This correction should resolve the error, and the data engineer will be able to perform a streaming read from the data source successfully.

Question 26

• A. trigger(once=True)

Explanation:

Structured Streaming in Spark provides a high-level API for stream processing. To specify how often the streaming computation should be run, we use the trigger setting.

If we want the query to execute only a single batch of data, we can use trigger(once=True). This will process all available data as a single batch and then terminate the operation. This is known as a one-time trigger.

(spark.table("sales")
.withColumn("avg_price", col("sales") / col("units"))
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("complete")
.trigger(once=True)
.table("new_sales")
)

Question 27

• E. Auto Loader

The data engineer can use Auto Loader to solve this problem. Auto Loader, a feature available in Databricks, is designed to simplify the process of incrementally ingesting data, such as new files in a directory. Auto Loader keeps track of new files as they arrive, and it automatically processes these files. It’s a robust and low-maintenance option for ingesting incrementally updated or new data.

Please note, while Delta Lake (B) is a technology that can provide features like ACID transactions, versioning, and schema enforcement on data lakes, it doesn’t directly address the problem of identifying and processing only new files since the last pipeline run. Similarly, Databricks SQL (A), Unity Catalog (C), and Data Explorer (D) are not directly targeted at this specific problem.

Question 28

• C. There is no change required. The inclusion of format("cloudFiles") enables the use of Auto Loader.

In Databricks, the Auto Loader feature is utilized through the “cloudFiles” format option. So, the given code block is already configured to use Auto Loader. Therefore, no changes are needed in the code.

Other Options Explanation:

• A. The data engineer needs to change the format("cloudFiles") line to format("autoLoader"): This is incorrect because Auto Loader is invoked using the “cloudFiles” format, not “autoLoader”.

• B. There is no change required. Databricks automatically uses Auto Loader for streaming reads: This is incorrect. Auto Loader needs to be explicitly invoked in the readStream command using the “cloudFiles” format.

• D. The data engineer needs to add the .autoLoader line before the .load(sourcePath) line: This is incorrect as there is no .autoLoader option available. The Auto Loader is enabled using the format("cloudFiles") command.

• E. There is no change required. The data engineer needs to ask their administrator to turn on Auto Loader: This is incorrect. The Auto Loader can be enabled directly in the code by the data engineer without needing any administrative privileges.

Question 29

• E. A job that enriches data by parsing its timestamps into a human-readable format.

Explanation:

Bronze tables in Databricks’ Lakehouse pattern are used for storing raw, unprocessed data. However, the process of converting timestamps into a more human-readable format is a form of data enrichment, which typically happens at this “Bronze” level. The enriched data is then stored in Silver tables for further processing or analysis.

Other Options Explanation:

• A. A job that aggregates cleaned data to create standard summary statistics: This would likely utilize a Silver or Gold table, which contain processed and cleaned data ready for analysis.

• B. A job that queries aggregated data to publish key insights into a dashboard: This would likely involve a Gold table, which contains data that has been cleaned, processed, and possibly aggregated, and is used for reporting and analytics.

• C. A job that ingests raw data from a streaming source into the Lakehouse: This is a correct statement, however, it does not pertain to the task of parsing timestamps which the question focuses on.

• D. A job that develops a feature set for a machine learning application: Depending on the specifics, this could potentially involve any stage of data, but typically this would be either Silver or Gold data, which has been cleaned and processed.

Question 30

D. A job that aggregates cleaned data to create standard summary statistics

Explanation:

In the Databricks Lakehouse paradigm, a Silver table is typically used to store clean and processed data that can be used for various types of transformations, including the calculation of aggregated statistics. Therefore, a job that aggregates cleaned data to create standard summary statistics would utilize a Silver table as its source.

Other Options Explanation:

A. A job that enriches data by parsing its timestamps into a human-readable format: This operation could be performed at either the Bronze or Silver level, depending on the specific requirements of the pipeline. However, as it’s a form of data cleaning or enrichment, it’s more likely to be performed at the Bronze level.

B. A job that queries aggregated data that already feeds into a dashboard: This type of operation typically involves Gold tables, which are used for high-level reporting and analytics.

C. A job that ingests raw data from a streaming source into the Lakehouse: This operation would involve a Bronze table, which is used for the initial ingestion of raw data.

E. A job that cleans data by removing malformatted records: While this could potentially occur at the Silver level, the initial round of data cleaning often happens at the Bronze level before the data is loaded into a Silver table.

Question 31

C.

(spark.table("sales")
.withColumn("avgPrice", col("sales") / col("units"))
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("append")
.table("cleanedSales")
)

Explanation:

The Bronze-Silver-Gold architecture in data management is a tiered framework for data processing and storage. Bronze represents raw, unprocessed data, Silver represents cleansed and enriched data, while Gold represents aggregated and business-ready data.

The statement under option C takes a stream of data from the “sales” Bronze table, enriches it by calculating the “avgPrice”, and writes it to the “cleanedSales” table, effectively transforming it to a Silver table. The transition from raw data to enriched data is generally considered a transition from a Bronze to a Silver table, which is why this option is the correct answer.

Question 32

• A. The ability to declare and maintain data table dependencies

Explanation:

Delta Live Tables offers several advantages over standard data pipelines that use Spark and Delta Lake on Databricks. One such advantage is the ability to declare and maintain dependencies between tables. This is useful when the output of one table is used as the input to another. It makes the pipeline more maintainable and resilient to changes.

Option B, the ability to write pipelines in Python and/or SQL, is not unique to Delta Live Tables. You can also write Spark and Delta Lake pipelines in these languages.

Option C, accessing previous versions of data tables, is a feature of Delta Lake (through Delta Time Travel), not specific to Delta Live Tables.

Option D, the ability to automatically scale compute resources, is a feature of Databricks, not specific to Delta Live Tables.

Option E, performing batch and streaming queries, is possible with both Spark Structured Streaming and Delta Lake, not specific to Delta Live Tables.

Question 33

• B. They need to create a Delta Live Tables pipeline from the Jobs page.

Explanation:

Here are the steps on how to create a Delta Live Tables pipeline from the Jobs page in Databricks:

1. Go to the Jobs page in Databricks.

2. Click on the “Create Job” button.

3. Select “Delta Live Tables” as the job type.

4. Select the notebooks that you want to include in the pipeline.

5. Specify the order in which you want the notebooks to be executed.

6. Click on the “Create” button.

Question 34

• B. They need to add a CREATE LIVE TABLE table_name AS line at the beginning of the query.

Explanation:

Delta Live Tables (DLT) supports SQL and Python syntax. To define a table in SQL, one has to use the CREATE LIVE TABLE statement before defining the query. Hence, to convert the query into a DLT compatible query, we would add the CREATE LIVE TABLE command at the beginning.

It’s worth mentioning that as of my knowledge cutoff in September 2021, this is the correct information. Always refer to the most recent Databricks documentation for the most up-to-date processes and procedures.

Question 35

• A. Records that violate the expectation are added to the target dataset and recorded as invalid in the event log.

Explanation:

The CONSTRAINT clause in Delta Live Tables sets an expectation on the dataset. If the action to be taken upon violation of the expectation is not explicitly specified, the default action, which is ‘warn’, is applied. With the ‘warn’ action, the records that do not meet the expectation are written to the target dataset, and a failure metric for the dataset is recorded in the event log.

Question 36

• A. Records that violate the expectation are added to the target dataset and recorded as invalid in the event log.

Explanation:

In Continuous Pipeline Mode with Production mode enabled, all tables in the pipeline are updated continuously until the pipeline is manually stopped. When ‘Start’ is clicked, the pipeline initiates and continues to run, processing incoming data in real-time. Compute resources are allocated for the entire duration of the pipeline execution, thus ensuring optimal performance.

Question 37

• D. They can institute a retry policy for the task that periodically fails

Explanation:

A retry policy can be instituted at the task level in Databricks. This would allow the specific task that is failing to be retried without having to rerun the entire job, thus minimizing compute costs. The other options, such as retrying the entire job or setting the job to run multiple times, would increase compute costs as more tasks would be run than necessary. Observing the task as it runs might help determine why it is failing, but it won’t ensure the job completes each night. Finally, utilizing a jobs cluster for each of the tasks in the job would not necessarily address the issue of the task failing and could lead to increased compute costs.

Question 38

• A. They can utilize multiple tasks in a single job with a linear dependency

Explanation:

The most reliable solution to this problem would be to set up multiple tasks within a single job with a linear dependency. This approach ensures that the second task (which was previously the second job) will not start until the first task (previously the first job) has successfully completed. This removes the problem of the second job starting before the first has completed. The other options, like using cluster pools, setting a retry policy on the first job, or limiting the size of the output in the second job, do not directly address the issue of the second job starting before the first job has finished. The option to set up the data to stream from the first job to the second job is not a typical way to ensure job dependencies in Databricks.

Question 39

• C. They can download the JSON description of the Job from the Job’s page.

Explanation:

Databricks provides the option to download a JSON description of the job configuration from the job’s page. This JSON description can be version controlled, and can also be used to recreate the job programmatically using the Databricks Jobs API. This provides a way to have version-controllable configuration of the Job’s schedule. Other options like linking the job to notebooks that are a part of a Databricks Repo, submitting the job on a job cluster or all-purpose cluster, or downloading an XML description of the job do not offer the same level of version control for a job’s schedule.

Question 40

• C. They can increase the cluster size of the SQL endpoint.

Explanation:

Databricks SQL Endpoint is the compute that is used to execute SQL queries in Databricks. The performance of the SQL queries can be directly improved by increasing the size of the underlying cluster used by the SQL endpoint. The cluster size in Databricks is defined by the number and type of machines (known as nodes) in the cluster. A larger cluster can handle more data and perform operations faster because the computations are distributed among more machines. Therefore, by increasing the cluster size of the SQL endpoint, the data engineering team can improve the performance of the data analyst’s queries. Other options mentioned might not have a direct impact on the performance of the SQL queries.

Question 41

• B. They can schedule the query to refresh every 1 day from the query’s page in Databricks SQL.

Explanation:

In Databricks SQL, users have the ability to schedule their SQL queries to run at specific intervals. This can be very useful for scenarios where the results of the query need to be updated periodically. In this case, the engineering manager can schedule the query to refresh every 1 day directly from the query’s page in Databricks SQL. This will ensure that the query is executed automatically every day, updating the results without requiring the manager to manually rerun the query each time. Other options such as scheduling from the Jobs UI or from the SQL endpoint’s page may not be applicable as they pertain to different Databricks features.

Question 42

• D. They can set up an Alert for the query to notify them if the returned value is greater than 60.

Explanation:

Databricks SQL allows you to create Alerts on specific queries. In this scenario, the data engineering team can create an Alert on the query that monitors the ELT job runtime. The Alert can be set to trigger a notification when the query result (the number of minutes since the job’s most recent runtime) exceeds 60. This way, the team will be notified if the ELT job has not run in over an hour. Other options such as alerting on dashboard conditions or job failures may not provide the specific information needed in this case.

Question 43

• D. The Job associated with updating the dashboard might be using a non-pooled endpoint.

Explanation:

Databricks SQL dashboards do not directly depend on Jobs. Rather, they execute SQL queries on SQL Endpoints (either serverless or a cluster-backed endpoint). Therefore, the speed at which a dashboard refreshes is independent of whether the Jobs are using pooled or non-pooled endpoints. The other options, such as the SQL endpoint needing time to start up, the inherent complexity of the queries, or the queries checking for new data before executing, could indeed contribute to the delay in updating the dashboard. The fifth option, E, is incorrect because individual queries in a dashboard do not connect to their own, separate Databricks clusters.

Question 44

• C. GRANT SELECT ON TABLE sales TO new.engineer@company.com;

Explanation:

The GRANT SELECT command is used to give a user permission to read a database table. Therefore, the command GRANT SELECT ON TABLE sales TO new.engineer@company.com; would grant the new data engineer the permissions needed to query the ‘sales’ table. The USAGE privilege doesn’t allow data access, it only allows the user to access objects in the database. CREATE privilege would allow the user to create objects in the database, but not necessarily read data from existing tables. Options D and E are incorrectly formulated, as they try to grant privileges on a table named “new.engineer@company.com” to a user or role called ‘sales’.

Question 45

• A. GRANT ALL PRIVILEGES ON TABLE sales TO new.engineer@company.com;

Explanation:

The GRANT ALL PRIVILEGES command is used to give a user full permissions to an object, such as a table. In this case, the command GRANT ALL PRIVILEGES ON TABLE sales TO new.engineer@company.com; would grant the new data engineer all necessary permissions to fully manage the ‘sales’ table. The other options either grant insufficient privileges (e.g., USAGE or SELECT only) or are not correctly formatted SQL commands.