SnowflakeProfessional levelARA-C01Page 4 of 5

ARA-C01 exam dumps: questions 301 to 400 of 434

Page 4 of the free ARA-C01 question bank for the SnowPro® Advanced: Architect exam. Questions 301 to 400 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated April 2026

Start timed practice exam Questions 301 to 400

Free ARA-C01 practice questions

Questions 301 to 305 of 434

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

ARA-C01 Question 301

Single answerConnectors

A SaaS company is building a Snowflake Native App with a Snowflake Connector for PostgreSQL to onboard customer data into each customer's own Snowflake account. During pilot testing, several customers report that connector setup fails because the application cannot create the required integration objects and warehouses using the customer's default application role. The SaaS company's architects want a design that minimizes manual setup, follows Snowflake security best practices, and allows the app to provision only the privileges required for the connector to operate. Which approach should the architects recommend?

A
Require customers to grant ACCOUNTADMIN to the application so the connector can create all required objects during installation.
B
Design the app to request elevated privileges through app specifications and have a customer-approved app instance role perform the setup steps needed by the connector.
C
Instruct customers to pre-create every warehouse, integration, database, and schema manually before installing the app, because connectors cannot participate in controlled privilege elevation.
D
Embed a service user and password for each customer inside the application package so the connector can authenticate externally and create missing Snowflake objects.

Show answer and explanation

Correct answer: B

Explanation

The best answer is to use Snowflake Native App and connector privilege-management patterns that let customers explicitly approve the app's required privileges, rather than over-privileging the app or forcing excessive manual configuration. In practical connector deployments, the architect should minimize setup friction while adhering to least privilege. Requiring ACCOUNTADMIN is an anti-pattern because it grants unnecessary authority. Similarly, embedding credentials is a serious security flaw and bypasses Snowflake's governance model. Snowflake best practices for Native Apps and connectors emphasize controlled, customer-approved privilege elevation for app setup and operation, using application roles and related app authorization mechanisms so the connector can create or manage only the objects it truly needs.

A. Incorrect.
Incorrect. Granting ACCOUNTADMIN to an application is not aligned with least-privilege design and is far broader than necessary for connector setup. Snowflake Native Apps and connector-based solutions should avoid requiring highly privileged administrative roles when a scoped, customer-approved privilege model can be used instead.
B. Correct.
Correct. For Snowflake connectors deployed through a Native App, the recommended pattern is to use customer-approved privilege requests and app roles/instance roles so the app can perform only the setup tasks it actually needs. This supports least privilege, reduces operational friction, and lets customers explicitly approve elevated access required for creating or managing connector-related objects.
C. Incorrect.
Incorrect. While some prerequisites can be pre-created by customers in certain designs, it is not true that connectors cannot use controlled privilege elevation. For Native Apps and connector scenarios, Snowflake provides mechanisms to request and manage the privileges needed for installation and operation, which is generally preferable to forcing extensive manual setup.
D. Incorrect.
Incorrect. Embedding per-customer credentials in an application package is insecure and not an approved Snowflake design pattern for provisioning Snowflake objects in customer accounts. Connector setup should rely on Snowflake's native security and privilege model rather than distributing static administrative credentials.

ARA-C01 Question 302

Single answerConnectors

A retail company uses a partner-built Snowflake Native App and needs to integrate it with an external SaaS system through a Snowflake connector. The security team requires that outbound connectivity be tightly controlled, secrets are not hard-coded in SQL objects, and the provider must be able to deploy the integration consistently across customer accounts. Which design should the architect recommend?

A
Create an EXTERNAL ACCESS INTEGRATION that allows network access only to approved endpoints, store credentials in a SECRET, and have the app reference these objects when making outbound calls.
B
Embed the SaaS API key directly in a stored procedure and use a standard network policy to restrict which external hosts the connector can call.
C
Use a SECURITY INTEGRATION to define the outbound destinations and store the SaaS password in a session variable that the connector reads at runtime.
D
Create an API INTEGRATION for the SaaS endpoint and let the Native App use it for arbitrary outbound HTTPS requests, storing the token in a user-defined function definition.

Show answer and explanation

Correct answer: A

Explanation

The best design is to use EXTERNAL ACCESS INTEGRATION with tightly scoped network rules and SECRET objects. This is the Snowflake-supported approach for allowing Snowflake handlers or application components to call external network locations while enforcing explicit egress controls and proper secret management. It is especially relevant in connector and Native App scenarios where the provider needs a repeatable, secure deployment model across consumer accounts. A common misconception is to use network policies for outbound control; however, network policies govern inbound client connections to Snowflake, not egress from Snowflake code. Another misconception is to use API INTEGRATION for arbitrary outbound calls, but API INTEGRATION serves different integration patterns, such as external functions, and is not the general mechanism for connector-style outbound HTTPS access. Snowflake documentation on external network access, EXTERNAL ACCESS INTEGRATION, network rules, and SECRET objects provides the relevant implementation guidance and best practices.

A. Correct.
Correct. For outbound access from Snowflake code to external services, the recommended pattern is to use EXTERNAL ACCESS INTEGRATION together with network rules and SECRET objects. This design supports controlled egress to approved external endpoints and avoids embedding credentials in code. It also aligns with how Snowflake Native Apps and connector-based solutions can securely manage outbound access in customer environments.
B. Incorrect.
Incorrect. Hard-coding API keys in stored procedures is a poor security practice and does not meet the requirement to avoid embedding secrets in SQL objects. In addition, network policies in Snowflake control client access to Snowflake, not outbound destinations from Snowflake code to external services.
C. Incorrect.
Incorrect. SECURITY INTEGRATION objects are used for authentication/security relationships such as federated auth, OAuth, or external token-related configurations, not for defining outbound network destinations for connector calls. Session variables are also not an appropriate secret-management mechanism for deployable, secure connector architectures.
D. Incorrect.
Incorrect. API INTEGRATION is used for specific integration patterns such as external functions or cloud eventing-related integrations, not as a general-purpose outbound HTTPS mechanism for arbitrary connector traffic from app code. Storing tokens in a UDF definition would also violate the requirement to avoid hard-coded secrets.

ARA-C01 Question 303

Single answerKafka

A retail company streams order events from Apache Kafka into Snowflake for near-real-time analytics. The architecture team wants to minimize custom code, preserve Kafka record metadata for troubleshooting, and ensure offsets are committed only after records are durably written to Snowflake. Which approach best meets these requirements?

A
Use the Snowflake Kafka Connector to write records into a Snowpipe Streaming channel and enable metadata columns so Kafka topic, partition, and offset can be stored with the ingested rows.
B
Configure Kafka Connect to land Avro files in an internal Snowflake stage, then use a scheduled task with COPY INTO to load them and commit Kafka offsets immediately after the files are produced.
C
Use a custom Kafka consumer application that inserts rows with JDBC into Snowflake tables and manually stores offsets in a separate control table after each poll cycle.
D
Use Snowpipe auto-ingest directly from Kafka topics and configure event notifications so Snowflake can subscribe to Kafka offsets.

Show answer and explanation

Correct answer: A

Explanation

For Kafka-to-Snowflake ingestion, the recommended production pattern is to use the Snowflake Kafka Connector rather than build a custom consumer. This reduces operational complexity and aligns with Snowflake best practices for managed ingestion. In modern architectures, the connector can use Snowpipe Streaming to achieve low-latency ingestion without staging files in cloud object storage. The connector is also designed to coordinate ingestion state with Kafka offset commits so that offsets are committed only after records are successfully processed for Snowflake, which helps avoid data loss scenarios. Additionally, preserving Kafka metadata such as topic, partition, and offset is a common design requirement for observability and replay troubleshooting. Snowflake documentation for the Kafka Connector and Snowpipe Streaming describes these capabilities and the recommended architecture for near-real-time ingestion from Kafka.

A. Correct.
Correct. The Snowflake Kafka Connector is the standard integration for streaming Kafka data into Snowflake with minimal custom development. It is designed to coordinate offset management with ingestion so offsets are committed only after data has been successfully processed for Snowflake. When used with Snowpipe Streaming, it supports low-latency ingestion without requiring files in cloud storage. The connector can also expose Kafka metadata such as topic, partition, and offset, which is useful for lineage, replay analysis, and troubleshooting duplicate or missing records.
B. Incorrect.
Incorrect. Kafka Connect does not natively land files in an internal Snowflake stage as a standard Kafka-to-Snowflake pattern, and this approach adds unnecessary batch latency and orchestration complexity. More importantly, committing offsets immediately after file production does not guarantee the data has been durably loaded into Snowflake tables. This breaks the requirement that offsets should only be committed after durable write completion.
C. Incorrect.
Incorrect. A custom JDBC consumer could potentially be built, but it does not minimize custom code and creates operational risk around error handling, retries, idempotency, and offset coordination. This option may appeal to teams wanting full control, but it is not the best architectural choice compared with the supported Snowflake Kafka Connector, which is purpose-built for this integration.
D. Incorrect.
Incorrect. Snowpipe auto-ingest works with files arriving in supported cloud storage through event notifications, not directly from Kafka topics. Snowflake does not subscribe directly to Kafka offsets through Snowpipe auto-ingest. This option reflects a common misconception that Snowpipe can ingest from any event source, when in practice Kafka requires the Snowflake Kafka Connector.

ARA-C01 Question 304

Single answerKafka

A 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.

ARA-C01 Question 305

Single answerSpark

A retail company runs a nightly Spark job on Databricks to transform clickstream data and write the results to Snowflake. The current implementation uses the Spark connector in a single batch at the end of the job. During peak season, the job frequently fails near completion because the Spark cluster autoscaling policy removes executors, causing long-running tasks to be retried and the final write to Snowflake to restart. The architects need a design that improves reliability and write throughput without changing the upstream transformation logic. Which approach should they recommend?

A
Configure the Spark connector to write via an internal stage using parallel data transfer, and repartition the DataFrame before the write so output is distributed across multiple partitions
B
Replace the Snowflake Spark connector with JDBC and increase the JDBC batch size so each executor writes larger INSERT statements directly into Snowflake tables
C
Cache the final DataFrame in Spark memory before writing so that executor loss does not affect the Snowflake load phase
D
Disable autoscaling on the Spark cluster and reduce Snowflake virtual warehouse size so the write operation completes with fewer concurrent connections

Show answer and explanation

Correct answer: A

Explanation

For Spark-to-Snowflake data movement at scale, the recommended architecture is to use the Snowflake Connector for Spark, which is optimized for bulk transfer through staging and COPY-based loading rather than direct row-by-row JDBC inserts. In practice, architects should also ensure that Spark partitioning supports sufficient parallelism for the connector's transfer phase. This is especially important when clusters are elastic or subject to executor churn, because a properly partitioned staged load is generally more robust and performant than a monolithic final write pattern. Snowflake documentation for the Spark connector and bulk loading guidance emphasizes using the native connector for scalable data exchange and leveraging partitioning/parallelism appropriately.

A. Correct.
Correct. The Snowflake Connector for Spark is designed to move data efficiently by unloading/loading through a stage rather than row-by-row JDBC INSERT patterns. Repartitioning the DataFrame can improve parallelism and throughput by producing multiple output partitions for the connector to transfer concurrently. This approach improves resiliency compared with a single narrow write path and aligns with Snowflake best practices for large Spark-to-Snowflake writes.
B. Incorrect.
Incorrect. Using generic JDBC for large-scale Spark writes is typically less efficient and less reliable than the Snowflake Spark connector because JDBC commonly results in row-oriented or small-batch insert behavior. Increasing JDBC batch size may help somewhat, but it does not match the staged bulk-load pattern that the Snowflake connector uses for scalable loads.
C. Incorrect.
Incorrect. Caching the DataFrame may reduce recomputation if tasks are retried, but it does not eliminate the core issue of how data is written to Snowflake or guarantee resilience when executors are removed. Cached data can also be lost when executors are decommissioned, especially if not fully materialized with sufficient replication, so this is not the best architectural fix.
D. Incorrect.
Incorrect. Disabling autoscaling might reduce one source of instability, but it does not address the need for an optimized Snowflake write strategy. Reducing the Snowflake warehouse size would likely hurt load performance, not improve it. The requirement is to improve reliability and throughput without changing upstream logic, and the connector's staged parallel load mechanism is the appropriate recommendation.

Timed practice exam

Take a ARA-C01 practice test under exam conditions

65 questions in 115 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

ARA-C01 practice questions 301 to 400 of 434

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 5 pages of up to 100 questions.