DAA-C01 Question 59
Single answerRespond to processing failuresA retail analytics team uses a Snowflake TASK to run every 15 minutes and populate a curated sales summary table from newly landed raw data. On Monday morning, analysts report that the summary table has not been updated since 02:00. You confirm the upstream raw table is still receiving data. The team needs to identify the cause of the failure and resume processing with minimal delay. Which action should the data analyst take FIRST to respond to this processing failure?
- A
Query the TASK_HISTORY for the task to review recent runs, inspect the error message for the failed execution, and then correct the root cause before resuming the task.
- B
Recreate the target summary table from scratch and rerun the entire pipeline, because task failures usually indicate table corruption.
- C
Increase the warehouse size assigned to the task, because a larger warehouse automatically clears failed task states and reprocesses missed runs.
- D
Run SHOW PIPES to determine why the scheduled task stopped, because pipe execution history contains task failure details.
Show answer and explanation
Correct answer: A
Explanation
When responding to a Snowflake processing failure involving a TASK, the best practice is to diagnose before changing infrastructure or rebuilding data structures. Snowflake provides task execution metadata through TASK_HISTORY, which includes run state, scheduled time, query ID, and error information. That evidence lets the analyst determine whether the issue stems from SQL compilation/runtime errors, missing privileges, suspended dependencies, warehouse configuration, or object changes. Only after identifying the cause should the team resume the task and address any missed intervals through backfill logic if needed. This aligns with Snowflake operational best practices for troubleshooting tasks and using system metadata views/functions rather than making speculative changes. Relevant Snowflake documentation includes TASK_HISTORY, task management/monitoring guidance, and Account Usage views for task analysis.
- A. Correct.
Correct. For Snowflake task failures, the appropriate first response is to inspect task execution history and error details using TASK_HISTORY (via the Information Schema table function or Account Usage views, depending on need and retention). This helps identify whether the issue is SQL logic, privileges, object dependencies, warehouse availability, or another runtime problem. After identifying and fixing the root cause, the analyst can resume the task and, if necessary, backfill missed processing.
- B. Incorrect.
Incorrect. Rebuilding the target table is an excessive and unsupported first step. A failed task run does not imply table corruption. In most cases, the failure is due to SQL errors, permissions, missing objects, suspended warehouses, or other operational issues. Recreating downstream objects before diagnosing the failure can increase downtime and risk data inconsistency.
- C. Incorrect.
Incorrect. Scaling the warehouse may help if the error is specifically caused by resource constraints or long-running processing, but it does not automatically clear the failed condition or explain why the task stopped. Snowflake tasks need the underlying issue identified and addressed. Increasing compute first is guesswork and not an appropriate initial troubleshooting step.
- D. Incorrect.
Incorrect. SHOW PIPES and pipe history are relevant to Snowpipe ingestion, not task scheduling and execution. Since the problem statement concerns a scheduled TASK that transforms already landed raw data, pipe metadata will not provide the task error details needed to respond to this failure.