Incident Response and Management Questions

Direct answer

First priority is stopping the spread, not restoring anything: isolate affected segments and, if the entry point is unknown, disable shared credentials the ransomware could use to jump further. In parallel I loop in legal and executive leadership, since ransomware is a business and legal event as much as a technical one. I don't trust backups until I've verified they predate the compromise.

Structured elaboration

Following a NIST/SANS-style response: contain, then assess, then decide on recovery.

Containment (first 15-30 min): isolate infected hosts and shares, reset credentials the ransomware could use to spread laterally, and preserve one infected machine uncontained for forensics instead of wiping everything.

Who's looped in: legal (breach notification duties, and ransom-payment legality varies by jurisdiction), leadership (business impact and ransom authority), and often external incident response or law enforcement.

Trusting backups: check the timestamp against your best estimate of the initial compromise, not just when encryption started, since attackers often sit inside a network for days first. Restore into an isolated environment and scan for the same indicators of compromise before promoting it to production.

Worked example (story skeleton)

Shares in two departments start encrypting minutes apart. The lead isolates that segment, confirms the others are clean, and works with IT to find the last known-good backup timestamp while legal is notified.

Trade-offs and pitfalls

Restoring fast from an untested backup risks reintroducing the malware. Waiting too long extends the outage. A common mistake is scoping only to systems visibly encrypting, when the attacker may already have persistence elsewhere that hasn't triggered yet.

What the interviewer probes next

How you'd decide whether to consider paying the ransom and who holds that authority, and how your plan changes if the backups are also compromised.

Direct answer
Signs pointing toward a security incident rather than a purely operational one include unexplained privilege or permission changes, authentication failures or account lockouts clustering in an unusual pattern, traffic or data-access patterns that look like exfiltration rather than normal load, and any sign of unauthorized file or configuration changes that nobody on the team made. Once you suspect any of these, the biggest change is that you stop trying to 'just fix it': you preserve evidence instead of immediately remediating, and you loop in a security responder rather than continuing to triage it as a routine outage.

Structured elaboration

• Signals that lean operational: the timing correlates with a known deploy or infrastructure change, the failure pattern matches a resource exhaustion or a known dependency issue, and the behavior is explainable by something the team did on purpose.
• Signals that lean security: access or configuration changes nobody recognizes, authentication anomalies (a spike in failed logins, logins from unusual locations, tokens being used in ways that don't match normal patterns), data being read or moved in volumes or patterns that don't match normal usage, or any indicator resembling a known attack pattern (credential stuffing, privilege escalation, lateral movement).
• What changes once you suspect it. You stop applying your normal 'fix it fast' instincts on the affected system, because touching it (restarting a process, wiping a disk, rotating credentials without first documenting state) can destroy evidence a security investigation needs. You loop in whoever owns security response, and from that point the deep investigation, containment technique, and evidence-handling discipline live with that team rather than being improvised by whoever happened to be on call.
• Who to involve: the security on-call or incident response function, as early as suspicion arises, not after you've already tried to resolve it yourself.

Worked example
A service starts throwing errors and the on-call engineer initially assumes it's a bad deploy, since that's the most common cause. But checking recent deploys shows nothing changed, and instead they notice a spike in failed authentication attempts against an admin endpoint in the minutes before the errors started, followed by a permissions change on a service account that nobody on the team made. That combination (no correlated deploy, authentication anomaly, unexplained permission change) is the tell that this isn't a routine outage; the engineer stops attempting further remediation, preserves the current state (avoids restarting the affected service, which could wipe useful logs), and escalates to the security team rather than continuing to debug it as an availability problem.

Trade-offs and pitfalls
The main risk under pressure is dismissing security signals too quickly because restoring service feels more urgent, which can mean actively destroying evidence (restarting a compromised host, deleting suspicious files 'to clean up') before anyone with security expertise has looked at it. The opposite risk is over-escalating every anomaly as a security incident, which burns the security team's time and can create alert fatigue that makes real security incidents harder to distinguish from noise; the right calibration is a small, well-understood set of signals (like the ones above) rather than a vague sense that 'something feels off.'

Direct answer

Containment stops a threat from spreading right now, like isolating a host. Eradication removes the root cause, like deleting the malware or closing the exploited hole. Teams often delay eradication after containing, because acting too fast can destroy evidence needed to find every other place the attacker got in.

Structured elaboration

NIST's incident lifecycle treats these as separate phases: containment buys time and limits damage (isolate a host, force password resets); eradication removes what let the attacker in or persist, so it can't simply return.

Worked example

An analyst isolates a beaconing workstation from the network but leaves the malware in place for a few hours while the team hunts for other infected machines, instead of wiping it immediately.

Trade-offs and pitfalls

Eradicate too soon and you can tip off the attacker and lose forensic evidence before you know the full scope. Wait too long and some level of attacker access stays live.

What the interviewer probes next

How you'd verify containment is actually holding, and what would push you to eradicate immediately instead of waiting.