DEA-C01 Practice Question 28: Glue Job Failure EventBridge SNS

AWS Glue publishes events to Amazon EventBridge in near real time. Events with "detail-type":"Glue Job State Change" are generated for SUCCEEDED, FAILED, TIMEOUT, and STOPPED, and the documentation lists "notifying an Amazon SNS topic when an ETL job fails" as an example use. A single rule with an event pattern on the source, detail-type, and state covers all twelve jobs, no matter which one fails, and SNS delivers the page. There is no code to maintain and no polling.

Option A does not alert anyone. Continuous logging improves the *diagnosis* of a failure once you know about it, but a human reading logs at standup is the same next-morning discovery the team already has.

Option B only catches errors the script itself raises and survives to handle. A job killed by an out-of-memory condition, a timeout, or an infrastructure failure never reaches the except block, so the marker file is missing exactly when it matters most, and a file in S3 is not a page. It is also twelve scripts to edit and keep in step.

Option C watches the wrong signal. glue.driver.aggregate.numFailedTasks counts failed *Spark tasks*. Spark retries failed tasks, so this metric can be non-zero on a job that ultimately succeeds, and a job that fails at startup or times out may never report it, false alarms in one direction and silence in the other. It also requires a separate alarm per job.

Reference: Automating AWS Glue with EventBridge