Your CI pipeline has been green for months. This morning every build fails at the deploy step with an authentication error against the cloud provider. Nobody touched the pipeline. Walk me through it.
What they are really testing: They are testing whether you can stabilise a blocked team quickly and then attack the structural cause, which is usually long lived static keys that finally expired or got rotated.
A real interview question
Your CI pipeline has been green for months. This morning every build fails at the deploy step with an authentication error against the cloud provider. Nobody touched the pipeline. Walk me through it.
What most people say
drag me
“I would generate a new access key, paste it into the CI secrets, and the build goes green again. Problem solved.”
It fixes today and guarantees the same outage in ninety days, and it shows no curiosity about why the credential died in the first place.
The follow-ups they ask next
How does OIDC federation actually stop this happening again?
Explain there is no stored secret at all: the CI provider signs a short lived token, the cloud trusts the issuer and the specific repo, and the session lasts minutes.
What if the key was deactivated deliberately by security and you just re-minted it?
Admit that would be the real mistake, and say you always confirm with the owner before restoring a credential that something else killed on purpose.
What the interviewer is listening for
- Reads the exact error code and reasons from it
- Unblocks the team first with a time box, then hunts cause
- Checks whether the key was killed intentionally before reviving it
- Proposes OIDC to remove the whole class of failure
What sinks the answer
- Rotates the key and calls it done
- Cannot distinguish expired from revoked from unauthorised
- Stores the new key in plaintext in the repo or a shared doc
- Never asks who or what disabled the credential
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 CI credential outage, but I would reason like this: confirm how wide the failure is, read the exact auth error, unblock safely, then find what expired and remove the long lived key entirely.”
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