A DevOps team manages a tier-1 microservices platform on Google Cloud and uses Google Cloud Monitoring for observability. The team is integrating their alerting infrastructure with PagerDuty and Rootly to automate incident response workflows. They have the following operational requirements: Critical infrastructure and latency alerts must immediately trigger high-urgency escalation policies to page on-call engineers. Warning-level and informational alerts must route to non-paging triage schedules. Incidents in the incident response platform must automatically resolve when the underlying metric condition returns to normal within Google Cloud Monitoring. How should the team configure Google Cloud Monitoring and the incident response platform to achieve this lifecycle integration?

Create distinct notification channels in Cloud Monitoring for each service level using corresponding integration routing keys, map these channels to alerting policies based on severity, and rely on Cloud Monitoring's native incident state notifications for automatic resolution.: ### What the Native Incident Response Integration Is Native integration between **Google Cloud Monitoring** and incident management platforms like **PagerDuty** or **Rootly** connects alerting policies directly to external incident response services. By utilizing **service-specific integration keys (routing keys)**, Cloud Monitoring dispatches incident lifecycle events—including triggers, acknowledgments, and resolutions—directly into the incident platform. ### How It Meets the Requirements - **Severity and Escalation Policy Mapping**: By provisioning separate **PagerDuty/Rootly notification channels** in Google Cloud Monitoring corresponding to distinct service integration keys, administrators can assign different channels to policies. High-severity alerting policies are mapped to high-urgency services with aggressive **escalation policies**, while warning policies route to low-urgency schedules. - **Automated Incident Lifecycle Synchronization**: When an alerting policy condition is violated, Cloud Monitoring sends an incident trigger with a unique **incident identifier (deduplication key)**. When the metric returns below the threshold and the condition clears, Cloud Monitoring automatically transmits a **resolve payload**, seamlessly closing the incident in PagerDuty or Rootly. ### Key Advantages and Capabilities - **Granular Routing**: Enables fine-grained routing of alerts based on service tier, environment, or severity. - **Automated State Tracking**: Eliminates manual alert clearing and prevents notification fatigue by syncing incident states bidirectionally. - **Contextual Enrichment**: Passes policy labels, metric values, and runbook documentation directly to incident responders. - **Native Maintenance**: Requires no intermediary compute infrastructure (such as Cloud Functions or custom proxies), minimizing operational complexity. ### Why This Is Optimal This approach leverages native platform capabilities to maintain strict synchronization between metric states and incident tickets while upholding least-privilege service routing and automated incident clearance.

Cloud Monitoring Pagerduty Severity Lifecycle Integration | Professional Cloud DevOps Engineer

Cloud Monitoring Pagerduty Severity Lifecycle Integration

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.

A DevOps team manages a tier-1 microservices platform on Google Cloud and uses Google Cloud Monitoring for observability. The team is integrating their alerting infrastructure with PagerDuty and Rootly to automate incident response workflows.

They have the following operational requirements:

Critical infrastructure and latency alerts must immediately trigger high-urgency escalation policies to page on-call engineers.
Warning-level and informational alerts must route to non-paging triage schedules.
Incidents in the incident response platform must automatically resolve when the underlying metric condition returns to normal within Google Cloud Monitoring.

How should the team configure Google Cloud Monitoring and the incident response platform to achieve this lifecycle integration?

Create distinct notification channels in Cloud Monitoring for each service level using corresponding integration routing keys, map these channels to alerting policies based on severity, and rely on Cloud Monitoring's native incident state notifications for automatic resolution.

Configure a single global Webhook notification channel pointing to a generic REST endpoint, write a custom middleware to filter severity, and disable auto-close settings in Cloud Monitoring to force manual engineer acknowledgment.

Configure an Account API User Token across all Cloud Monitoring notification channels and use alerting policy user labels to dynamically override external escalation rules at trigger time.

Configure Cloud Monitoring to send alerts to a Pub/Sub topic and schedule a Cloud Task to batch process and escalate incidents every 15 minutes based on cumulative error count.

Professional Cloud DevOps Engineer

Cloud Monitoring Pagerduty Severity Lifecycle Integration

Related questions