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.

• ✗

  Create an uptime check against the Airflow web server URL and alert when the HTTP response is not 200.

  Why it's wrong here

  An uptime check only verifies that the Airflow UI is reachable. It says nothing about whether DAG runs are failing or tasks are retrying, since a healthy web server can front a scheduler that is producing failures. This is an availability signal for the interface, not a workload health signal.

• ✗

  Enable Cloud Audit Logs for the Composer API and alert when any environment update method is called.

  Why it's wrong here

  Audit Logs capture administrative actions such as creating or updating environments, not the runtime success or failure of DAG runs. Alerting on environment update calls would notify on configuration changes, which is unrelated to detecting failed DAG runs or stuck tasks. It monitors control-plane activity rather than data-plane execution.

• ✗

  Create a Monitoring alerting policy on the composer.googleapis.com/environment/healthy metric and notify when it drops below the threshold.

  Why it's wrong here

  The environment health metric reflects whether the Composer environment's own components are running, not whether individual DAG runs succeeded. A DAG can fail repeatedly while the environment stays perfectly healthy, so this policy would stay silent during the exact failure you need to catch. It answers a different question about infrastructure availability.

• ✓

  Create a Monitoring alerting policy on the airflow task instance duration or retry-related metric exposed through Cloud Monitoring for the environment.

  Why this is correct

  Composer exposes Airflow metrics such as task instance duration and retry counts to Cloud Monitoring. An alerting policy on those metrics can detect a task whose runtime or retry behaviour exceeds a normal threshold, which is exactly the stuck-retrying condition described. It complements the failure alert by catching slow degradation before hard failure.

• ✓

  Create a log-based alerting policy on the Composer airflow logs that matches the DAG run failure log entry and notifies the on-call channel.

  Why this is correct

  Composer writes Airflow task and DAG state transitions into Cloud Logging, so a log-based alerting policy can match the failure entry and fire a notification. This is the standard way to alert on DAG run failures because Airflow emits structured log lines for those events, and the policy can be scoped to specific environments or DAG IDs to reduce noise.

Go deeper

Related to this question