Assuming that the session parameter USE_CACHED_RESULT is set to false, what are characteristics of Snowflake virtual warehouses in terms of the use of Snowpark?

Question

Options

• ACreating a DataFrame from a table will start a virtual warehouse.
• BCreating a DataFrame from a staged file with the read() method will start a virtual warehouse.
• CTransforming a DataFrame with methods like replace() will start a virtual warehouse.
• DCalling a Snowpark stored procedure to query the database with session.call() will start a virtual

• A
  3% (1)
• C
  5% (2)
• D
  92% (35)

Explanation

Calling session.call() executes a stored procedure that actively runs SQL against the database, which requires compute resources - so a virtual warehouse must start to process that work. Options A and C are wrong because Snowpark DataFrames use lazy evaluation: creating a DataFrame from a table or transforming it with methods like replace() only builds a logical query plan and never triggers execution on its own. Option B is similarly wrong - calling read() on a staged file constructs a DataFrame definition but does not execute any computation until an action (like collect() or show()) is explicitly invoked. The core principle is that only actions (not DataFrame construction or transformation) cause a warehouse to spin up; session.call() is an action because it forces immediate execution of the stored procedure.

Memory tip: Think of a Snowpark DataFrame as a recipe, not a meal - writing down ingredients and steps (creating/transforming) costs nothing, but actually cooking it (calling an action like session.call()) is when the stove (warehouse) turns on.

No community discussion yet for this question.