SnowPro Advanced: Architect · 5% of the exam

Snowpark and Other Development: free practice questions

5 sample questions from our 13-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Snowflake exam.

1. An architect is designing a Snowflake Native App that will be published on the Snowflake Marketplace. The app must allow the consumer to install it in their own Snowflake account and query provider-owned data without the provider ever exposing the underlying tables directly. Which two features of the Native App Framework enable this pattern? (Select TWO.)

  • A. Secure Views defined inside the application package, which restrict column-level access to the underlying provider data
  • B. Shared databases attached to the application package, so the consumer account queries provider data through the app's versioned objects✓ Correct
  • C. Data Sharing via a listing, so the app installs a reference to the provider's share inside the consumer account
  • D. Application roles granted to consumers, which scope permissions to only the objects exposed by the app✓ Correct
  • E. External tables pointing to a provider-owned S3 bucket, allowing consumers to query raw files without table grants
Explanation

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 A (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 C 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 E (External tables on provider S3) would expose the provider's storage outside Snowflake's control and is not a Native App pattern.

2. A data engineering team writes a JavaScript stored procedure that loops through a cursor of orders and calls a helper function for each row. After deploying, they find that if the helper function raises an exception midway through the loop, some rows are committed and others are not. They want ALL rows to succeed or NONE to be committed. What is the CORRECT approach?

  • A. Wrap the entire loop body in a JavaScript `try/catch` block and call `snowflake.execute({ sqlText: 'ROLLBACK' })` inside the `catch` block to undo partial work.
  • B. Define the stored procedure with `EXECUTE AS OWNER` so that the owner's transaction context is used, which automatically enables full atomicity.
  • C. Call the stored procedure inside an explicit transaction (`BEGIN ... COMMIT/ROLLBACK`) from the caller, and ensure the procedure does not issue an implicit `AUTOCOMMIT`, allowing the caller to rollback on failure.✓ Correct
  • D. Replace the JavaScript stored procedure with a Python stored procedure, which natively supports atomic batch processing through pandas `DataFrame.apply()`.
Explanation

Stored procedures in Snowflake do not automatically wrap their DML in a single atomic transaction unless the caller wraps the `CALL` in an explicit `BEGIN ... COMMIT/ROLLBACK` block (or the procedure itself manages transaction control). By calling the procedure inside an explicit transaction and having the application-level caller issue `ROLLBACK` on any exception propagated out of the procedure, all DML within that transaction is undone atomically. Option A is partially on the right track but incomplete — while catching the exception and issuing a `ROLLBACK` via `snowflake.execute()` inside the procedure would work, this must be done carefully; the issue is that the explicit ROLLBACK call inside the JavaScript is the mechanism, not just a try/catch alone. However, Option C is more architecturally correct because it keeps transaction management at the appropriate layer (the caller) without relying on error-prone in-procedure rollback logic. Option B is incorrect — `EXECUTE AS OWNER` controls privilege context, not transaction atomicity. Option D is incorrect — switching to Python does not grant automatic atomicity; pandas `apply()` is a client-side operation and unrelated to Snowflake transaction semantics.

3. A company builds a Snowflake Native App that includes a Streamlit-in-Snowflake dashboard for consumers. After publishing version 1.0, the provider needs to add a new stored procedure in version 1.1. Which statement about versioning and consumer upgrades is CORRECT?

  • A. Consumers are automatically upgraded to version 1.1 as soon as the provider releases it, with no action required from the consumer.
  • B. The provider can set a default version on the application package; consumers who have set their installed app to auto-upgrade will receive version 1.1, while others must manually upgrade.✓ Correct
  • C. Once a Native App is installed, the consumer's version is permanently locked and can only be updated by uninstalling and reinstalling the app.
  • D. Versioning applies only to the Streamlit component; stored procedures always reflect the latest provider code regardless of the installed version.
Explanation

In the Native App Framework, the provider sets a default (or patch) version on the application package. Consumers can configure their installed application to use the default version (auto-upgrade) or pin to a specific version. When the provider sets version 1.1 as the default, consumers with auto-upgrade enabled will receive it; others remain on 1.0 until they manually upgrade. Option A is incorrect — upgrades are not forced automatically on all consumers without their configuration allowing it. Option C is incorrect — apps do not need to be uninstalled to upgrade; the `ALTER APPLICATION ... UPGRADE` command (or auto-upgrade) handles this. Option D is completely false — versioning applies to the entire application package, including all stored procedures, Streamlit apps, and other objects.

4. A Snowpark Scala job submits a complex multi-join aggregation query via the DataFrame API. The architect wants to confirm that all transformation logic is being pushed down to the Snowflake SQL engine rather than processed on the client. What is the BEST method to verify this?

  • A. Call `.explain()` on the final DataFrame to inspect the logical and physical query plan generated by Snowpark, then verify no client-side operations appear in the plan.✓ Correct
  • B. Run the Snowpark job and check Snowflake's QUERY_HISTORY view; if query execution time is under one second, all logic was pushed down.
  • C. Enable verbose logging in the Snowpark Scala driver and search the logs for 'client-side filter' warnings, which indicate operations that were not pushed down.
  • D. Compare row counts between the Snowpark DataFrame result and a direct SQL query; identical counts confirm full pushdown.
Explanation

`.explain()` prints the logical and physical query plan for the DataFrame, showing exactly what SQL Snowpark will generate and send to Snowflake. If all transformations appear as SQL operations in the plan (joins, aggregations, filters, etc.), they will be executed by the Snowflake engine. This is the standard, direct method to audit pushdown behavior. Option B is unreliable — query execution time depends on data size, warehouse size, and caching, not solely whether logic was pushed down. Option C is a misconception; Snowpark does not emit 'client-side filter' warnings in its logging framework in this manner. Option D only validates correctness, not WHERE the computation occurs — both a pushed-down and a client-side computation could return identical counts.

5. An architect is evaluating whether to use an external function or a Snowpark Python UDF for a use case that calls a third-party REST API to enrich records. Which statement BEST describes the architectural trade-off?

  • A. External functions are always faster than Snowpark UDFs because they offload computation to dedicated external compute.
  • B. External functions invoke a remote HTTP endpoint (e.g., AWS Lambda) per batched call and introduce network latency and external service dependency, while Snowpark Python UDFs execute inside Snowflake's warehouse nodes, keeping computation within the Snowflake perimeter.✓ Correct
  • C. Snowpark Python UDFs can make outbound HTTP calls to third-party APIs directly without any additional configuration, making external functions redundant.
  • D. External functions support streaming row-by-row responses, while Snowpark Python UDFs require all results before returning to the caller.
Explanation

External functions route calls through an API Integration to an external HTTP endpoint (e.g., an AWS API Gateway backed by Lambda), introducing network round-trip latency and a dependency on external service availability. Snowpark Python UDFs execute inside Snowflake's warehouse environment, keeping compute within the Snowflake security perimeter. For third-party API enrichment, external functions are the correct choice — but understanding their latency and dependency costs versus in-warehouse UDFs is the key trade-off. Option A is false; external functions are typically SLOWER due to network overhead, not faster. Option C is misleading — standard Snowpark Python UDFs run in a sandboxed environment and cannot make arbitrary outbound network calls; Snowpark Container Services or external functions are needed for that. Option D is false; external functions batch rows in requests and return batched responses, not streaming row-by-row results.

8 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free