ARA-C01 Question 304
Single answerKafkaA retail company streams order events from Apache Kafka into Snowflake for near-real-time analytics. The architecture team wants to minimize custom code, handle schema evolution in the event payloads, and support high-throughput ingestion with low operational overhead. Kafka producers publish Avro messages and use Schema Registry. Which approach should the architect recommend?
- A
Use the Snowflake Kafka Connector with Snowpipe Streaming, configure a schema detection/evolution workflow for Avro payloads, and land the data into Snowflake tables designed for streaming ingestion.
- B
Use a standard JDBC sink connector to batch-load Kafka messages directly into Snowflake tables every few minutes, because JDBC provides the best support for Avro schema evolution in Snowflake.
- C
Export Kafka topics to local files on the Kafka brokers and use PUT and COPY INTO commands from those broker file systems into Snowflake internal stages.
- D
Use an external function in Snowflake to pull messages directly from Kafka topics on demand, because external functions are designed for low-latency event ingestion from message brokers.
Show answer and explanation
Correct answer: A
Explanation
For Kafka-to-Snowflake ingestion, the recommended pattern is to use the Snowflake Connector for Kafka. When the requirement emphasizes near-real-time loading, high throughput, and lower operational overhead, Snowpipe Streaming is the key capability to consider because it is designed for low-latency row streaming into Snowflake without relying on file staging in the same way as classic Snowpipe patterns. In environments using Avro and Schema Registry, architects should design for controlled schema evolution and downstream transformation/parsing strategies in Snowflake rather than relying on generic database sinks or custom polling solutions. This recommendation aligns with Snowflake documentation and best practices around the Snowflake Connector for Kafka and Snowpipe Streaming.
- A. Correct.
Correct. The Snowflake Kafka Connector is the native integration pattern for loading Kafka data into Snowflake. For near-real-time ingestion and reduced latency, Snowpipe Streaming is the recommended approach. Since the producers publish Avro messages with Schema Registry, this aligns well with handling evolving schemas in the Kafka ecosystem while minimizing custom ingestion code. In practice, architects typically combine the connector with downstream table design and parsing patterns that accommodate schema changes, rather than building bespoke consumers.
- B. Incorrect.
Incorrect. A generic JDBC sink is not the recommended architecture for high-throughput, near-real-time Kafka ingestion into Snowflake. JDBC-based loading usually introduces more custom tuning and operational burden, and it does not provide the same optimized ingestion path as the Snowflake Kafka Connector. The claim that JDBC provides the best support for Avro schema evolution in Snowflake is also misleading.
- C. Incorrect.
Incorrect. Kafka brokers are not intended to be used as file-export hosts for Snowflake PUT operations. Snowflake's PUT command uploads files from a client machine to an internal stage; it does not read files directly from arbitrary broker file systems in a production streaming design. This option adds unnecessary operational complexity and is not a best-practice architecture for continuous Kafka ingestion.
- D. Incorrect.
Incorrect. External functions allow Snowflake to call out to remote services, typically through API Gateway-style integrations, but they are not intended to act as a Kafka ingestion mechanism. Using external functions to poll or pull directly from Kafka topics would create an inefficient and nonstandard architecture, and it would not meet the stated goals of high-throughput, low-overhead streaming ingestion.