Revoke first, investigate second. Deactivate or delete the key immediately rather than waiting to confirm misuse, then issue replacement credentials so services recover. Next, pull the audit log for every call made with that key since it was exposed, looking for unfamiliar addresses, new identities, or data access. Treat it as an incident, involve security, and follow up by removing the need for static keys at all.
Why interviewers ask this
The interviewer is testing your instincts under a security incident, where hesitation costs you. They want revocation before analysis, then a genuine blast radius investigation rather than assuming nothing happened. They also look for the systemic follow up, because a team that responds well but keeps issuing long lived keys will be back in the same position within months.
How to structure your answer
- Revoke immediately and say why you do not investigate first.
- Restore service with replacement credentials.
- Investigate blast radius from the audit trail.
- Fix the systemic cause and the detection gap.
Example answer
Deactivate the key first. People hesitate because they are worried about breaking something, but the key is public and exposure is measured in seconds; automated scanners find these things faster than we do. So deactivate rather than delete initially, since that stops the risk while keeping the identity for investigation, then get replacement credentials to whatever legitimately needed it. Then blast radius. I pull every call made with that key from the audit trail since the commit landed, and I care about anything from an unfamiliar address, and specifically about persistence: new users or roles, new keys, changed trust policies, because a smart attacker uses the leaked key once to create a quieter way back in. I also check for data reads and exfiltration patterns. It gets handled as a security incident with the security team involved, not quietly by whoever noticed. Afterwards, two follow ups. Why did this identity have long lived keys at all, since it should be a role, and why did our secret scanning not catch it before the push? Both are more valuable than the rotation itself.
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
- What would you look for specifically to detect persistence?
- How do you know the key was not used before it was published?
- What controls would stop this happening again?
Related cloud 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