ARA-C01 Question 257
Select 3Data sourcesA global retailer is designing a Snowflake-based ingestion architecture for multiple data sources. The company must load: (1) daily CSV files from an S3 bucket in the same cloud region, (2) near-real-time JSON events from an application team that can call a REST endpoint, and (3) reference data from an external PostgreSQL system that must stay synchronized with minimal custom code. The architect wants to minimize operational overhead while using native Snowflake capabilities where possible. Which combination of approaches should the architect choose? (Select TWO.)
- A
Use a Snowflake external stage on the S3 bucket with Snowpipe or scheduled COPY INTO for the daily CSV files.
- B
Expose a Snowflake internal stage as an HTTP endpoint so the application can POST JSON events directly into Snowflake.
- C
Use the Snowpipe Streaming API for the near-real-time JSON events sent by the application.
- D
Use a connector/replication approach such as Snowflake Connector for PostgreSQL or partner CDC tooling to synchronize the PostgreSQL reference data.
- E
Create a materialized view in Snowflake that directly queries PostgreSQL tables over JDBC so the reference data stays synchronized.
Show answer and explanation
Correct answers: A, C, D
Explanation
The scenario mixes three common source patterns: staged files, application event streams, and operational database synchronization. For S3-hosted CSV files, an external stage with COPY INTO or Snowpipe is the standard Snowflake-native design. For near-real-time events from an application, Snowpipe Streaming is the best native fit because it supports low-latency ingestion directly from the producer application. For PostgreSQL synchronization, Snowflake does not natively treat PostgreSQL as a directly queryable source for materialized views; instead, architects typically use connectors or CDC/ELT partner tools to replicate changes into Snowflake tables. These choices minimize custom code and operational burden while aligning with Snowflake guidance for data loading from files, streaming ingestion, and database-source replication patterns.
- A. Correct.
Correct. For files arriving in Amazon S3, a Snowflake external stage is the standard native pattern. From there, the retailer can use COPY INTO on a schedule or Snowpipe for automated file ingestion. This is operationally efficient and aligns with Snowflake best practices for staged file-based data sources.
- B. Incorrect.
Incorrect. Snowflake internal stages are not exposed as generic REST ingestion endpoints for arbitrary HTTP POST requests from applications. Applications cannot directly push event payloads into an internal stage through a native Snowflake REST upload endpoint in the way described here. This distractor reflects a common misconception that stages are equivalent to general-purpose API ingestion services.
- C. Correct.
Correct. For near-real-time application events, Snowpipe Streaming is a native Snowflake capability designed for low-latency row ingestion without relying on cloud storage as an intermediate landing zone. It is appropriate when an application can actively send data to Snowflake through supported APIs/SDKs.
- D. Correct.
Correct. For ongoing synchronization from PostgreSQL with minimal custom code, a connector or CDC-based replication solution is appropriate. Snowflake supports connector-based ingestion patterns and integrates well with partner tools for change data capture. This is more suitable than file exports when the requirement is to keep relational reference data synchronized with low operational overhead.
- E. Incorrect.
Incorrect. Snowflake materialized views cannot directly query external PostgreSQL tables over JDBC. Materialized views in Snowflake are created on Snowflake tables or certain supported constructs within Snowflake, not as live federated queries to external OLTP systems. This option confuses virtualization/federation concepts with Snowflake's materialized view functionality.