Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
Your team manages a high-traffic microservices application running on Google Kubernetes Engine (GKE) and is introducing automated canary deployments through your CI/CD pipeline.
You have established request-based availability and latency Service-Level Objectives (SLOs) in Cloud Monitoring. During canary rollouts, you need to evaluate the health of the canary version in real time and automatically trigger a deployment rollback if the canary release severely degrades application performance and rapidly depletes your error budget.
Which architectural approach should you implement to satisfy these requirements?
Build a custom dashboard with Metrics Explorer charts, and configure a Cloud Monitoring snooze schedule during the canary deployment window.
Configure a scheduled BigQuery query to run every 12 hours against exported Cloud Logging tables, and invoke an App Engine task to revert the deployment when error counts increase.
Create a metric-absence alerting policy on the HTTP request count metric with an incident duration of 60 minutes, and send an email notification to the on-call DevOps engineer.
Configure an SLO burn-rate alerting policy with a short lookback period to detect fast-burn conditions on the canary service, and attach a Cloud Pub/Sub notification channel that triggers an automated rollback service.
Build a custom dashboard with Metrics Explorer charts, and configure a Cloud Monitoring snooze schedule during the canary deployment window.
Configure a scheduled BigQuery query to run every 12 hours against exported Cloud Logging tables, and invoke an App Engine task to revert the deployment when error counts increase.
Create a metric-absence alerting policy on the HTTP request count metric with an incident duration of 60 minutes, and send an email notification to the on-call DevOps engineer.
Configure an SLO burn-rate alerting policy with a short lookback period to detect fast-burn conditions on the canary service, and attach a Cloud Pub/Sub notification channel that triggers an automated rollback service.
An SLO burn-rate alerting policy tracks how rapidly a service is consuming its allotted error budget over a specific evaluation window. In Google Cloud Observability, Cloud Monitoring allows you to define request-based Service-Level Indicators (SLIs) and objectives (SLOs) for microservices. When combined with a Cloud Pub/Sub notification channel, alerting policies can publish structured incident messages to message topics, allowing decoupled event-driven automation (such as Cloud Functions, Cloud Run, or CI/CD webhooks) to consume the event and execute remediation actions like rolling back a canary release.
Using Cloud Monitoring's native SLO burn-rate engine with a Pub/Sub notification channel is the Google SRE-recommended pattern. It avoids the latency of batch log queries, eliminates manual alert triaging, and directly ties deployment stability to business-critical reliability targets.