ADA-C01 Question 259
Single answerManage and schedule tasksA data platform team uses a Snowflake task graph to orchestrate nightly processing. The root task loads raw data at 01:00 UTC, and three child tasks transform and validate the data using AFTER dependencies. Recently, the root task occasionally runs longer than expected, causing a second scheduled run to start before the prior graph has fully completed. This creates duplicate processing in downstream systems. The administrator needs to ensure that a new scheduled run of the root task does not start if the previous graph run is still active, while keeping the existing task graph design. Which configuration change should the administrator make?
- A
Set ALLOW_OVERLAPPING_EXECUTION = FALSE on the root task
- B
Set SUSPEND_TASK_AFTER_NUM_FAILURES = 1 on each child task
- C
Convert the child tasks to standalone scheduled tasks with the same CRON expression as the root task
- D
Increase the warehouse size used by the child tasks so the graph completes faster
Show answer and explanation
Correct answer: A
Explanation
Snowflake task graphs commonly use a scheduled root task with child tasks defined through AFTER dependencies. When the root task is scheduled more frequently than the graph can reliably complete, overlapping executions can occur unless explicitly controlled. The correct administrative setting is ALLOW_OVERLAPPING_EXECUTION on the root task. Setting this to FALSE ensures the next scheduled graph run is skipped if the prior run has not finished yet. This is the appropriate solution when the goal is to preserve the existing task graph structure and avoid duplicate downstream effects. By contrast, SUSPEND_TASK_AFTER_NUM_FAILURES is for failure-based suspension, not concurrency control. Replacing dependent child tasks with separately scheduled tasks weakens orchestration and does not solve the core issue. Performance tuning, such as resizing warehouses, may help reduce run time but is not a deterministic control for scheduling overlap. This aligns with Snowflake documentation and best practices for managing task graphs and scheduled execution behavior.
- A. Correct.
Correct. For a standalone root task or the root of a task graph, ALLOW_OVERLAPPING_EXECUTION controls whether a new instance of the scheduled task graph can begin while a previous run is still executing. Setting it to FALSE prevents overlapping graph runs, which directly addresses the duplicate-processing problem without redesigning the graph.
- B. Incorrect.
Incorrect. SUSPEND_TASK_AFTER_NUM_FAILURES controls automatic suspension after repeated task failures. It does not prevent overlapping scheduled executions of a task graph. Someone might choose this if they confuse execution overlap with retry or failure-handling behavior.
- C. Incorrect.
Incorrect. Converting child tasks to separate scheduled tasks would remove the dependency-based orchestration provided by AFTER and could actually make coordination harder. It also would not inherently prevent overlap between full processing cycles unless additional controls were added.
- D. Incorrect.
Incorrect. Increasing warehouse size may reduce runtime, but it does not guarantee that overlapping executions will not occur. The requirement is to ensure a new run does not start while a previous graph run is active; that is a task configuration issue, not just a performance-tuning issue.