Free Snowflake DAA-C01 Practice Exam with Questions & Answers

To correctly predict the output of this query, a Data Analyst must understand how Snowflake handles semi-structured data (JSON), specifically regarding path notation, data type casting, and the display of VARIANT values in the Snowsight UI.

1. Variant vs. Casted Types (Display): When you access a value within a JSON object using colon notation (e.g., json_col:employee.phone[0]), the resulting value is of the VARIANT data type. In the Snowflake Snowsight results pane, VARIANT strings are displayed with double quotes (e.g., "+1 223-256-7330"). However, when you explicitly cast a variant to a string type using the double-colon syntax (e.g., ::varchar), Snowflake extracts the value as a native SQL string, which is displayed without quotes (e.g., +1 028-735-4521).

2. Handling Empty Strings vs. Out-of-Bounds: In the provided JSON exhibit, the phone array contains four elements at indices 0, 1, 2, and 3. The elements at indices 2 and 3 are empty strings (""). When these are queried, Snowflake returns the empty string variant, which appears as "" in the result set. The query also attempts to access phone[4]. Since the array only has four elements (max index 3), index 4 is out-of-bounds. In Snowflake, accessing a non-existent index in an array or a non-existent key in an object returns NULL.

Evaluating the Options based on the exhibit:

Option B correctly reflects all these behaviors: WORK_PHONE is in quotes (Variant), OFFICE_PHONE1 is not in quotes (Casted), OFFICE_PHONE2 and OFFICE_PHONE3 show the empty strings present in the JSON, and OFFICE_PHONE4 correctly shows null for the out-of-bounds access.

Option A is incorrect because it misses the quotes for the variant column and shows the out-of-bounds index as an empty string instead of null.

Option C is incorrect because it fails to account for the empty strings present at indices 2 and 3.

Option D incorrectly mixes the casting logic and display.

This question tests the "Schema-on-Read" proficiency required of a SnowPro Advanced: Data Analyst, specifically the ability to predict exactly how transformed semi-structured data will materialize for end-users.

In the Snowflake ecosystem, Parquet is treated as a semi-structured data format. When you stage a Parquet file, Snowflake does not automatically parse it into multiple columns like it might with a flat CSV file. Instead, the entire content of a single row or record is loaded into a single VARIANT column, which is referenced in SQL using the positional notation $1.

The fundamental mistake often made—and represented in Option A—is treating Parquet as a delimited format where $1, $2, and $3 refer to different columns. In Parquet ingestion, columns $2 and beyond will return NULL because the schema is contained within the object in $1.

To successfully "shred" or flatten this semi-structured data into a relational table with separate columns, an analyst must use path notation. This involves referencing the root object ($1), followed by a colon (:), and then the specific element key (e.g., $1:o_custkey). Furthermore, because the values extracted from a Variant are technically still Variants, they must be explicitly cast to the correct data type using the double-colon syntax (e.g., ::number, ::date) to ensure they land in the target table with the correct data types.

Evaluating the Options:

Option A is incorrect because it uses positional references ($2, $3, etc.) which are only valid for structured files like CSVs.

Option B is incorrect because it attempts to reference keys directly without the required stage variable ($1) and colon separator.

Option D is incorrect as it uses a non-standard parse() function that does not exist for this purpose in Snowflake SQL.

Option C is the 100% correct syntax. It correctly identifies that the Parquet data resides in $1, utilizes the colon to access internal keys, and applies the necessary type casting. This specific method is known as "Transformation During Ingestion" and is a core competency for any SnowPro Advanced Data Analyst.

While Snowflake provides various ways to encapsulate logic, Stored Procedures are the primary tool for procedural programming and dynamic SQL execution. Unlike standard UDFs, which are generally designed to calculate and return values within a query, stored procedures can execute administrative commands (DDL) and data manipulation (DML) that are not possible in a simple SELECT statement.

Using Snowflake Scripting (or languages like Python, Java, or JavaScript), an analyst can write a procedure that builds a SQL string as a variable and then executes it using the EXECUTE IMMEDIATE command. This is demonstrated in procedural logic flows where inputs determine specific execution paths. While Tasks can be used to schedule the execution of these procedures, the task itself is a scheduling agent and does not provide the logic-driven dynamic string construction inherent to the procedure.

To determine the correct output, a Data Analyst must understand the behavior of the STRTOK_SPLIT_TO_TABLE table function and how it interacts with different delimiters.

1. Functionality of STRTOK_SPLIT_TO_TABLE:

The STRTOK_SPLIT_TO_TABLE function tokenizes a string based on a set of specified delimiters. Unlike simple SPLIT functions that often look for a literal string as a delimiter, STRTOK treats the delimiter string as a set of individual characters. Any character present in the delimiter string will trigger a split. Crucially, it skips empty tokens—if multiple delimiters appear consecutively, it does not produce a row for the space between them.

2. Evaluating the Data and Delimiters ('*-'):

'JOHN*DOE': The * character is a delimiter. This results in two tokens: JOHN and DOE.

'ALICE-SMITH': The - character is a delimiter. This results in two tokens: ALICE and SMITH.

'BOB*-JOHNSON': Both * and - are delimiters. Because they appear consecutively (*-), the function splits at each but ignores the empty space between them. This results in two tokens: BOB and JOHNSON.

3. Analyzing the Resulting Rows:

The LATERAL join produces a row for every token generated. The columns SEQ (identifying the source row sequence) and INDEX (position of the token within that sequence) are used for sorting.

Student 1: 2 tokens (JOHN, DOE) $\rightarrow$ 2 rows.

Student 2: 2 tokens (ALICE, SMITH) $\rightarrow$ 2 rows.

Student 3: 2 tokens (BOB, JOHNSON) $\rightarrow$ 2 rows.

Evaluating the Options (image_8233d8.png):

Option A incorrectly only shows results for Student 3.

Option C incorrectly implies Student 1 and 2 produce three tokens each.

Option D incorrectly interprets the consecutive delimiters in Student 3's name as creating a different sequence count.

Option B is the 100% correct result set. It accurately shows that each student’s name is split into exactly two parts, properly handling the varying delimiters and the consecutive characters in the third record.

In Data Analysis, correlation refers to a statistical relationship between two variables. When analyzing a time-series chart like the one provided, a Data Analyst looks for patterns in how the two categories—"Enterprise" (blue line) and "Pro Edition" (yellow line)—move in relation to one another over the X-axis (Year).

A Positive Correlation would be indicated if both lines generally moved in the same direction at the same time (e.g., when Enterprise sales increase, Pro Edition sales also increase). A Negative Correlation (or inverse correlation) would be shown if the lines moved in opposite directions consistently (e.g., when one peaks, the other troughs).

Looking closely at the provided exhibit, the fluctuations for both editions are highly erratic and appear independent of each other. For instance, around the year 2008, the Pro Edition (yellow) shows a significant peak while the Enterprise edition (blue) experiences a sharp decline. Conversely, in other sections of the chart, they both dip or rise simultaneously by chance, but there is no sustained, predictable pattern of movement. The peaks and valleys do not align in a way that suggests one variable's movement is tied to the other.

Statistically, this lack of a discernible relationship indicates a Correlation Coefficient near zero. In the context of the Snowflake Snowpro Advanced: Data Analyst exam, identifying "No Correlation" is a key skill for interpreting Snowsight visualizations. It tells the analyst that the factors driving sales for the Enterprise tier are likely distinct from those driving the Pro Edition, and they should be analyzed as independent segments rather than interdependent variables. Therefore, based on the visual evidence of random, non-synchronous movement across the timeline, the only supported conclusion is that there is no correlation.

Understanding how Snowflake aggregate functions like MIN() and MAX() handle numerical data and NULL values is fundamental for accurate Data Analysis. In this scenario, we have a table with five records distributed across two departments.

The MIN() function returns the smallest non-null value in the specified column across all rows in the group (or the entire table, if no GROUP BY is present). Looking at the salary column in the employees table, the values are: 10000, 9000, 8000, 15000, and NULL. The NULL value is ignored by the calculation. Among the remaining numerical values, 8000 is the smallest. Therefore, MIN_VAL will be 8000.

The MAX() function operates similarly, returning the largest non-null value from the set. Comparing the same list of numerical values—10000, 9000, 8000, and 15000—the largest value is clearly 15000. Consequently, MAX_VAL will be 15000.

Evaluating the Options based on the exhibit (image_8ca0df.png):

Option A incorrectly identifies the minimum and maximum based on the employee_id column (where 2000 is max and 900 is min), rather than the requested salary column.

Option B is incorrect as it seems to mix values from different columns or specific rows.

Option C is incorrect because it mistakenly suggests that MIN() returns NULL if a NULL value is present in the column. In Snowflake, standard aggregate functions (except for specialized ones like ARRAY_AGG or certain window functions with specific clauses) skip NULL values entirely.

Option D is the 100% correct output. It displays MIN_VAL as 8000 and MAX_VAL as 15000, which accurately reflects the mathematical minimum and maximum of the non-null entries in the salary column.

This behavior is consistent across all relational databases adhering to ANSI SQL standards, which Snowflake follows for these core aggregate operations.

When working with very large tables, calculating the exact number of unique combinations of columns (cardinality) using COUNT(DISTINCT ...) is a resource-intensive operation. It requires the Snowflake query engine to keep an exhaustive list of every unique pair encountered in memory, which can lead to high credit consumption and performance bottlenecks.

To provide a "very quick estimate," Snowflake utilizes the HyperLogLog (HLL) algorithm. The function HLL(column1, column2, ...) returns an HLL state (a binary representation) that can be used to estimate the number of distinct values with a high degree of accuracy and minimal computational overhead. This is part of Snowflake's suite of approximate aggregation functions, which are essential for Data Analysis on massive datasets where a 1% margin of error is acceptable in exchange for significantly faster results.

Evaluating the Options:

Option A is syntactically incorrect; DISTINCT cannot be used in that position with COUNT.

Option C is a valid query but will be significantly slower and more expensive than an HLL estimate on a "very large table".

Option D simply counts the total number of non-null rows, which does not represent the "number of different values" (cardinality).

Option B is the 100% correct answer. It specifically addresses the requirement for a "quick estimate" using the industry-standard probabilistic counting method built into Snowflake.

One of the most powerful features of the Snowsight interface for a Data Analyst is the automatic data profiling provided in the results pane. Snowflake automatically calculates statistics and visual distributions for the result set of any query executed in a worksheet, provided the result set is not excessively large.

When the Analyst views the query results, they can simply click on the column header for the "total amount" column. This action opens a summary pane that displays key descriptive statistics such as the mean, sum, and a histogram showing the frequency distribution of the values in that specific column. This allows for immediate visual analysis of data skew, outliers, or common ranges without requiring the analyst to write additional SQL or move the data to an external visualization tool.

Evaluating the Options:

Option A is the Correct answer. This is the fastest, built-in way to perform "exploratory data analysis" (EDA) on a result set within the UI.

Option B and C are incorrect because while Snowsight does have a "Chart" tab, creating a chart requires manual configuration and is a separate step from the automatic profiling features found in the column headers.

Option D is incorrect because calling the WIDTH_BUCKET function would require the Analyst to run the query again with modified SQL logic, which explicitly contradicts the requirements of the question.

This feature significantly enhances the Data Analysis workflow by providing "at-a-glance" insights into data quality and distribution directly within the development environment.

To automate a data pipeline in Snowflake using Tasks and Streams, an analyst must understand the relationship between scheduling and conditional execution. A task is an object used to execute a single SQL statement (or a call to a stored procedure) on a recurring basis. A stream, on the other hand, tracks Change Data Capture (CDC) metadata for a table, indicating whether new rows have been added, updated, or deleted.

The core requirement of this question is to ensure the task runs automatically but only if there is new data. In Snowflake, a task requires a SCHEDULE parameter to run automatically without manual intervention. The SCHEDULE defines the frequency (e.g., '5 MINUTE' or a CRON expression) at which the task "attempts" to run. However, to prevent wasting credits by running the task when no data has changed, the WHEN clause is used in conjunction with the system function SYSTEM$STREAM_HAS_DATA('stream_name').

Evaluating the Options based on the exhibit (image_8c9a13.png):

Option A is incorrect because it lacks a SCHEDULE. Without a schedule, the task is considered "standalone" and will never execute unless manually triggered by an EXECUTE TASK command.

Option B is incorrect because it incorrectly attempts to place the SYSTEM$STREAM_HAS_DATA function within the SCHEDULE parameter. The schedule must be a time-based interval or a cron string.

Option C is incorrect because 'STREAM' is not a valid schedule interval.

Option D is the 100% correct answer. It provides a valid time-based SCHEDULE ('2 minute') which enables the task to heart-beat automatically. It then correctly utilizes the WHEN clause with SYSTEM$STREAM_HAS_DATA('MYSTREAM'). This configuration ensures that every two minutes, Snowflake checks the stream; if the stream contains data, the task executes the SQL; if the stream is empty, the task skips the execution, saving compute resources. This pattern is the industry standard for building efficient, automated Data Transformation pipelines in the Snowflake Data Cloud.

This scenario requires a specific combination of Snowflake's extensibility features: the ability to run Python (pandas) code, the ability to return multiple rows for a single input (tabular output), and high performance through vectorization.

A User-Defined Table Function (UDTF) is the correct architectural choice when an input value needs to be expanded into a set of rows. While a standard UDF returns exactly one value per input row, a UDTF can return zero, one, or many rows, making it ideal for "parsing" or "splitting" tasks. By using a Vectorized UDTF (specifically utilizing the Python handler with pandas), the Analyst can process blocks of rows as pandas DataFrames or Series. This is significantly more efficient than processing one row at a time because it reduces the overhead of the Snowflake-to-Python execution engine.

Evaluating the Options:

Option A is incorrect because a standard UDF can only return a single scalar value per input row, making it impossible to "return multiple rows of parsed output."

Option C is incorrect because External Functions are used to call code hosted outside of Snowflake (like an AWS Lambda). While they can process data, they introduce network latency and are not the native way to run pandas code for internal joins.

Option D is incorrect because Stored Procedures are generally used for administrative tasks and procedural logic. While they can return tables, they cannot be directly "joined" with other tables in a standard SELECT statement in the same way a UDTF can.

Option B is the correct choice. It satisfies the requirement for pandas integration, provides the necessary multi-row output via the process and end_partition methods, and allows the analyst to use the LATERAL keyword to join the parsed results directly with existing tables in a single SQL statement.