PDE Maintaining and Automating Data Workloads Practice Question

Your organization runs a Cloud Composer (Apache Airflow) environment that executes a DAG every night to move data from Cloud Storage into BigQuery. The DAG has been succeeding for months, but last week the nightly load silently produced a BigQuery table with zero rows while the Airflow task still reported success. You need to add a safeguard that fails the DAG task whenever the loaded row count is zero before downstream tasks run. What should you do?

⚠ Common exam trap

The trap here is assuming that any task marked successful in Airflow implies the underlying data operation was semantically correct, when success only reflects that the operator did not raise an exception.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add a BigQueryCheckOperator task immediately after the load task that asserts the target table row count is greater than zero.

The failure mode is a task that reports success while producing an empty result set, so the safeguard must inspect the data itself and raise a task-level failure. A BigQueryCheckOperator performs exactly that assertion and integrates with Airflow's dependency graph, which prevents downstream tasks from consuming invalid output and triggers configured alerting.

Answer analysis

Option-by-option breakdown

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

✗
Increase the retries parameter on the load task so transient issues that produce zero rows are automatically retried.
Why it's wrong here
Retries only re-run the same task after a failure; a task that returns success with zero rows will never trigger a retry. The scenario describes a silent success, not a transient error, so adding retries changes nothing about detection. Retries also cannot inspect the destination table contents to decide whether the load was semantically valid.
✓
Add a BigQueryCheckOperator task immediately after the load task that asserts the target table row count is greater than zero.
Why this is correct
The BigQueryCheckOperator runs a SQL statement and fails the task when the returned result does not match the expected condition. Placing it right after the load task means a zero-row result raises an Airflow task failure, stopping downstream tasks and surfacing the problem through the normal DAG alerting path instead of silently completing.
✗
Enable Cloud Logging export for the Composer environment and create a log-based alert that matches error text from the load operator.
Why it's wrong here
The load operator logged no error, because it succeeded. A log-based alert keyed to error text will never match, so the empty table goes undetected. Even if a pattern were found, the alert would be a monitoring notification rather than an in-DAG gate that stops dependent tasks from running against bad data.
✗
Configure an Airflow SLA on the load task so that a missed deadline raises an alert about the empty table.
Why it's wrong here
An SLA fires when a task does not finish within a duration you specify, which is a timeliness signal, not a data-quality signal. A load that finishes quickly with zero rows would still satisfy any SLA. SLA misses also do not fail the task or block downstream work, so the empty table would continue to propagate through the pipeline.

Go deeper

PDE Maintaining and Automating Data Workloads Practice Question

Why each option matters

Option-by-option breakdown

Related to this question