Exam Professional Cloud DevOps Engineer topic 1 question 80 discussion

I would go for B+D: -A: no, there's no reason to add capacity if we are barely scratching error budget; -B: everything seems fine, so it's ok to dare with more innovative/risky releases; -C: no, stakeholders said SLO is ok; -D: adding additional SLIs (and so SLOs) might be a way to reflect observer reliability more closely; -E: put the servers down for no reason is a no-no.

I vote for D+E if you read "The Global Chubby Planned Outage" https://sre.google/sre-book/service-level-objectives/

Option B and D

BE is correct

B is correct because when you dont use your error budget you can increase the release frequency. In the question it even mentions "balancing velocity, reliability, and business needs". The balance here can shift from reliability to velocity and business needs. D is correct as multiple other users already mentioned because of: "The Global Chubby Planned Outage" https://sre.google/sre-book/service-level-objectives/

I will go with D and E. Option B sounds good, but introducing new changes could add errors, that do not match the current objectives "You want your application's SLO to more closely reflect its observed reliability. " A doesn't make sense. C neither, because the SLO has been reviewed and its ok.

B and E: A. not relevant B. Yes because we have a lot of budget. Risky isn't necessary a negative word in SRE because what we learn from SRE is to embrace risk and failure. C. SLO is set appropriately they say. D. adding more SLI doesn't necessarily help. E. SRE practice suggest that we can have planned downtime.

This was asked on (12/24/22), passed the exam . I opted for D & E

B and E. When you only consume 5% of your error budget consistently it means that you can take more risk by releasing features more often (B) and/or bring down service to set user expectation close to SLO (and business has confirmed that this SLO is appropriate)

B+E B because this if you constantly have a lot of spare error budgets it is an indication that you are not taking enough risk ie releasing new features. And you are ultimately depriving the users of new functionalities by being too cautious. E: Everyone agrees on E as it was mentioned in the SRE book as part of the The Global Chubby Planned Outage Re: why not D) The review indicated that the existing SLOs are good. So adding more SLIs not useful here plus does nothing to the user perceived reliability.

DE - You want your application's SLO to more closely reflect its observed reliability.

B & D are correct.

D+E You want the application's SLO to more closely reflect it's observed reliability. The key here is error budget never goes over 5%. This means they can have additional downtime and still stay within their budget. E is correct as per Google SRE handbook (https://sre.google/sre-book/service-level-objectives/) 'You can avoid over-dependence by deliberately taking the system offline occasionally (Google’s Chubby service introduced planned outages in response to being overly available)' D is a good answer because with more SLI's, this may more accurately reflect the system's reliability. A is wrong because adding more serving capacity would make the system even more available. C is wrong because: The question states 'The SLO is set appropriately'.

chekc link from Sekierer for why E is valid (https://sre.google/sre-book/service-level-objectives/) Then D is logical as well.

B - You can increase the frequency of your releases and take higher risks as you have never exceeded your error budget. E - Planned downtime to use some of your error budget will help to make sure end users don’t get use a higher availability of your service.

https://cloud.google.com/blog/products/management-tools/sre-error-budgets-and-maintenance-windows This is the link to the answers of this question

These are the correct choices