Snowflake ARA-C01: Data Engineering Practice Questions

In the Native App Framework, the APPLICATION PACKAGE acts as a container that bundles the application logic with references to provider data (via shares included in the package). Consumers install the app from the package, querying provider data only through the app's versioned objects — the underlying tables are never directly shared. APPLICATION ROLES are defined inside the app and granted to consumer users, scoping exactly which app objects they can access. Option D (Secure Views) is a general Snowflake feature and not a Native App-specific mechanism; while views can be used inside an app, they alone do not define the Native App data-isolation model. Option B confuses a Marketplace listing (a distribution mechanism) with the architectural pattern; the listing is how the app is published, not how data isolation is enforced. Option A (External tables on provider S3) would expose the provider's storage outside Snowflake's control and is not a Native App pattern.

In a Snowpark UDTF, a single handler class instance may be reused across partitions in some execution contexts. The correct patterns are: (1) Initialize mutable state inside process() with a guard (e.g., a flag set on the first call), ensuring it resets per logical partition boundary without relying on __init__ being called per partition; and (2) implement end_partition() to finalize and emit any buffered rows, which is called once at the end of each partition — this is the correct place to flush buffers and perform cleanup. Option B is partially correct in concept but incorrect in detail — __init__ is not guaranteed to be called per partition in all configurations; the PARTITION BY clause controls data routing, not class instantiation lifecycle. Option C is a valid workaround but changes the interface entirely and loses the multi-row output benefits of UDTFs. Option E (@staticmethod) is incorrect syntax for a handler class and would break the UDTF entirely. Option D (warehouse size) has no effect on Python handler instance lifecycle.

The Snowpark ML Modeling API (snowflake.ml.modeling) provides sklearn-compatible estimator wrappers (e.g., RandomForestClassifier) that accept Snowpark DataFrames and push the training workload into Snowflake — data never leaves the platform. This is the purpose of the Snowpark ML Modeling API. Option D pulls all data to the client and trains locally, defeating the purpose of in-Snowflake ML and creating data transfer overhead. Option A is architecturally incorrect — sklearn.fit() requires an entire dataset, not individual rows, so it cannot be used in a row-level UDF; this pattern would produce nonsensical results. Option B manually exports and re-imports data, adding latency, cost, and data governance risk.

Correct — Option C: Snowpark ML Modeling API objects (preprocessors, pipelines, estimators) are built on top of the Snowpark DataFrame API, which uses lazy evaluation. Calling fit() does trigger computation (to learn parameters), but transform() returns a new Snowpark DataFrame representing the transformation plan — it does not execute until a terminal action (collect(), show(), to_pandas(), write.save_as_table(), etc.) is invoked. This is consistent with the broader Snowpark DataFrame contract and is a common source of confusion for engineers migrating from eager-execution frameworks like pandas.

Wrong — Option B: There is no get_output_stage_location() method on Snowpark ML pipelines, and results are not automatically written to an internal stage. This reflects a misconception about how Snowpark ML handles output — it does not have a file-based intermediate output model.

Wrong — Option D: While it is true that calling transform() on a pipeline whose last step is a pure estimator (not a transformer) would raise an error in some ML frameworks (e.g., scikit-learn), the Snowpark ML Pipeline class mirrors scikit-learn conventions: if the last step is an estimator, transform() does raise an exception — but the question states the behavior is a silent no-op with no rows, not an error. The real cause is lazy evaluation, not the estimator-vs-transformer distinction. Additionally, predict() is the correct terminal call for inference, but that is a separate concern from why no computation appears.

Wrong — Option A: Snowpark ML preprocessing transformers do not universally execute inside a Python UDF sandbox; many operations (e.g., StandardScaler) are translated into SQL expressions pushed down to the Snowflake query engine and would appear in query history once a terminal action is triggered. The claim that they never appear in query history is incorrect and conflates the lazy-evaluation issue with the execution model.

MAX_BATCH_ROWS is a parameter available in CREATE EXTERNAL FUNCTION that explicitly caps the number of rows Snowflake will include in a single HTTP batch request to the remote endpoint, directly addressing Lambda timeouts from oversized payloads. Pairing this with tuned Lambda reserved concurrency ensures the downstream service can handle the resulting parallel batch volume. Option A is incorrect — COMPRESSION in the API Integration controls payload compression format, not batch row count. Option B is incorrect — REQUEST_TRANSLATOR is used to reshape the request payload structure, not to split batches; Snowflake controls batching before the translator runs. Option E is incorrect — warehouse size influences query parallelism broadly but does not directly control external function batch sizes; it is not a reliable or recommended tuning lever for this problem.