Your team manages critical Compute Engine workloads where unexpected storage and memory exhaustion can cause application downtime. You need to implement a proactive incident management workflow in Cloud Monitoring that satisfies the following requirements: Predicts threshold violations for constrained resources at least 12 hours before they occur. Prevents false-positive incidents caused by momentary utilization spikes. Integrates context into incident notifications by providing severity categorization and direct links to internal troubleshooting runbooks. Which configuration should you implement in Cloud Monitoring?

Create a forecasted metric-value alerting policy with a 12-hour forecast window, configure a retest window under advanced options, attach custom policy user labels for severity, and embed playbook links with markdown variables in the documentation section.: ### What a forecasted metric-value alerting policy is A **forecasted metric-value alerting policy** in Cloud Monitoring uses predictive decision algorithms trained on historical time-series data to evaluate whether a metric will violate a specified threshold within a future time window (the forecast window). ### How it meets the requirements - **Predicts threshold violations 12 hours in advance**: Setting the **forecast window** to 12 hours allows Cloud Monitoring to predict future exhaustion of constrained resources (such as disk space or memory) up to 12 hours ahead, providing the operations team ample lead time for remediation. - **Prevents false-positive incidents from momentary spikes**: Configuring a **retest window** (e.g., 10 to 15 minutes) under advanced options ensures that an alert condition is met only when forecasts consistently predict a threshold violation across the entire retest period, filtering out transient spikes. - **Integrates context and severity**: Adding **policy user labels** (e.g., `severity: critical`) annotates incidents for proper upstream routing in incident management systems, while including markdown-formatted playbook links and documentation variables (`${metric.display_name}`, `${resource.name}`) directly delivers actionable remediation context to on-call engineers. ### Key advantages - **Proactive capacity planning**: Generates alerts before resource exhaustion causes service degradation. - **Customizable notification documentation**: Supports Markdown and dynamic variables for streamlined triage. - **Noise reduction**: Uses retest windows and algorithm training to filter transient anomalies.

Cloud Monitoring Forecasted Alerting Policy Workflow | Professional Cloud DevOps Engineer

Cloud Monitoring Forecasted Alerting Policy Workflow

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your team manages critical Compute Engine workloads where unexpected storage and memory exhaustion can cause application downtime. You need to implement a proactive incident management workflow in Cloud Monitoring that satisfies the following requirements:

Predicts threshold violations for constrained resources at least 12 hours before they occur.
Prevents false-positive incidents caused by momentary utilization spikes.
Integrates context into incident notifications by providing severity categorization and direct links to internal troubleshooting runbooks.

Which configuration should you implement in Cloud Monitoring?

Create a metric-absence alerting policy with a trigger duration of 12 hours, set the auto-close duration to 30 minutes, and configure Cloud Logging export sinks to BigQuery.

Create a forecasted metric-value alerting policy with a 12-hour forecast window, configure a retest window under advanced options, attach custom policy user labels for severity, and embed playbook links with markdown variables in the documentation section.

Create a standard metric-threshold alerting policy configured with 'Missing data points treated as values that violate the policy condition' and add a custom notification subject line.

Configure an alerting policy snooze with a 12-hour recurring schedule, set evaluation of missing data to inactive, and assign the Monitoring Cloud Console Incident Editor role to the responder group.

Professional Cloud DevOps Engineer

Cloud Monitoring Forecasted Alerting Policy Workflow

Related questions