SNOWPRO-CORE-C03 Practice Questions: Snowflake AI Data Cloud Features & Architecture Domain

Correct answer (B): Within a single Snowflake account, databases are the primary top-level logical containers for objects like schemas, tables, and views. Using separate databases for HR and Sales provides clear separation while still allowing controlled sharing of objects across databases if needed. Warehouses, stages, and cloud storage buckets do not provide the same logical object hierarchy separation for data modeling and governance inside Snowflake.

Why the other options are wrong:
- Option A: Virtual warehouses control compute for queries but do not logically separate the underlying data. HR and Sales could still accidentally access each other’s tables if they share the same database and schema structure.
- Option C: Cloud storage buckets exist outside Snowflake’s object hierarchy. While they matter for loading or external data, they do not provide the primary logical separation of databases and schemas inside a Snowflake account.
- Option D: Stages are used for data loading/unloading, not as the primary logical container for production tables and views. They are not the best object to establish HR vs. Sales boundaries.

Correct answer (C): Snowpark is the developer framework that lets engineers write Python (and other language) code that runs inside Snowflake compute, operating directly on Snowflake data. It is ideal for feature engineering and data processing pipelines that must stay close to the data.

Why the other options are wrong:
- Option A: Cortex is a managed AI and LLM service focused on applying models and LLMs to data, not a general-purpose framework for arbitrary Python feature engineering logic.
- Option B: Snowflake ML simplifies many ML lifecycle tasks, but the scenario specifically requires running custom Python feature engineering code on Snowflake compute, which is Snowpark’s role.
- Option D: Marketplace is for sharing data products and services, not for running internal Python feature engineering pipelines.

Correct answer (A): Dynamic Tables are specifically designed to maintain a target table in sync with changes in source data based on a defining query. They provide managed, incremental transformations over time without requiring you to explicitly create and orchestrate streams and tasks, matching the desire for a managed continuous transformation.

Why the other options are wrong:
- Option B: Incorrect. A standard view does not materialize data or manage refresh; every query re-reads the raw table, which does not provide a curated, maintained physical table for performance and operational needs.
- Option C: Incorrect. Streams plus manual batch operations can implement incremental processing, but the requirement is to avoid managing streams and tasks explicitly. Dynamic Tables are the managed alternative.
- Option D: Incorrect. Iceberg tables are about interoperating on Apache Iceberg-format data, often in external storage. They do not by themselves provide a managed incremental transformation from one table into another.

Correct answer (A): Using a single Snowflake organization with multiple accounts in different regions and clouds allows centralized governance and billing while giving regions autonomy. Data residency is addressed by storing and processing data in-region in each account. Global analytics can be enabled selectively via data replication (for physical copies where needed) and secure data sharing across accounts, all within the same organization.

Why the other options are wrong:
- Option B: Incorrect. Snowflake does not automatically replicate data across regions; explicit replication or sharing is required. A single-region account cannot satisfy strict in-region residency across multiple regions.
- Option C: Incorrect. Reader accounts query provider-managed data and do not create local regional copies, which can violate residency and performance requirements for local processing.
- Option D: Incorrect. Multiple organizations complicate central governance and billing. External storage alone does not replace Snowflake-native replication and secure data sharing patterns.

Correct answer (A): Snowflake's result cache stores results for previously run queries and can return them instantly if the same query is issued and the underlying data has not changed. A major data load changes the table and invalidates the cached result. As a result, Snowflake must re-execute the query, causing the longer runtime observed.

Why the other options are wrong:
- Option B: Incorrect. Resizing a warehouse affects compute resources but does not 'turn off' caching globally. The key trigger here is the data change, not warehouse size.
- Option C: Incorrect. Micro-partitions are managed automatically; there is no manual rebuild step that would explain this behavior.
- Option D: Incorrect. Queries are executed in the region of the account; data is not transparently routed to another region, and there is no automatic slow replication that would cause this specific symptom.

Correct answer (C): Snowflake automatically organizes table data into columnar, compressed micro-partitions and maintains the metadata needed for pruning at query time. Users do not manually create or manage partitions; optimization happens through Snowflake’s storage engine and metadata.

Why the other options are wrong:
- Option A: Snowflake does not require user-defined partitions for pruning. While clustering keys can help in some cases, explicit physical partitions are not created or maintained by users.
- Option B: Splitting tables across schemas does not create physical partitions and would add unnecessary complexity. It also does not align with how Snowflake’s storage engine works.
- Option D: Virtual warehouses are compute resources and cannot be used to physically partition data. They all access the same shared storage layer.

Correct answer (B): Snowflake Iceberg tables allow Snowflake to manage metadata and query data stored in external object storage using the Apache Iceberg format, without copying that data into native Snowflake storage. This meets the requirement to leave data in the data lake while querying it as Snowflake tables.

Why the other options are wrong:
- Option A: COPY INTO would ingest and store data in Snowflake, violating the requirement to keep raw data in the existing object storage without copying.
- Option C: Exporting results from Snowflake does not enable querying the existing Iceberg tables from within Snowflake. It shifts more work to external systems and breaks the desired unified query experience.
- Option D: Dynamic Tables automate transformations within Snowflake but assume data is in Snowflake tables. They are not a mechanism for directly querying externally stored Iceberg data without ingestion.

Correct answer (A): Snowpark is designed for data processing in languages like Python, executed inside Snowflake’s compute layer. It lets the team define transformations in Python while keeping execution close to the data, leveraging Snowflake’s scalability and governance and avoiding data movement in and out of external environments. Cortex focuses on AI/LLM use cases, Streamlit on interactive apps, and Snowflake ML on model training/inference, none of which directly address general-purpose Python transformations on data.

Why the other options are wrong:
- Option B: Cortex LLM functions provide AI capabilities such as text generation and summarization, not automatic code translation of arbitrary Python transformations into SQL for production pipelines.
- Option C: Streamlit in Snowflake is for building interactive apps and UIs, not for running backend batch transformation pipelines at scale inside the database.
- Option D: Snowflake ML is for building and serving machine learning models. It does not replace arbitrary transformation logic and is not intended as a general-purpose ETL framework.

Correct answer (A): Cortex Analyst is specifically designed to allow business users to ask natural language questions about governed Snowflake data and receive answers and visualizations. It leverages Snowflake’s metadata, security, and query engine and does not require the team to manage LLM infrastructure, matching the described use case.

Why the other options are wrong:
- Option B: Cortex LLM functions are powerful for LLM-powered transformations inside SQL, but they require more technical setup and are not a pre-built conversational analytics experience for business users.
- Option C: Snowflake Notebooks are suited for analysts and engineers mixing SQL, Python, and narrative text. They are not a turnkey natural language Q&A interface for non-technical users.
- Option D: Streamlit in Snowflake can be used to build custom interactive apps, but the team would need to design and implement the full natural language interface and logic themselves. Cortex Analyst provides this functionality out of the box.

Correct answer (B): Using separate warehouses for each workload leverages Snowflake’s shared data architecture so all workloads access one copy of the data. A multi-cluster warehouse for BI handles high concurrency, while dedicated ELT and data science warehouses isolate heavy batch and exploratory workloads. Auto-suspend/resume provides cost control when workloads are idle, and no data duplication is required.

Why the other options are wrong:
- Option A: Incorrect. A single large always-on warehouse prevents workload isolation, risks contention between workloads, and wastes compute cost when some workloads are idle.
- Option C: Incorrect. Separate accounts and databases fragment governance and require data replication between accounts, which contradicts the goal of minimal data duplication.
- Option D: Incorrect. Copying tables into multiple databases duplicates data and increases maintenance overhead; assigning small warehouses does not solve concurrency needs for BI or isolate intense ELT from other workloads as well as dedicated warehouses.