Exercise · 23 tasks · about 15 minutes
DevOps vs SRE vs platform engineering: test yourself¶
Sort 23 real tasks into DevOps practice, SRE, platform team or shared, then check your score. Every answer comes with a short reason and its source.
Prefer paper? Download the worksheet (PDF, one page).
The exercise for my video DevOps vs SRE vs Platform Engineering: Who Does What?
Sort each task into one of four
a habit the whole team follows
site reliability engineers
the team that builds self-service tools for the company’s own developers
it depends on the company
The key shows the usual split described by Google’s SRE books, the CNCF (the foundation that hosts Kubernetes) and DORA (Google Cloud’s research program on software delivery). Your company may differ.
The 23 tasks¶
Pick your answer, then click the task to check it. Every answer comes with a short reason and its source.
1. Merge your code into the team’s shared main copy at least once a day, with automated tests running every time.
DevOps practice. Continuous integration is a habit every developer follows, not a separate job.
Source: DORA: continuous integration
2. Ship one small change at a time instead of a big release every few months.
DevOps practice. Small changes get feedback sooner, so problems are easier to find and fix. The whole team works this way.
Source: DORA: working in small batches
3. Build a “new service” starter template, so every team starts with tests, a pipeline, logs and alerts already set up.
Platform team. Golden-path templates are the platform team’s product.
Sources: CNCF platforms white paper, a Duolingo platform engineer job posting
4. Wake a human only when users are actually hurt (errors or slowness), not every time one server is busy.
SRE. Alert on what users feel, because paging a person is expensive.
Sources: Google SRE book: monitoring distributed systems, GitLab’s SRE job description
5. Maintain the shared build-and-deploy pipeline (CI/CD) that turns a code change into a running release.
Shared. Experian lists it in a DevOps engineer job, Duolingo in a platform engineer job. At Google, it’s a separate job: release engineering.
Sources: Google SRE book: release engineering, job postings from Experian and Duolingo
6. Let low-risk changes go live after a colleague’s review and automated checks, instead of waiting for a weekly approval meeting.
DevOps practice. DORA found that change approvals work best as peer review plus automation, not a separate approval board. It’s how the whole organization ships.
7. Give developers a button or command that creates a database in minutes, without filing a ticket.
Platform team. Self-service tools replace ticket queues. DORA calls the opposite the “ticket-ops” trap.
Sources: CNCF platforms white paper, DORA: platform engineering
8. Review a new service before it launches: is it monitored, and can it survive a traffic spike?
SRE. At Google, a team inside SRE runs launch reviews before new products go live. SRE job postings at Google and Duolingo list them too.
Sources: Google SRE book: reliable product launches at scale, job postings from Google and Duolingo
9. Interview developers about what slows them down, then plan the platform’s roadmap from their answers.
Platform team. Platform teams treat developers as customers and research what they need.
Sources: CNCF platforms white paper, DORA: platform engineering
10. Write code that creates the company’s cloud servers and networks (“infrastructure as code”).
Shared. AWS lists it among DevOps practices, but unlike continuous integration (task 1), it’s a skill some people have, not a habit the whole team follows. Platform and SRE jobs ask for it too, so who writes it depends on the company.
Sources: AWS: what is DevOps?, GitLab’s SRE job description, a Twilio platform engineering job posting
11. Run the developer portal: one web page that lists every service, who owns it, and its docs.
Platform team. A web portal is one of the interfaces a platform team owns.
Source: CNCF platforms white paper
12. Lead the response while checkout is failing: decide who does what and keep everyone updated.
SRE. Emergency response and incident response are named SRE duties.
Sources: Google SRE book: introduction, Google SRE book: managing incidents, a Google SRE job posting
13. Roll back the change that broke checkout, to stop the damage before digging for the cause.
Shared. Google’s SRE book says to stop the damage before looking for the cause. But unlike leading the response (task 12), the rollback is done by whoever is on call: the developer in a “you build it, you run it” team, or an SRE where SREs are on call.
Sources: Google SRE book: introduction, Google SRE book: effective troubleshooting
14. Put security and compliance checks into the default pipeline, so every team gets them without extra work.
Platform team. Platforms build the company’s required checks into their templates. A security team may write the rules.
Source: CNCF platforms white paper
15. The developers who built a feature also get alerted when it breaks in production (“you build it, you run it”).
DevOps practice. It removes the wall between dev and ops: the team that owns a service also runs it.
Sources: Team Topologies: key concepts, AWS: what is DevOps?
16. Agree on a reliability target, such as “99.9% of checkout requests succeed each month”, and measure it.
SRE. Service level objectives (SLOs) are SRE’s core tool.
Sources: Google SRE book: service level objectives, Google SRE workbook: implementing SLOs, GitLab’s SRE job description
17. Release a new version to a small slice of users first (a “canary”), watch the errors, then roll it out to everyone.
Shared. Who does it depends on the company. Google’s SRE book recommends rolling out changes a little at a time. A platform team may build the rollout tools, and developers use them.
Sources: Google SRE book: introduction, CNCF platforms white paper, a Duolingo platform engineer job posting
18. Write a blameless report after the outage: what happened, why, and which fixes will stop it happening again.
SRE. Blameless postmortems are a core part of SRE culture.
Sources: Google SRE book: postmortem culture, a Google SRE job posting
19. After the outage, add an automatic safety check (roll back when errors jump) to the shared pipeline template, so every team gets it.
Platform team. The shared template is the platform team’s product, so the postmortem’s fix goes into the golden path for every team. Who maintains the pipeline itself (task 5) depends on the company.
Sources: CNCF platforms white paper, a Duolingo platform engineer job posting
20. When this month’s error budget is used up, pause risky launches until reliability recovers.
SRE. That’s an error budget policy. The error budget is the failures your reliability target allows, and when it’s used up, releases pause.
Sources: Google SRE book: introduction, Google SRE workbook: example error budget policy
21. Developers and operations people watch the same dashboards and fix problems together, instead of blaming each other.
DevOps practice. Breaking down the wall between dev and ops is what DevOps culture is for.
Sources: Google SRE workbook: how SRE relates to DevOps, Microsoft: what is DevOps?
22. Keep repetitive manual work under half of your team’s time, and spend the rest writing code that removes it.
SRE. Google’s goal: toil, the repetitive manual work, under 50% of each SRE’s time, so the rest goes into engineering.
Sources: Google SRE book: eliminating toil, Google SRE book: introduction
23. Write the guides and run demos so other teams actually choose to use the platform.
Platform team. The CNCF lists marketing the platform as a platform team job.
Source: CNCF platforms white paper
Did it on paper?¶
Here’s the whole key at once. Count how many you got right.
Show all answers
- DevOps practice1, 2, 6, 15, 21
- SRE4, 8, 12, 16, 18, 20, 22
- Platform team3, 7, 9, 11, 14, 19, 23
- Shared5, 10, 13, 17
Download the worksheet (PDF, one page). The reasons are under each task above. I checked every source in October 2026.
Free. Unsubscribe anytime. Form not loading? Subscribe here.