I’m facing a strange issue in Snowflake/dbt today.

We have Viewpoint source tables ingested through Fivetran into Snowflake. Several staging models have a column named PURGE. These models have been running successfully every day for a long time.

Today, all models referencing PURGE suddenly started failing with:

SQL compilation error:
000904 (42000): invalid identifier 'PURGE'

The interesting part:

• The PURGE column still exists in the Snowflake landing/Fivetran table
• No source column was removed
• The dbt code hasn't intentionally changed
• Models that don't reference PURGE are working
• This works:

​

SELECT "PURGE"
FROM <table>
LIMIT 1;

• But this fails:

​

SELECT PURGE
FROM <table>
LIMIT 1;

with:

invalid identifier 'PURGE'

So it appears that unquoted PURGE is no longer being resolved as a column identifier, while quoted "PURGE" still works.

Does anyone know if there was a recent Snowflake behavior change / parser change / release that could cause this?

I'm especially interested in whether PURGE has recently started being treated as a keyword in some SQL context, because this broke many existing dbt models simultaneously without any apparent schema change.

Any insight into the exact Snowflake change would be appreciated.

I’m preparing for the SnowPro Advanced Architect exam and ran into two practice questions where the “expected” answers seem debatable. Would love opinions from real Snowflake practitioners on both the real-world answer vs exam-answer logic.

Question 1: Clustering Key

The general query patterns for the table are:

1. DeviceId, IOT_timestamp, and CustomerId are frequently used in the filter predicate for SELECT statements
2. City and DeviceManufacturer are often retrieved
3. There is frequently a COUNT on UniqueId

Which field(s) should be used for the clustering key?

A. IOT_timestamp
B. City and DeviceManufacturer
C. DeviceId and CustomerId
D. UniqueId

Most sources say A (IOT_timestamp), likely because IoT/time-series workloads are commonly queried by time ranges.

But raw timestamps can have extremely high cardinality (seconds/milliseconds), and Snowflake docs say clustering keys should have appropriate cardinality. Wouldn’t C make more sense if DeviceId and CustomerId are frequently filtered on? Or ideally should it be something like DATE_TRUNC(IOT_timestamp), which isn’t an option?

How would you approach this in real-world design vs exam logic?

Question 2: PUT + Snowpipe REST API vs SQL API

An Architect needs to define the process for ingesting data files into a table after uploading them to a stage using the PUT command.

Which data loading process will meet these requirements?

A. Use Snowpipe with auto-ingest
B. Use Snowpipe REST API endpoints
C. Use the Snowflake SQL API
D. Use an external table with auto-refresh

The common answer seems to be B because PUT uploads to an internal stage and auto-ingest only works with external cloud storage notifications.

But practically, wouldn’t C be simpler? You could just execute:

PUT ...
COPY INTO ...

or trigger COPY INTO remotely using SQL API, without building code around Snowpipe REST endpoints.

Is the exam just looking for “Snowflake-native continuous ingestion best practice,” while SQL API is technically possible but not preferred?

Would love to hear how people would answer these in the exam vs in production.