Archives for March 2025

You’ve been asked to set up an automated alerting system for a critical data table. Whenever new rows appear, an email must be sent to notify the team immediately.

No dashboards. No polling. Just pure Snowflake magic.

Your Task:

Create an alert that sends an email when new data lands in a table named alert_input_data in your schema (week_135 or equivalent). Your alert should trigger automatically — not on a fixed schedule.

Constraints:

• Do not use the ACCOUNTADMIN role.
• The email must be sent using Snowflake’s built-in notification system.
• The alert must fire only when new rows are present. (So no timed checks)
• You must use a warehouse you have access to.

Expected Outcome:

When a new row is inserted into the table, you receive an email with a message confirming that new data has landed.

Bonus Challenges:

• Include useful metadata (like a row count or timestamp) in the email.
• Allow the alert to be reused for different tables or emails with minimal changes.
• Log when the alert was triggered and what it detected.

Hints (if you need them):

You’ll probably want to look into:

• Creating a table that supports data change detection
• Using Snowflake’s email notification integrations
• Writing alerts that are event-based, not scheduled
• Making sure your role has permission to execute the alert

If you’ve, in the past, used CORTEX.COMPLETE as part of any workflow you are well aware of the strenuous prompting necessary in order to make it produce predictable results.

Well, worry no more! Structured outputs allow you to provide a JSON schema within which the LLM must respond.

Your challenge is to have CORTEX.COMPLETE produce a list of cool Snowflake features and descriptions of those features. The output ought to look like the below, post-processing:

Every Pi Day (3.14), math students, using fake but famous mathematicians’ names, flock to The Golden Ratio Bakery to enjoy their favorite π-themed pies. Instead of picking a random dessert, they select their treat based on the legendary mathematician they admire most.

Alan Turing Apple Pie 9.99£
Ada Lovelace Cherry Pie 12.5£
Carl Gauss Pumpkin Pie 15.00£
Srinivasa Ramanujan Chocolate Pie 8.75£
Katherine Johnson Blueberry Pie 10.99£
Euclid Raspberry Pie 11.25£
Johannes Kepler Strawberry Pie 14.50£
Leonhard Euler Peach Pie 14.99£
Pythagoras Blackberry Pie 9.75£
Fibonacci Mango Pie 13.50£
Sophie Germain Mixed Berry Pie 10.00£
Pierre-Simon Laplace Banana Cream Pie 12.25£
Blaise Pascal Lemon Meringue Pie 11.99£
Hypatia Key Lime Pie 10.75£
John von Neumann Pear Pie 13.99£
Joseph Fourier Apricot Pie 14.25£
Gottfried Wilhelm Leibniz Plum Pie 15.75£
David Hilbert Fig Pie 16.00£
Bernhard Riemann Walnut Pie 14.50£
Niels Bohr Almond Pie 13.25£
Johann Bernoulli Cranberry Pie 12.75£
Henri Poincaré Plum Tart 14.00£
Emmy Noether Coconut Cream Pie 15.99£
Georg Cantor Infinite Layer Pie 17.77£

This year, demand is through the roof, and the usual sequential order processing is causing frustrating delays. Mathematicians—real or not—are notoriously impatient and expect instant, parallel execution for their pie requests.

To avoid a pie-induced catastrophe, we need to optimize the order system by leveraging Snowflake’s ASYNC execution to process multiple mathematicians’ orders simultaneously and return the updated list of satisfied customers without delays.

Your task is to speed up pie order processing by inserting two mathematicians’ pie orders asynchronously using ASYNC, ensuring both inserts complete before returning results using AWAIT, and returning the updated order list sorted by order_id so we know which legendary mind—or at least their name—got their pie first.

Happy Pi Day to all!

Remember if you want to participate:

1. Sign up as a member of Frosty Friday. You can do this by clicking on the sidebar, and then going to ‘REGISTER‘ (note joining our mailing list does not give you a Frosty Friday account)
2. Post your code to GitHub and make it publicly available (Check out our guide if you don’t know how to here)
3. Post the URL in the comments of the challenge.

“A little knowledge is a dangerous thing”—a quote attributed to many, yet still undeniably true. We’ve all witnessed situations where people jump to conclusions based on partial information rather than considering the full picture.

Today, we’re tackling this issue by enforcing restrictions that prevent users from viewing only a fragment of the data.

Join Policies to the Rescue

Join Policies in Snowflake allow us to enforce joins, ensuring that users cannot retrieve data from a table unless they join it with another table. And that’s exactly what we’re going to implement in today’s challenge.

The Challenge
Step 1: Create and Populate the Tables

CREATE OR REPLACE TABLE join_table (
col1 INT,
col2 VARCHAR,
col3 NUMBER )
JOIN POLICY my_join_policy
;

INSERT INTO join_table (col1, col2, col3) VALUES (1, 'Sample Data', 123.45);

CREATE OR REPLACE TABLE join_table_details (col1 INT,  col4 VARCHAR,  col5 DATE);

INSERT INTO join_table_details (col1, col4, col5) VALUES (1, 'Additional Info', '2025-03-07');

Step 2: Enforce Join Restriction

Your task is to configure the join policy so that only the ACCOUNTADMIN role can query join_table directly.

Any other role attempting to query join_table without a join (e.g., with SELECT * FROM join_table) should encounter an error message instead of retrieving data.

Goal

If anyone besides ACCOUNTADMIN runs a direct query on join_table, the expected result should be an error message similar to: