ARA-C01 Question 261
Single answerData in motionA retail company streams order events from Kafka into Snowflake by using Snowpipe Streaming. During peak sales, event volume increases sharply and the downstream analytics team reports that some newly ingested rows are not appearing immediately in query results, even though the producer application reports successful inserts. The architect must improve freshness for operational dashboards without redesigning the pipeline around batch files. Which action is the MOST appropriate?
- A
Modify dashboard queries to read from the stream object created on the target table, because streams expose uncommitted rows before they are visible in the base table
- B
Increase the frequency of TASK executions that query the target table, because tasks control when Snowpipe Streaming commits ingested rows
- C
Tune the Snowpipe Streaming channel usage and client flushing/commit behavior so rows are committed more frequently and become visible sooner
- D
Replace Snowpipe Streaming with external tables on Kafka topics, because external tables provide lower-latency visibility than committed table storage
Show answer and explanation
Correct answer: C
Explanation
This scenario focuses on data in motion and the difference between data being accepted by a streaming client versus becoming visible for SQL queries. In Snowpipe Streaming, ingestion clients write rows through channels, and those rows become queryable after the service commits them. Therefore, if the business requirement is lower-latency dashboard freshness without moving to file-based ingestion, the best architectural response is to optimize the Snowpipe Streaming ingestion pattern itself, especially channel management and flush/commit behavior.
Why the other options are wrong:
- Streams are CDC objects over committed table changes; they do not surface uncommitted data.
- Tasks orchestrate downstream processing but do not influence when Snowpipe Streaming commits rows.
- External tables query files in external stages/object storage and are not a direct Kafka ingestion mechanism.
This aligns with Snowflake best practices for streaming ingestion: use Snowpipe Streaming when low-latency ingestion is required, and tune the ingestion client behavior to meet freshness objectives rather than expecting downstream objects like streams or tasks to compensate for delayed commit visibility. Relevant Snowflake documentation includes Snowpipe Streaming concepts, ingest SDK/client behavior, and Snowflake streams/task documentation describing their roles in CDC and orchestration rather than ingestion commit control.
- A. Incorrect.
Incorrect. A Snowflake stream object does not expose uncommitted or not-yet-committed rows. Streams track change data capture offsets for table changes that are already committed to the source object. If rows are not yet visible in the base table, querying a stream on that table will not solve freshness issues.
- B. Incorrect.
Incorrect. Tasks schedule SQL execution, but they do not control commit timing for Snowpipe Streaming ingestion. A task can process data after it is committed and visible, but it cannot make streamed rows appear sooner by changing task frequency.
- C. Correct.
Correct. With Snowpipe Streaming, rows become queryable after they are committed through the streaming ingestion path. If producers report successful inserts but users observe visibility lag, the architect should evaluate how the client SDK, channels, and flush/commit settings are configured. More appropriate flushing and commit patterns can reduce end-to-end latency for operational reporting while keeping the streaming architecture intact.
- D. Incorrect.
Incorrect. External tables are used to query data in external storage such as cloud object stores, not Kafka topics directly. They are not a replacement for Snowpipe Streaming for low-latency row ingestion from Kafka into Snowflake tables. This option reflects a misunderstanding of how external tables work.