After a routine deploy, about a third of requests to your internal orders API start failing with connection refused. You run dig and the hostname is resolving to an IP address that was decommissioned last week. Walk me through it.
What they are really testing: They are testing whether you understand caching and TTLs, and whether you can stop the bleeding for users before you go hunting the misconfigured record.
A real interview question
After a routine deploy, about a third of requests to your internal orders API start failing with connection refused. You run dig and the hostname is resolving to an IP address that was decommissioned last week. Walk me through it.
What most people say
drag me
“DNS is cached, so I would just wait for the TTL to expire and it should fix itself in a while.”
It treats a live customer-facing failure as something to sit out, shows no urgency, and misses that you can force the correct answer immediately instead of waiting.
The follow-ups they ask next
The authoritative record is correct but clients still fail. Explain that.
Talk about resolver caches, negative caching and long lived JVM or connection pool caches that never re-resolve.
Why not just set every TTL to 30 seconds forever?
Trade off query volume, resolver load and cost against how fast you can move traffic in an incident.
How do you stop a decommissioned IP being left in DNS again?
Ownership in infrastructure as code, plus an automated check that every record resolves to a live target.
What the interviewer is listening for
- Pulls the bad answer out of rotation before diagnosing
- Knows to query the authoritative nameserver to bypass caches
- Reasons explicitly about TTL as a recovery time cost
- Verifies the fix from more than one vantage point
What sinks the answer
- Waits passively for a cache to expire while users fail
- Cannot explain the difference between authoritative and cached answers
- Fixes the record and declares victory without verifying
- Blames DNS in general without naming a mechanism
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not owned a DNS incident end to end, but here is how I would reason: first get users off the bad answer, then find out whether the wrong address is authoritative or just cached.”
Keep going with troubleshooting
Junior
You get paged at 2am. Checkout latency has gone from 200ms to 4 seconds and it started right after the 11pm deploy. Walk me through what you do.
Junior
It is 3am and you get paged: the primary application server is at 100% disk usage and the app is throwing write errors. You are the only one online. Walk me through exactly what you do.
Junior
You push a new version of a service and within two minutes the pods are all showing CrashLoopBackOff. The team is watching you share your screen. Walk me through exactly what you do.
Junior
A developer pings you: the checkout service cannot reach the payments service, the calls just hang and time out. You have never worked on either service. Walk me through what you do.
Junior
A developer messages you: 'My app suddenly gets Access Denied writing to the S3 bucket. Nothing changed.' It worked yesterday. Walk me through what you do.
Mid
Your load balancer shows 5xx errors jumping from 0.1 percent to 12 percent of requests over ten minutes. There was no deploy. What do you do?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free