SnowPro Advanced: Data Engineer free question 3 / 10 · Domain 1: Data Movement
An external application submits INSERT statements through the Snowflake SQL API. A network disconnection sometimes leaves no response, so it is unclear whether a statement ran. You want to resubmit without inserting rows twice, while avoiding extra load on normal request handling. Which usage matches the official documentation?
- Send the first request without a requestId, and attach a UUID requestId and retry=true only when resubmitting
- Attach requestId and retry=true to every request from the start, and resubmit repeatedly with the same URL
- Resubmit with the same requestId, and Snowflake matches the already executed statement even without retry=true
- Send the first request with only a UUID requestId, and attach retry=true only when resubmitting with the same requestId
Show the answer and explanation
Answer: D
Why this is correct
In the SQL API, you attach a requestId to the first request, and when you resubmit with the same requestId and retry=true, Snowflake does not execute the statement again if it was already executed successfully by the first request. Generate a UUID to use as the requestId. Because retry=true makes Snowflake search the statement history for a matching statement, which adds load, the documentation says to attach it only when a resubmission is needed.
Why the other options are wrong
"Attach requestId and retry=true to every request from the start, and resubmit repeatedly with the same URL" … retry=true searches the statement history for the same statement, which adds processing load. The documentation says to attach it only when you need to resubmit.
"Send the first request without a requestId, and attach a UUID requestId and retry=true only when resubmitting" … To prevent double execution, the first request and the resubmission must carry the same requestId. If the first request has no ID, there is nothing to match the resubmission against.
"Resubmit with the same requestId, and Snowflake matches the already executed statement even without retry=true" … The documentation says you must specify retry=true in addition to the requestId. The ID alone is not treated as a resubmission.
Related setting
When the server is receiving many requests, it can return HTTP 429. The documentation recommends wrapping concurrent requests in retry handling. Retrying on 429 and using retry=true when you do not know whether a statement ran are separate matters.