Optimizing SLO Balance Between Reliability and Velocity

PCDOE By islever Editorial Last updated

Balancing change, velocity, and reliability of the service.

Short answer

BC When a service consistently meets its SLO, you should increase deployment velocity/risk and shift engineering time to less reliable services.

Question

You support a service with a well-defined Service Level Objective (SLO). Over the previous 6 months, your service has consistently met its SLO and customer
satisfaction has been consistently high. Most of your service's operations tasks are automated and few repetitive tasks occur frequently. You want to optimize the
balance between reliability and deployment velocity while following site reliability engineering best practices. What should you do? (Choose two.)
  1. Make the serviceג€™s SLO more strict.
  2. Increase the serviceג€™s deployment velocity and/or risk. Correct Answer
  3. Shift engineering time to other services that need more reliability. Correct Answer
  4. Get the product team to prioritize reliability work over new features.
  5. Change the implementation of your Service Level Indicators (SLIs) to increase coverage.

Key Takeaways

The core concept tested is the SRE SLO Decision Matrix, which dictates that services meeting their SLOs should shift resources away from reliability work to enable higher velocity or address less mature services.

This question addresses how to manage the trade-off between service reliability and deployment velocity when a service is already performing well against its Service Level Objectives (SLOs). It establishes that high reliability allows teams to increase risk and focus on other areas.

Common mistake: Many learners incorrectly choose options related to tightening SLOs (A) or improving SLI coverage (E), failing to recognize that these actions are unnecessary when the service is already stable and reliable.

Expert Analysis

Why the Answer Is Correct

According to Google's Site Reliability Engineering (SRE) principles, specifically the SLO Decision Matrix, when a service consistently meets its SLOs and customer satisfaction is high, the team has "earned" the right to increase deployment velocity or take on more risk. Simultaneously, since the service is stable, engineering time should be shifted to other services that are less reliable and need more attention, optimizing overall organizational reliability.

Why the Other Options Are Wrong

Option A is incorrect because making the SLO stricter without a business need can stifle innovation unnecessarily. Option D is wrong because prioritizing reliability over features for an already stable service is inefficient use of resources. Option E is incorrect because changing SLIs implies the current measurement is flawed, but the prompt states the SLO is well-defined and met.

Community Comment Notes

The majority of the community, including highly-rated comments, identified B and C as the correct answers. One user provided a direct link to the official SRE workbook's SLO decision matrix to validate this choice. Another commenter initially suggested different options but later aligned with the consensus after reviewing the material, highlighting the importance of understanding the specific SLO matrix framework.

Official Reference

https://sre.google/workbook/implementing-slos/#slo-decision-matrix

This link opens the official vendor documentation in a new tab.

Exam Strategy

When analyzing SLO-related questions, always look for keywords like 'consistently met' or 'high satisfaction.' If the service is healthy, the answer usually involves increasing velocity/risk or moving resources to unstable services. Avoid options that suggest fixing what isn't broken.

Frequently Asked Questions

Why not tighten the SLO if the service is doing well?

Tightening the SLO (Option A) increases the cost of reliability without clear business benefit. The SRE framework suggests using stability to enable speed elsewhere.

What does the SLO Decision Matrix recommend for stable services?

It recommends treating reliability as a solved problem, allowing teams to increase release frequency or reduce reliability efforts to help other struggling services.

More PCDOE FAQ →

Discussion 20 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 20

  1. NXD 👍 24
    BC https://sre.google/workbook/implementing-slos/#slo-decision-matrix A: wrong – SLO is already well-defined, customer satisfaction is high. E: wrong – change SLI means how SLO, which is already well-defined. CD are valid, but the best option is C because current product is already quite reliable.
  2. TNT87 👍 6
    These are the correct answers. Thank me later. All the best guys
  3. zygomar 👍 4
    as NXD 's link shows (https://sre.google/workbook/implementing-slos/#slo-decision-matrix) answer is B C. See link.
  4. FunkyB 👍 3
    NXD, thank you for posting the link. The answer is explicitly stated in the post. The SLO matrix listed there is also great for future use cases. I personally love reading the discussions and posts to fully understand the concepts and services. Thanks again.
  5. TNT87 👍 3
    After perusing the SRE book... D, E Is correct, there is a question that is almost this very question but the wording is different
Show 15 more comments
  1. MF2C 👍 3
    yes B and C
  2. Alaaelanwr 👍 3
    i think BC
  3. Sekierer 👍 3
    B and C
  4. Rupo7 👍 2
    As mentioned by others, we can see in the SRE book table here https://sre.google/workbook/implementing-slos/#slo-decision-matrix that when: SLO=Met Toil=Low Customer Satisfaction=High then: Choose to (a) relax release and deployment processes and increase velocity, or (b) step back from the engagement and focus engineering time on services that need more reliability. This matches only B and C.
  5. giammydell 👍 2
    I think B and E: A No: SLO is well defined B YES: the service met the SLO so you have error budget available for DEPLOY C I think NO, you will reduce your team number D NO higher reliability is unnecessary (SLO well defined) E YES you can modify SLI to extend coverage
  6. Shasha1 👍 2
    i think CD are correct regarding E i am not sure we can modify SLI after we defined
  7. shefalia 👍 2
    This was asked on (12/24/22), passed the exam . I opted for B & E
  8. thewalker 👍 1
    B. Increase the service's deployment velocity and/or risk. With the current high reliability and consistent SLO adherence, you have room to increase the deployment velocity. This means you can deploy updates and new features more frequently, which can help in rapidly delivering value to your customers and staying competitive. As long as you monitor the impact on your SLO and maintain your reliability standards, this approach can optimize both reliability and deployment velocity. C. Shift engineering time to other services that need more reliability. Since your current service is already stable and meeting its SLOs, you can allocate some of the engineering resources to other services that might be struggling with reliability. This will help improve the overall reliability of your organization's services and make better use of your engineering talent.
  9. BlackCoffee 👍 1
    The two correct answers are B and C. E is incorrect because there is no indication that the current SLIs are failing to reflect user happiness, as customer satisfaction is already consistently high. Changing them is unnecessary.
  10. TNT87 👍 1
    B C, ,,,, D; E Are for the previous question, number 80
  11. aswani 👍 1
    Are the questions still relavant?
  12. TNT87 👍 1
    Ans C; D are correct.
  13. TNT87 👍 1
    its a mistake here
  14. dobby_elf 👍 1
    letter B and C
  15. LaxmanTiwari 👍 1
    Agree with BC

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Binary Authorization Attestor Implementation

S-grade

GKE Cluster and Namespace Design for Data Isolation

S-grade

Granting Log Export Permissions in Google Cloud

S-grade

Minimizing GKE Logging Costs with SYSTEM Mode

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide