DAA-C01 Question 57
Single answerSchedulingA retail analytics team uses a dynamic table to maintain a near-real-time sales summary for dashboards. They also run a scheduled task every morning at 6:00 AM to export a point-in-time snapshot of that summary to a downstream reporting table. Recently, the 6:00 AM export occasionally captures stale data because the dynamic table refresh has not completed yet. The team needs a solution that ensures the export runs only after the dynamic table has been refreshed, while still minimizing unnecessary compute usage and operational complexity. Which approach should they implement?
- A
Replace the scheduled task with a triggered task that uses the dynamic table as the source object, so the export task runs after changes are detected.
- B
Create a task graph where the export task runs AFTER a root task that refreshes the dynamic table, and schedule only the root task.
- C
Increase the warehouse size used by the export task, so the snapshot query finishes fast enough to avoid stale results.
- D
Change the dynamic table TARGET_LAG to DOWNSTREAM, so the 6:00 AM scheduled export automatically waits for the refresh to complete.
Show answer and explanation
Correct answer: B
Explanation
The key requirement is dependency-aware scheduling: the export must occur only after the dynamic table refresh completes. In Snowflake, this is best handled by task orchestration using a task graph, where one task depends on another via the AFTER clause. Scheduling only the root task centralizes control and avoids race conditions that can occur when two independent schedules happen to overlap. This is preferable to trying to solve the issue by changing compute size or relying on freshness settings that do not control task execution order. Snowflake documentation and best practices for tasks emphasize using task graphs for ordered pipelines and dependencies, while dynamic tables are designed for automated data maintenance rather than directly orchestrating downstream task execution.
- A. Incorrect.
Incorrect. Triggered tasks are activated based on change tracking through streams or event-based mechanisms, not by directly using a dynamic table itself as a trigger source. A dynamic table is automatically maintained by Snowflake according to its refresh configuration, but it is not a task trigger object in the way a stream is used for triggered execution. This option reflects a common misconception that any changing object can directly trigger a task.
- B. Correct.
Correct. A task graph is the most appropriate pattern here. The team can schedule a root task and have it explicitly refresh the dynamic table, then define the export task with an AFTER dependency so it runs only after the refresh step completes successfully. This aligns execution order with business requirements, reduces timing uncertainty compared with two independent schedules, and avoids unnecessary warehouse usage caused by repeated polling or overprovisioning.
- C. Incorrect.
Incorrect. Increasing the warehouse size for the export task may make the export query run faster, but it does nothing to guarantee that the dynamic table has already been refreshed before the export starts. The problem is dependency and orchestration, not export query performance. This is a plausible but incorrect operational response.
- D. Incorrect.
Incorrect. Setting a dynamic table's TARGET_LAG to DOWNSTREAM changes how freshness is coordinated relative to downstream dynamic tables, but it does not make an independently scheduled task wait for refresh completion. Tasks and dynamic table refreshes are separate scheduling mechanisms unless explicitly orchestrated. This option confuses dynamic table freshness semantics with task dependency management.