Q1 Explain SLI, SLO, and SLA with a real example.
Answer: "An SLI is the metric we measure, like the
percentage of API requests returning HTTP 200 within 300ms. An SLO is our internal
reliability goal for that metric, such as 99.9% over 30 days. An SLA is the external
legal contract with the customer—for example, promising 99.5% uptime or paying a financial penalty."
Q2 What is an Error Budget and how do you use it?
Answer: "An Error Budget is 100% minus the SLO. For a 99.9%
monthly SLO, our error budget is 0.1%, or about 43 minutes of allowed downtime per month. As long as we
have budget left, developers can push new features rapidly. If an outage burns through the budget, we
pause feature releases and focus on reliability fixes."
Q3 What is 'Toil' and how have you reduced it?
Answer: "Toil is manual, repetitive operational work that doesn't add
permanent value—like manually restarting stuck services or cleaning up old log files. SREs aim to keep
toil below 50% of their time by automating those tasks using Python scripts, cron jobs, or Terraform."
Q4 What are the Four Golden Signals of Monitoring?
Answer: "Latency (time taken to serve a request), Traffic (requests per
second), Errors (rate of failing requests like HTTP 5xx), and Saturation (how full resources like CPU,
memory, or database connections are)."
Q5 What is the difference between Availability and
Reliability?
Answer: "Availability measures whether the system is
reachable at a given moment (for example, the webpage loads and returns HTTP 200).
Reliability measures whether the system performs its intended function accurately and
consistently over time without errors."
Q6 What is the difference between Monitoring and
Observability?
Answer: "Monitoring tells you when something is
wrong based on known thresholds. Observability lets you understand why a complex
system is failing inside by combining Metrics (what broke), Logs (the
exact error message), and Distributed Traces (which microservice caused the delay)."
Q7 How can AI (AIOps) be leveraged in Site Reliability
Engineering?
Answer: "AI helps SREs in four practical ways: (1) Alert
Correlation—grouping 100 noisy alerts into one incident ticket; (2) Anomaly
Detection—catching unusual traffic drops before static thresholds fire; (3) Automated
Root Cause Analysis—correlating error spikes with recent Git deployments; and (4)
Incident Co-Pilots—summarizing crash logs and drafting blameless postmortems."
Q8 Users report your website is slow or returning 502 Bad
Gateway. How do you troubleshoot?
Answer: "First, I check if a new deployment or config change happened
recently—if yes, I roll it back immediately. Next, I check the Load Balancer health checks, inspect server
CPU/Memory/Disk (`top`, `free -m`, `df -h`), check application error logs (`kubectl logs`), and verify if
the database has slow queries or maxed-out connections."
Q9 A Kubernetes Pod is stuck in `CrashLoopBackOff`. How do you
fix it?
Answer: "I run `kubectl describe pod` to check events and exit codes, and
`kubectl logs
--previous` to see the exact error message before it died. Common causes are missing
environment variables, wrong startup command, failed liveness probes, or running out of memory (Exit
Code 137)."
Q10 `df -h` shows 40% free disk space, but the server still
says "No space left on device". Why?
Answer: "The disk has run out of inodes because millions
of tiny files were created (for example, in `/tmp` or a mail queue). I run `df -i` to confirm inode
exhaustion and remove the folder containing millions of small files."
Q11 What is the difference between a Liveness Probe and a
Readiness Probe in Kubernetes?
Answer: "A Readiness Probe checks if a pod is ready to
receive user traffic; if it fails, Kubernetes stops sending traffic to that pod without restarting it. A
Liveness Probe checks if the app is deadlocked/frozen; if it fails, Kubernetes kills and
restarts the container."
Q12 What is the difference between Blue/Green and Canary
deployments?
Answer: "In Blue/Green, we run two identical
environments and switch 100% of traffic from Blue (old) to Green (new) at once. In a Canary
deployment, we send only a tiny slice of live traffic (like 5%) to the new version first,
monitor error rates, and gradually roll out to 100%."
Q13 Why do we write a Blameless Postmortem after an incident?
Answer: "If you blame or punish an engineer for an honest mistake, people
will hide problems in the future. A blameless postmortem asks 'Why did our system allow this mistake
to reach production?' and adds automated tests, alerts, or guardrails so nobody can trigger the
same outage again."
Q14 What is the difference between RTO and RPO in Disaster
Recovery?
Answer: "RTO (Recovery Time Objective) is the maximum
acceptable downtime after an outage before service must be restored (e.g., 15 minutes). RPO
(Recovery Point Objective) is the maximum acceptable age of data we can afford to lose (e.g., 5
minutes of database transactions)."
Q15 How do you prepare an e-commerce platform for a 10x Black
Friday traffic spike?
Answer: "First, cache static and product catalog reads at the CDN and
Redis layer so 85% of traffic never hits the database. Second, run load tests (k6/Locust) weeks ahead to
find bottlenecks. Third, pre-scale Kubernetes nodes and database read replicas before the event starts.
Fourth, enable rate limiting, circuit breakers, and graceful degradation."