SRE interview questions: short answers
The short answer from every lesson in the track — the lesson’s own text, minus the “Short answer:” label — and the questions from its “Next they ask” section. The answers to those questions, the mechanism and the measurements behind it all are in the linked lesson.
01
Signals and PID 1
For the process with ID 1 in its own namespace the default action of a signal is not carried out, so
SIGTERMwithout a handler does nothing to it — the orchestrator waits out the grace period and finishes the job withSIGKILL, leaving exit code 137, that is 128 + 9, in the report. A zombie, meanwhile, is not a process but the record of a death: it is held for the exit code, it occupies a slot in the process table, and what removes it iswait, not time.Next they ask
02
cgroups and OOM
A memory limit is set on a group of processes, and when the group hits it the kernel first tries to free memory inside the group; when that fails, it kills one of the group's processes with
SIGKILL. That is why the application log is empty and why the outside sees 137, which is128 + 9. Usage does not run away past the limit either: in the measured run the group's peak climbed exactly to it and stopped there.Next they ask
03
Descriptor limits
EMFILEis a limit on the number of descriptors held by one process, and what it counts is not files but every open object — sockets, pipes,epoll— plus the three the process received at birth. There are two limits: the kernel checks the soft one when a descriptor is opened, while the hard one bounds how high the process may raise its own soft limit — and the process can do that raising itself, without a restart.Next they ask
04
Page cache and fsync
writecarries data only as far as the kernel's cache and returns; durability is promised byfsync, and it costs two orders of magnitude more. That is why a process crash loses nothing written — the cache belongs to the kernel — while a power loss may lose everything unflushed.Next they ask
05
The accept queue
Between the client's
connectand the server'sacceptsits a kernel queue, and a connection in it is already established — the kernel did the agreeing, not the application. That is why a busy server looks like a working one to a client, and why an overflowing queue gives the client a timeout rather than a refusal: the packet is dropped silently and TCP retries it.Next they ask
06
Timeouts and deadlines
A timeout bounds the caller's waiting and says nothing to the worker, so the work continues after the client leaves; a deadline is a point in time that travels with the request, and a worker can refuse against it without starting. Measured on a chain of three services: without a budget all three finished the work, with a budget one did — the second refused without starting and the third was never called.
Next they ask
07
Retries and jitter
Retrying amplifies load at the moment of failure, and an identical retry schedule synchronises that load into a peak after recovery. So two different things are needed: exponential backoff, so that there are fewer retries as failures repeat, and jitter, so that clients do not come back together. In this lesson's model jitter cut the peak a hundredfold but pushed the moment everyone is served from 3100 ms out to 13,290.
Next they ask
08
Graceful shutdown
A graceful shutdown is two actions in order — stop accepting new connections and finish the ones already taken — and it works only because
SIGTERMcan be caught. Measured on one and the same server under identical load: without a handler 20 requests out of 20 were broken, with draining zero, and the cost of draining was 164 ms against 2 — the remainder of the work already started.Next they ask
09
Queues and tails
Time in the system is service plus waiting, and what grows with utilisation is the waiting, not the service. So the dependency is disproportionate: in the model, raising utilisation from 0.80 to 0.95 is plus 19 %, and time grew 4.1x with the work unchanged at 10 ms per request.
Next they ask
10
SLOs and budgets
An SLO is a target on a metric plus a window, and an error budget is how much failure that target allows within that window — counted in the same unit as the metric itself. With availability counted over requests, 99.9 % over 30 days at 1000 requests per second is 2,592,000 failed requests, which for a total outage equals 43.2 minutes; the same 99.9 % over a day is 1.4 minutes.
Next they ask
11
Health checks
There are three probes and they differ by consequence — liveness restarts, readiness removes from rotation, startup postpones liveness for the duration of the boot. So the liveness question is not "is the process alive" but "would restarting this process help": only what a restart fixes goes inside it, and dependencies go into readiness.
Next they ask
12
Rollouts and rollbacks
The damage from a bad rollout depends on how much traffic the faulty version serves and for how long, and on how severe the defect is — not on the name of the strategy. With a constant request rate and constant shares, the number of broken requests is the rate × the share of traffic on the new version × the share of requests the defect breaks × the total exposure time, and within that time the time to the alarm, the decision and the rollback add up. So a canary needs a detector able to notice the problem in a small sample: in the lesson's model the same canary affected 645 requests with a detector waiting for 200 errors and 29 with a rate detector — twenty-two times apart.
Next they ask
13
Name resolution
The application usually does not call DNS but the system's name-resolution function (
getaddrinfoon Linux), and that function goes through sources in the order set bynsswitch.conf— often the/etc/hostsfile first, the name server after it. So the answer can arrive with no network at all, and the duration of this step is set by the resolver's settings: in the lesson's measurement a name that did not resolve cost 12.0 seconds. Whether the client's timeout bounds it depends on the API: a socket timeout set after the lookup, as in Python'ssocket.create_connection, does not cover a blocking lookup, while a deadline on the whole call does — Go'snet.DialTimeoutincludes name resolution in its budget.Next they ask
14
TLS handshake
A handshake costs no CPU work worth mentioning but round trips — flights to the server and back — and it is paid once per connection rather than per request. How many round trips depends on the version: TLS 1.3 one, TLS 1.2 two. Measured over a link with a known round trip: 43.6 ms against 84.7 for a full handshake. So "the first request is slow" is cured by reusing the connection, not by turning encryption off.
Next they ask
15
TIME_WAIT and ports
TIME_WAITis the normal end of a connection rather than a leak. The side that closed holds on to its address-and-port pair for a while, so that delayed segments of the old connection are not accepted by a new connection with the same addresses and ports. It becomes a problem for a client that opens a connection per request: what runs out is not memory and not descriptors but port numbers. Measured: with a range of 50 numbers, exactly 50 connections andEADDRNOTAVAILon the fifty-first.Next they ask
16
Load balancing
Round-robin hands out an even number of requests rather than an even amount of work, so it loses as soon as requests are not alike. Asking two random servers takes a large part of the gain of asking all of them, and its price does not grow with the fleet. Model: a p99 wait of 582.4 ms for round-robin, 123.6 for two choices and 42.9 for inspecting every server.
Next they ask
17
Consistent hashing
Modulo ties the owner of a key to the number of nodes, so any change of membership recomputes everything; a ring ties the owner to the position of the key, so only the keys next to the change move. Computed over 100,000 keys: adding a ninth node to eight moves 88.9 % of the keys under modulo and 11.5 % on a ring with one point per node.
Next they ask
18
Idempotency
Exactly-once delivery cannot be guaranteed, but the effect can. The client generates a key per operation, the server claims a place under that key before doing the work and stores the answer, and any retry gets the same answer instead of a second effect. Measured: four retries without a key, four effects; with a key, one.
Next they ask