Google Professional Cloud DevOps Engineer Question 97
Single answerGoogle Cloud PlatformYour team is responsible for maintaining a critical microservice running on Google Kubernetes Engine (GKE). The service has an agreed Service Level Objective (SLO) of 99.9% availability, which equates to an error budget of 43.2 minutes of downtime per month. Recently, the service experienced a series of outages that consumed 35 minutes of the error budget. A new feature deployment is planned for next week, but there is concern about the remaining error budget. What is the best action your team should take?
- A
Proceed with the feature deployment as planned, but increase monitoring to catch issues quickly.
- B
Delay the feature deployment and focus on improving system reliability to restore the error budget.
- C
Reduce the SLO target to increase the allowable error budget for the current month.
- D
Proceed with the deployment but roll it back immediately if any new errors occur.
Show answer and explanation
Correct answer: B
Explanation
An error budget is a tool that balances innovation and reliability. When most of the error budget has been consumed, it is a signal to prioritize reliability over new changes. In this scenario, delaying the feature deployment helps prevent further outages and maintains service reliability within the agreed SLO.
- A. Incorrect.
This option does not address the risk of further consuming the error budget, which could lead to breaching the SLO. While monitoring is important, it does not directly mitigate the risk of deployment failures.
- B. Correct.
This is the correct answer. When a significant portion of the error budget has been consumed, delaying non-critical changes like feature deployments is best practice. Focusing on reliability ensures the service remains within its SLO.
- C. Incorrect.
Lowering the SLO target is not a viable solution as SLOs are agreements with stakeholders. Changing them arbitrarily undermines trust and the purpose of the error budget.
- D. Incorrect.
Although rolling back might mitigate issues after the fact, it still introduces risk. With limited error budget remaining, avoiding the deployment altogether is a more prudent approach.