You are designing a data ingestion pipeline for a SaaS application that generates JSON log files daily. These files are uploaded to an AWS S3 bucket. You need to load this data into Snowflake, transfo

Question

Options

• ASnowpipe with Snowsight Tasks and Materialized Views.
• BSnowpipe with External Tables and User-Defined Functions (UDFs).
• CScheduled Tasks using Cron and Stored Procedures with Python IJDF.
• DSnowpipe with Streams and Tasks.
• ESnowpipe with COPY INTO and Views.

• A
  4% (1)
• B
  4% (1)
• C
  9% (2)
• D
  65% (15)
• E
  17% (4)

Explanation

Snowpipe + Streams + Tasks form a fully event-driven, serverless pipeline that directly maps to all four requirements: Snowpipe auto-ingests JSON files the moment they land in S3 (via SQS notifications), Streams perform CDC-style tracking of newly loaded raw rows in a staging table, and Tasks fire automatically when Streams have new data to execute the JSON-to-relational transformation - all without managing any infrastructure.

Why the distractors fail:

• A is nonsense as a pipeline - Snowsight is a UI tool, not a processing feature, and Materialized Views optimize reads but don't drive ingestion workflows.
• B inverts the goal: External Tables leave data in S3 rather than loading it into Snowflake, and UDFs alone don't automate transformation orchestration.
• C uses time-based Cron polling instead of event-driven triggering, meaning latency between file arrival and ingestion is unpredictable, and Stored Procedures add operational complexity.
• E is close but COPY INTO is a manual batch command - it doesn't auto-trigger on file arrival - and Views are virtual (no stored transformation output), so data isn't persisted in a structured table.

Memory tip: Think S-P-S-T - S3 drops a file → Pipe ingests it → Stream captures the delta → Task transforms it. Each letter hands off to the next like an assembly line, which is exactly what "automated, low-overhead, cost-optimized" looks like in Snowflake.

No community discussion yet for this question.