WikiFree Editorial

Site Reliability Engineer Career Path: Courses and Portfolio Project

Build a site reliability engineer portfolio with course resources, five practical stages, exercises and a project review rubric.

Site Reliability Engineer Career Path — 3 course resources, five stages and one portfolio project; red frame and WikiFree.com branding

Career studio / DevOps

Build evidence for the Site Reliability Engineer role

A fictional learning portal needs an availability objective and an incident process. Use synthetic request counts to define a service-level indicator and examine error-budget consumption.

Intermediate3 course resources5 practical stages1 portfolio project

Your outcome: SLI/SLO proposal, incident timeline and reliability improvement plan.

Start with the right expectations

Who this is for

Linux or command-line familiarity, basic networking and application behavior.

This path develops a demonstrable work sample for the named role. It does not replace employer-specific experience, professional qualifications or supervised practice.

Plan your study time

Use a flexible six-week project schedule: one week for each of the first four stages and two weeks for the portfolio and review. Allow roughly 3–5 hours per week for the case work, in addition to course study. This is a planning suggestion, not a measured course duration or a promise of job readiness.

Read the course access notes before starting. Free viewing or reading does not automatically include certificates, graded assessments, software licences or paid cloud resources. Core case work can be documented with a free editor and spreadsheet; optional implementation tools may have additional requirements.

Your course sequence

Start in the order below. Use the course outline to select the sections relevant to the stage tasks, and complete foundation exercises before moving on. Full provider courses can be substantially longer than this project schedule. These are course resources, not a claimed count of individual lessons.

Resource 01 / Google

Developing a Google SRE Culture: Free Reliability Course

Purpose: Build the foundations. Connect your notes to the case tasks below rather than only collecting completion marks.

  • Connect DevOps and SRE: understand their relationship and the role of reliability work.
  • Discuss reliability goals: explore service-level objectives, error budgets and the trade-offs they make visible.
  • Learn from incidents: examine blameless postmortems, psychological safety and knowledge sharing.

Access: Free videos, readings and quizzes; free Google Skills account required. No paid course subscription.

Certificate: Provider completion badge advertised; final assessment requires 80%. No professional certification or academic credit.

Open the WikiFree course · Provider learning source

Learn, make, check

Keep a decision log as you work. For each stage, capture the assumption, your work product, a check and the change you made after that check. The acceptance criterion is the stopping condition for the stage.

Stage 1 / suggested project week 1

Define a user-centered indicator

Understand: An SLI measures a user-relevant service behavior.

Make: Define successful requests, eligible traffic and the measurement window.

Check before moving on: Exclude only traffic justified by the documented definition.

Study companion: Developing a Google SRE Culture: Free Reliability Course. Use its relevant lessons and examples; the independent WikiFree task is not a provider assessment.

Save as evidence: a dated work product and a short note explaining one choice, one alternative and one remaining uncertainty.

Stage 2 / suggested project week 2

Calculate the budget

Understand: An error budget follows from a target and a denominator.

Make: Calculate allowed unsuccessful requests under the sample objective.

Check before moving on: State that the chosen target is a case assumption, not a universal standard.

Study companion: Free Observability Course: Monitoring, APM and App Health. Use its relevant lessons and examples; the independent WikiFree task is not a provider assessment.

Save as evidence: a dated work product and a short note explaining one choice, one alternative and one remaining uncertainty.

Stage 3 / suggested project week 3

Practice incident response

Understand: Incident work needs coordination and a clear timeline.

Make: Draft roles, updates and a mitigation decision from the synthetic incident.

Check before moving on: Separate confirmed facts from hypotheses in every update.

Study companion: Free DevOps Course: CI/CD, SRE and Infrastructure as Code. Use its relevant lessons and examples; the independent WikiFree task is not a provider assessment.

Save as evidence: a dated work product and a short note explaining one choice, one alternative and one remaining uncertainty.

Stage 4 / suggested project week 4

Learn without blame

Understand: A review should improve the system rather than assign motives.

Make: Write contributing factors, follow-up actions and verification dates.

Check before moving on: Do not claim a root cause merely because an event preceded the outage.

Study companion: Free DevOps Course: CI/CD, SRE and Infrastructure as Code. Use its relevant lessons and examples; the independent WikiFree task is not a provider assessment.

Save as evidence: a dated work product and a short note explaining one choice, one alternative and one remaining uncertainty.

Stage 5 / suggested project weeks 5–6

Present your portfolio

Assemble the four work products into SLI/SLO proposal, incident timeline and reliability improvement plan. Write a README explaining the problem, your assumptions, the decisions you made, tests actually performed and what remains incomplete.

Give a five-minute walkthrough: one minute for the problem, two for the work and evidence, one for trade-offs and one for the next improvement. If you have not implemented a proposed system, label it a design or prototype rather than a deployed solution.

Acceptance: a reviewer can locate each work product, reproduce the key reasoning and identify the limits without a private explanation from you.

Site Reliability Engineer portfolio roadmap and a review question from the fictional case
The working roadmap for this case. The answer is explained in the self-check below.

The portfolio brief

A fictional learning portal needs an availability objective and an incident process. Use synthetic request counts to define a service-level indicator and examine error-budget consumption.

Deliver: SLI/SLO proposal, incident timeline and reliability improvement plan.

Fictional practice inputs
window eligible requests unsuccessful requests
Week 1 100000 80
Week 2 100000 150
Week 3 100000 60

Use these small inputs to make the reasoning visible. They are not a representative dataset, a real client engagement or evidence of production performance. Where the brief requires additional sample records, create them yourself, label them synthetic and explain why you added them.

Download the portfolio kit

The ZIP includes the case CSV, four stage worksheets, course sequence, decision log, test log, portfolio README template, review rubric and reference reasoning. It is a starter kit for your work, not a completed application, professional report or proprietary project file.

Check your reasoning

For 100000 eligible requests and a 99.9% success target, how many failures are allowed by this simple request-based budget?

Write your answer and assumptions before opening the reference.

Read the reference reasoning

100 failures. If 150 failures occur, the target is missed for that window. This is a request-based model, not a time-based uptime calculation.

Portfolio review rubric

Criterion Points Evidence required
Problem and scope 4 A clear user, need, boundary and assumptions
Role-specific work 8 2 points for each of the four stage acceptance checks
Reasoning and validation 4 Independent checks, actual results and uncertainty
Communication and reproducibility 4 A usable README, source links and reviewable work products

Aim for at least 16/20 as a self-review target, with no missing stage acceptance check. This is a WikiFree practice rubric, not an industry credential or a hiring assessment.

Interview practice

Which alert would require immediate action, and which would be a trend review?

Answer using the case: context, your action, evidence and limitation. Describe this honestly as a self-directed project. Do not present fictional organizations, invented interviews or practice results as paid work experience.

Your progress

Use this checklist as a personal study aid. Progress is stored in this browser when local storage is available; it is not an account record or a certificate.

0 of 5 milestones complete

The lessons and projects remain readable without JavaScript. Automatic progress saving requires JavaScript.

Questions before you start

Will this path qualify me for a job?

It helps you study relevant foundations and produce a work sample. Employers may require additional skills, qualifications and experience. Review actual role requirements before applying; no job or certification is guaranteed.

Are all tools and certificates free?

The linked learning routes were selected for free viewing or reading. Follow the separate access and certificate notes on each course. Paid tools and cloud deployment are optional; document a local design when implementation resources are unavailable.

Can I follow this on a phone?

You can read the path and many learning resources on a phone. Coding, detailed spreadsheet work, design tools and mobile-app development are easier or require a suitable computer. The page is designed to reflow; that is not a claim that every physical device has been tested.

Created by WikiFree.com. Course references were selected from the published catalog snapshot checked on 13 October 2026. Access can change; consult each current course page. The case, exercises and rubric are original WikiFree learning materials.

Share this article

Questions & discussion

Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.

Add to the discussion

Your email address will not be published. Required fields are marked *