Declare the incident, assign an incident commander, and separate investigation from communication. Then hunt the shared dependency: authentication, DNS, a database, a certificate, the service mesh control plane, or a cloud zone. Check what changed outside deploys, meaning config pushes, feature flags, DNS records, expiring certs, and provider status. Mitigate before you diagnose by shedding load, failing over, or disabling the suspect flag, then verify with user facing SLIs.
Why interviewers ask this
Simultaneous, broad failure is the signature of a shared dependency, and interviewers want to see whether your instinct is to look for the common cause rather than debug ten services in parallel. They are also assessing incident command: role separation, structured communication, and the discipline of mitigating before fully understanding.
How to structure your answer
- Set up incident structure first: commander, comms, scribe.
- Reason from the pattern: simultaneous and broad means shared dependency.
- Enumerate what changed that is not a deploy.
- Mitigate with the reversible lever you have, before root cause.
- Confirm recovery against user facing signals, then schedule the postmortem.
Example answer
Broad and simultaneous with no deploy means it is almost never ten independent bugs, it is one thing underneath all of them. So I get incident structure up immediately, commander and a comms person, then start on the shared layer list: auth service, DNS, the primary database, the mesh control plane, certificates, and cloud provider health. In parallel I ask what changed that is not code, because config pushes and feature flags are changes people forget to count. We had exactly this pattern once and it turned out to be an internal certificate authority renewal that had quietly expired an intermediate, so every mutual TLS handshake started failing at the same minute. The tell was that failures were connection level rather than application level. While that investigation runs I want a mitigation lever ready, usually shedding non essential traffic or failing over to the secondary region, because I would rather be degraded and stable than fully broken while we think. Then verify with real user metrics, not just green pods.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you distinguish a DNS problem from a network problem quickly?
- What is your policy on failing over to another region during an unknown fault?
- How do you keep stakeholders informed without derailing the responders?
Related site reliability engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions