ADA-C01 Question 255
Single answer3.4 Given a scenario, manage tasks.A data engineering team uses a serverless task named LOAD_DAILY_SALES to run every 5 minutes and merge files from a staging table into a reporting table. Over the last week, the task has frequently shown a state of SUSPENDED after several failed runs caused by intermittent source file format issues. The team wants the task to automatically stop after a defined number of consecutive failures, notify operators through monitoring, and then allow an administrator to resume it after the underlying issue is fixed. Which configuration best meets this requirement?
- A
Set SUSPEND_TASK_AFTER_NUM_FAILURES on the task to the desired threshold, monitor TASK_HISTORY / alerts for failures, and use ALTER TASK ... RESUME after the issue is corrected.
- B
Set USER_TASK_TIMEOUT_MS to the desired failure threshold, because it suspends a task after that number of failed runs; then recreate the task to restart it.
- C
Convert the task from serverless to a warehouse-backed task, because only warehouse-backed tasks support automatic suspension after repeated failures.
- D
Set ALLOW_OVERLAPPING_EXECUTION = FALSE, because it prevents task failures from accumulating and keeps the task from being suspended.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to configure SUSPEND_TASK_AFTER_NUM_FAILURES on the task. This task parameter is designed for operational safety: after a specified number of consecutive task failures or timeouts, Snowflake suspends the task automatically. That behavior is useful in production pipelines where repeated failures should stop further runs until an administrator intervenes. After the issue is fixed, the task can be resumed with ALTER TASK ... RESUME. For monitoring, administrators commonly use INFORMATION_SCHEMA.TASK_HISTORY, ACCOUNT_USAGE views, Snowsight, and external alerting integrations to detect task failures and suspensions. By contrast, USER_TASK_TIMEOUT_MS governs run duration before timeout, ALLOW_OVERLAPPING_EXECUTION governs concurrent scheduling behavior for root tasks, and switching between serverless and warehouse-backed execution does not change whether repeated-failure auto-suspension is supported. These behaviors are documented in Snowflake task administration and CREATE/ALTER TASK parameter references.
- A. Correct.
Correct. Snowflake tasks support the SUSPEND_TASK_AFTER_NUM_FAILURES parameter to automatically suspend a standalone task or the root task in a task graph after a specified number of consecutive failed runs or timeouts. Administrators can monitor failures using task history and operational monitoring, then resume the task with ALTER TASK ... RESUME after fixing the root cause. This directly matches the scenario's requirement for automatic stopping after repeated failures and manual restart after remediation.
- B. Incorrect.
Incorrect. USER_TASK_TIMEOUT_MS controls how long a task is allowed to run before timing out; it does not define how many consecutive failures trigger suspension. Also, a suspended task does not need to be recreated to run again; it can be resumed with ALTER TASK ... RESUME. This option confuses execution timeout with failure-count-based suspension.
- C. Incorrect.
Incorrect. Automatic suspension after repeated failures is not limited to warehouse-backed tasks. Serverless tasks also support task parameters such as SUSPEND_TASK_AFTER_NUM_FAILURES. Changing the compute model would not be necessary to satisfy the requirement and would add operational overhead without solving the stated problem.
- D. Incorrect.
Incorrect. ALLOW_OVERLAPPING_EXECUTION controls whether a new run of a root task graph can begin while a prior run is still executing. It is related to concurrency behavior, not failure-threshold-based suspension. While overlapping execution settings can affect scheduling behavior, they do not prevent a task from being suspended after repeated failures.