SnowflakeExpert levelDAA-C01Page 3 of 3

DAA-C01 exam dumps: questions 201 to 267 of 267

Page 3 of the free DAA-C01 question bank for the SnowPro® Advanced: Data Analyst exam. Questions 201 to 267 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated April 2026

Start timed practice exam Questions 201 to 267

Free DAA-C01 practice questions

Questions 201 to 205 of 267

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

DAA-C01 Question 201

Single answerSummarize large data sets using Snowsight dashboards

A retail analytics team uses Snowsight dashboards to monitor daily sales across hundreds of millions of transaction rows. Business users complain that a dashboard tile showing sales by region and product category is slow to load and is difficult to interpret because it returns too many detailed rows. The analyst wants to redesign the tile so executives can quickly review trends while minimizing the amount of data processed for the visualization. Which approach should the analyst take?

A
Create a query for the dashboard tile that aggregates sales with GROUP BY region, product category, and day, returning only summarized measures needed for the chart.
B
Replace the chart with a table visualization that shows every transaction row so Snowsight can summarize the data interactively in the dashboard.
C
Use SELECT * in the tile query and rely on Snowsight filters to reduce the data after the full result set is returned.
D
Export the transaction data to a CSV file, re-import a smaller sample into Snowflake, and build the dashboard from the sample instead.

Show answer and explanation

Correct answer: A

Explanation

When building Snowsight dashboards for large data volumes, analysts should design SQL queries that return summarized, business-ready data instead of raw detail. Aggregating measures with GROUP BY and selecting only the required columns improves query efficiency and creates visualizations that are easier to understand. This is especially important for executive dashboards, where the goal is rapid interpretation of trends rather than row-level exploration. Snowflake and Snowsight best practices favor pushing summarization into SQL so the dashboard tile works with a smaller, more meaningful result set. This reduces unnecessary processing and rendering overhead while preserving accuracy and freshness from the underlying Snowflake data.

A. Correct.
Correct. For large data sets, the best practice is to summarize data in the SQL query before it reaches the visualization. Using GROUP BY with only the dimensions and measures needed for the dashboard reduces the result set size, improves performance, and makes the chart easier for executives to interpret. This aligns with how Snowsight dashboards are typically built: tiles are backed by SQL queries, and well-designed queries should return aggregated results appropriate for the business question.
B. Incorrect.
Incorrect. Returning every transaction row increases the amount of data that must be scanned, transferred to the result set, and rendered in the dashboard. A table of raw rows is usually less useful for executive summary reporting and does not address the performance concern. The misconception is assuming the visualization layer should perform the summarization rather than the SQL query.
C. Incorrect.
Incorrect. SELECT * is a poor choice for dashboard queries against large data sets because it retrieves unnecessary columns and detailed records. Applying filters after returning a large result set does not optimize the initial query appropriately for a summary dashboard. The misunderstanding here is confusing interactive filtering with efficient query design.
D. Incorrect.
Incorrect. Sampling and rebuilding the dashboard from imported CSV data creates data freshness and governance problems and is not an appropriate solution when Snowflake can query and aggregate the source data directly. Executives typically need accurate, current summaries, not a static sample. This distractor reflects an unnecessary workaround rather than a Snowflake analytics best practice.

DAA-C01 Question 202

Single answerSummarize large data sets using Snowsight dashboards

A retail analytics team uses Snowsight dashboards to monitor daily sales across several billion rows in a FACT_SALES table. Business users want an executive dashboard that opens quickly and shows high-level KPIs by day, region, and product category, with the ability to filter interactively in Snowsight. The current dashboard is built directly on detailed transaction-level queries and is too slow during peak usage. Which approach would BEST improve dashboard performance while still meeting the requirement to summarize large data sets for interactive analysis?

A
Create a pre-aggregated summary table or dynamic table at the day, region, and product-category level, and build the Snowsight dashboard from that summarized dataset.
B
Keep the dashboard on the detailed FACT_SALES table, but increase the warehouse size for all dashboard users so every filter interaction scans the full transaction history faster.
C
Export the daily results to an external BI tool because Snowsight dashboards are intended only for small sample datasets rather than large summarized datasets.
D
Replace the dashboard with a worksheet that queries the raw FACT_SALES table so users can manually run SQL each time they need updated KPIs.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to build the dashboard on a summarized dataset at the grain actually needed for the business questions. In Snowsight, dashboards are created from queries and visualizations, so dashboard performance depends heavily on the efficiency of those underlying queries. When the source is a very large fact table, querying raw transactional data for high-level KPI dashboards is usually unnecessary and expensive. Pre-aggregating data into a summary table or using a dynamic table can significantly reduce the amount of data scanned and improve user experience for interactive filters.

This aligns with Snowflake analytic design best practices: model data according to the access pattern, avoid repeatedly scanning detailed history for summary reporting, and use appropriately curated datasets for dashboards. Warehouse scaling can help with compute-intensive queries, but it should not be the primary fix for a dashboard whose logic can be materially simplified through aggregation. Snowsight dashboards are suitable for enterprise reporting scenarios when built on efficient queries and summarized datasets.

A. Correct.
Correct. For dashboards that summarize very large datasets, the most effective pattern is to reduce the volume of data queried at runtime by pre-aggregating to the grain required for the dashboard. In this scenario, users only need KPIs by day, region, and product category with interactive filtering. A summary table or dynamic table at that grain allows Snowsight visualizations and dashboard tiles to query far fewer rows, improving responsiveness while still supporting the required filters. This matches common Snowflake performance best practices: transform and aggregate data to fit the analytic use case instead of repeatedly scanning transaction-level detail for executive reporting.
B. Incorrect.
Incorrect. Increasing warehouse size can reduce query runtime, but it does not address the fundamental inefficiency of repeatedly scanning billions of detailed rows for a dashboard that only needs summarized metrics. This is a common misconception: more compute can help, but it is often a costly workaround rather than the best design. For dashboard workloads, especially with repeated interactive filtering, pre-aggregation is typically more efficient and scalable than relying solely on larger virtual warehouses.
C. Incorrect.
Incorrect. Snowsight dashboards can be used with large enterprise datasets as long as the underlying queries and models are designed appropriately. The limitation here is not that Snowsight cannot handle large summarized datasets; the problem is that the dashboard is querying transaction-level detail unnecessarily. Moving to an external BI tool does not inherently solve poor data modeling or query design.
D. Incorrect.
Incorrect. Replacing the dashboard with a worksheet removes the self-service dashboard experience and does not solve the performance issue. Worksheets are useful for ad hoc analysis, but executives needing fast KPI monitoring and interactive filtering are better served by a dashboard backed by a dataset modeled for summary analysis. Querying the raw FACT_SALES table manually would likely be slower and less usable.

DAA-C01 Question 203

Single answerCreate a reusable filter

A retail analytics team uses Snowsight dashboards to monitor daily sales. Several worksheets and dashboard tiles need to be filtered repeatedly to show only the current user's assigned region. The lead analyst wants a solution that can be defined once and reused across analyses, while still allowing other analysts to apply the same logic without rewriting the predicate each time. Which approach best meets this requirement?

A
Create a view that hard-codes one region in the WHERE clause, and have all analysts query that view
B
Create a reusable custom filter in Snowsight based on the region column and save it for repeated use across analyses
C
Ask each analyst to add a worksheet-level filter manually whenever they open a new analysis
D
Create a temporary table containing only one region's rows and point each dashboard tile to that table

Show answer and explanation

Correct answer: B

Explanation

The best answer is to create and save a reusable custom filter in Snowsight. Reusable filters are intended to support common, repeated filtering conditions so analysts do not have to redefine the same predicates across worksheets and dashboards. This aligns with analytics best practices: centralize repeated business logic where the tool supports it, reduce manual repetition, and improve consistency across visualizations. The other options either hard-code the logic in a way that reduces flexibility, rely on repetitive manual steps, or misuse physical data structures for an interactive analysis problem. In Snowflake documentation and Snowsight best practices, saved or reusable analytical components are preferred when the same filter logic needs to be applied consistently across multiple analyses.

A. Incorrect.
Incorrect. A view with a hard-coded region is not flexible or reusable for multiple users with different assigned regions. It also requires changing the view definition or creating multiple views for different regions. While views are reusable database objects, this approach does not address reusable filtering logic in an analyst-friendly way within Snowsight.
B. Correct.
Correct. A reusable custom filter in Snowsight is designed for this use case: define filter logic once and apply it repeatedly across analyses. This reduces duplication, improves consistency, and supports repeated analyst workflows without manually rebuilding the same filter each time.
C. Incorrect.
Incorrect. Manually adding worksheet-level filters works functionally, but it does not create a reusable filter. It increases the chance of inconsistency and user error, especially when multiple worksheets and dashboard components must use the same logic.
D. Incorrect.
Incorrect. A temporary table is session-scoped and not a practical reusable filtering mechanism for dashboards or shared analysis. It also duplicates data unnecessarily and creates maintenance overhead. Temporary tables are for transient data processing, not for reusable interactive filtering.

DAA-C01 Question 204

Single answerCreate a reusable filter

A Snowflake analyst builds a Snowsight worksheet used by multiple business users to review quarterly sales performance. The users repeatedly need to limit results to the same set of conditions: REGION = 'EMEA', SALES_CHANNEL IN ('ONLINE','PARTNER'), and ORDER_DATE within the current quarter. The analyst wants a solution that lets these conditions be defined once and then applied consistently across future queries in the worksheet without retyping the predicate each time. Which approach best meets this requirement?

A
Create a reusable filter in Snowsight with the required conditions, then apply that saved filter to subsequent worksheet queries as needed.
B
Create a masking policy on REGION, SALES_CHANNEL, and ORDER_DATE so that all worksheet queries automatically return only rows matching those values.
C
Define a session variable containing the full WHERE clause text and reference the variable directly in every SQL statement without dynamic SQL.
D
Create a new warehouse dedicated to EMEA sales analysis so users can run the same filter logic more efficiently.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to create a reusable filter in Snowsight. In worksheet-driven analysis, reusable filters are designed to help analysts save commonly used filter logic and apply it consistently across future work, which is especially helpful for recurring business slices such as region, channel, and date range. This is more maintainable and less error-prone than repeatedly rewriting WHERE clauses. By contrast, masking policies address data privacy, warehouses address compute, and session variables are not an ideal mechanism for reusable worksheet filter predicates. This aligns with Snowsight best practices for interactive analysis and reuse of common filtering criteria.

A. Correct.
Correct. A reusable filter in Snowsight is intended for exactly this use case: defining filter criteria once and reapplying them across worksheet queries or result explorations. This improves consistency, reduces repeated manual edits, and lowers the chance of users applying slightly different predicates when analyzing the same business slice.
B. Incorrect.
Incorrect. Masking policies are data protection features used to redact or transform sensitive column values at query time based on policy logic and role context. They do not function as analyst-defined reusable row filters for ad hoc analysis. Someone might choose this option because it sounds like a centrally managed way to constrain output, but masking policies are not the right feature for reusable business filtering.
C. Incorrect.
Incorrect. Session variables can store scalar values, but they are not a straightforward mechanism for storing and directly injecting an entire WHERE clause into ordinary SQL statements. Reusing a full predicate this way would typically require dynamic SQL or procedural logic, making it less suitable and less user-friendly for worksheet-based analysis. This option reflects a common misconception that variables can be substituted anywhere in SQL syntax as text fragments.
D. Incorrect.
Incorrect. Warehouses provide compute resources and affect performance and concurrency, not logical filtering behavior. Creating a dedicated warehouse does nothing to define or enforce reusable row-level conditions. This distractor targets the misconception that compute configuration can solve semantic query-authoring problems.

DAA-C01 Question 205

Single answerPerform exploratory ad-hoc analyses using Notebooks and worksheets to describe data

A retail analytics team is investigating a sudden drop in weekly online revenue. An analyst needs to perform exploratory ad-hoc analysis in Snowflake, quickly profile the SALES table, compare trends by product category, and share the investigation with teammates who may want to rerun and extend the analysis. The analyst wants to combine SQL results with narrative comments and simple visualizations in a single interactive environment. Which Snowflake feature is the best fit for this requirement?

A
Use a Snowflake Notebook so the analyst can run SQL in cells, add explanatory text, visualize result sets, and keep the exploratory workflow in one shareable document
B
Use a standard worksheet only, because worksheets are the only Snowflake interface designed for ad-hoc SQL exploration and charting with team collaboration
C
Create a dynamic table to automatically profile the SALES table and document findings for teammates in the same object
D
Build a permanent semantic model first, because ad-hoc exploratory analysis in Snowflake requires a governed semantic layer before visualizing data

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use a Snowflake Notebook. In this scenario, the analyst needs an environment for exploratory ad-hoc analysis that supports SQL execution, descriptive commentary, visual output, and easy sharing so others can rerun or extend the work. Snowflake Notebooks are designed for this style of iterative analysis and documentation. Worksheets remain valuable for quick SQL queries and result inspection, but they are less aligned with the requirement to capture the full analytical narrative and workflow in a single interactive artifact. Dynamic tables are transformation objects rather than exploratory tools, and a semantic model is helpful for governed analytics but not required for descriptive ad-hoc investigation. This aligns with Snowflake best practices of using the right interface for the task: worksheets for quick query execution and notebooks for richer exploratory analysis, documentation, and collaboration.

A. Correct.
Correct. Snowflake Notebooks are well suited for exploratory ad-hoc analysis because they let analysts combine executable cells, such as SQL, with markdown-style narrative and visual outputs in one interactive document. This supports profiling data, comparing trends, documenting findings, and sharing a repeatable investigation with teammates. The scenario specifically calls for combining analysis, comments, and visuals in a single environment, which aligns directly with Notebook capabilities.
B. Incorrect.
Incorrect. Worksheets are useful for ad-hoc SQL analysis and can display results and basic charts, but the statement is too restrictive and inaccurate because worksheets are not the only Snowflake interface for ad-hoc exploration. The scenario also emphasizes combining narrative commentary, interactive analysis, and shareable investigative context in one document, which is a stronger match for Notebooks than a worksheet alone.
C. Incorrect.
Incorrect. Dynamic tables are used for declarative pipeline-style data transformation and incremental refresh patterns, not for documenting exploratory analysis in an interactive, shareable notebook-style workflow. A dynamic table does not provide narrative cells, exploratory charting context, or collaborative investigation notes in the way the scenario requires.
D. Incorrect.
Incorrect. A semantic model can be useful for governed business metrics and consistent definitions, but it is not a prerequisite for ad-hoc exploratory analysis in Snowflake. Requiring a semantic model first would add unnecessary setup and does not address the immediate need to quickly profile data, test hypotheses, and annotate findings during investigation.

Timed practice exam

Take a DAA-C01 practice test under exam conditions

65 questions in 115 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

DAA-C01 practice questions 201 to 267 of 267

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 3 pages of up to 100 questions.