PDE Maintaining and Automating Data Workloads Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Define a direct downstream dependency (loader >> downstream) so Airflow's scheduler marks the downstream task runnable only after the loader task succeeds.

  Why this is correct

  In Airflow, a dependency edge makes the scheduler hold the downstream task until the upstream task reaches a successful terminal state. This is the native, no-polling coordination mechanism inside a single DAG, exactly matching the requirement that the downstream task wait for the load's completion signal without repeatedly querying BigQuery.

• ✗

  Use a task dependency with an ExternalTaskSensor pointed at the loader task's DAG and task ID, configured with the correct execution_delta.

  Why it's wrong here

  ExternalTaskSensor waits on a task in a different DAG, not within the same DAG. Since the loader and downstream task live in the same nightly DAG, this sensor would look for an external DAG and fail or never resolve correctly. Within a single DAG, a plain dependency edge already enforces ordering, so this is the wrong tool for the scenario.

• ✗

  Set the loader task's trigger_rule to all_done and add a dependency edge so the downstream task runs immediately after the loader reaches any terminal state.

  Why it's wrong here

  The all_done trigger rule allows the task to run even when the upstream task failed or was skipped, which is the opposite of the required guarantee. The scenario demands that the downstream task run only after a successful load. Using all_done plus an edge would let the downstream task proceed on failure, corrupting downstream results, so this is incorrect.

• ✗

  Use an XCom to push a completion flag from the loader task and have the downstream task pull it via xcom_pull, combined with a trigger rule of all_success on the dependency edge.

  Why it's wrong here

  XComs only persist small metadata and do not themselves gate scheduling; using xcom_pull still requires the downstream task to already be scheduled. The all_success trigger rule governs whether a task runs based on upstream states, but XComs alone do not create a wait-for-signal coordination pattern here, so this does not reliably sequence the load and the downstream task as described.