The interviewer points at the photo-sharing upload service you just drew and asks how you would define reliability targets for it, and what happens when you miss them. The answer is a written target, such as "99.9% of photo uploads succeed over 30 days". That target is an SLO (service level objective). It is checked against an SLI (service level indicator), a measured ratio of good events to valid events, such as uploads that succeeded over uploads users attempted. A customer contract that promises credits when reliability drops is an SLA (service level agreement).

The basic idea is to count good events over valid events at the point where users experience them, and pick a target below 100%. The gap between the target and 100% is the error budget, the share of the window that is allowed to fail. At 99.9%, 60k of 60M uploads a month may fail. Reach for this when people argue about reliability without a shared number, or must choose between features and fixes. Skip it for a prototype with a handful of users, where an uptime check and a named owner are enough, and for a nightly batch job, where you only need to know whether the run finished.

This is the opening question in most site reliability engineering (SRE) interview loops. In a general system design round it takes a few minutes, so aim to say the whole answer in under 2 minutes. Mid-level candidates write a sensible SLI and SLO and compute the budget. Senior candidates also defend how events are counted and where they are measured, notice when the service's dependencies cannot support the target, and say what the budget changes.