Google ACE Practice Question: A team runs a Kubernetes CronJob that performs…

Answer analysis

Option-by-option breakdown

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

• ✗

  Set `successfulJobsHistoryLimit: 0` — GKE sends an alert when the history is empty

  Why it's wrong here

  Setting `successfulJobsHistoryLimit: 0` is a garbage-collection tweak, not an alerting mechanism. This field tells the Kubernetes controller how many completed Job objects to retain; when set to 0, completed Jobs are deleted immediately, which actually destroys historical evidence of successful runs and their logs. GKE has no built-in trigger that fires an alert because the history is empty — the cluster simply removes the records without notifying anyone, so you lose visibility instead of gaining an alert.

• ✓

  Create a log-based metric on CronJob failure events in Cloud Logging and an alerting policy on that metric

  Why this is correct

  This is the correct approach because GKE logs Kubernetes events, including CronJob failures (such as a Job exceeding its deadline or failing to be created), to Cloud Logging when cluster logging is enabled. A log-based metric can count only the error-level or failure-related log entries generated by the CronJob controller, and a Cloud Monitoring alerting policy can then respond to that metric crossing a threshold, sending notifications via email, Pub/Sub, or mobile app. Unlike static limits or cluster-wide notifications, this gives you a targeted, rule-based way to detect exactly when a scheduled job fails, making it the standard solution for CronJob observability on GKE.

• ✗

  Set `restartPolicy: Always` on the CronJob's Pod template — it will retry until success

  Why it's wrong here

  For any Job or CronJob pod template, the `restartPolicy` must be `OnFailure` or `Never`; setting it to `Always` is invalid and Kubernetes will reject the pod template, so the CronJob will never run at all. Even if the policy were accepted, `restartPolicy` only controls how the kubelet restarts containers inside the same Pod — it does not notify you when the job ultimately fails, and endless retries can hide a persistent problem while consuming cluster resources. This option is wrong on two counts: it is invalid for the workload type and it would not produce an alert if the job continues to fail.

• ✗

  Enable GKE's built-in CronJob alerting feature in the cluster's Notifications settings

  Why it's wrong here

  GKE Notifications is a cluster-level feature that publishes messages to Pub/Sub for lifecycle and upgrade events such as node pool upgrade completions, cluster autoscaler activity, and security bulletins — not for workload-level resources like CronJobs. The GKE console's Notifications settings let you subscribe to these cluster maintenance and incident categories, but there is no built-in category or toggle specifically for CronJob failures. Consequently, enabling GKE Notifications cannot alert you when a scheduled job fails; you must instead build a custom log-based metric and monitoring alert, as the correct answer describes.

Go deeper

Related to this question