Patch Management Interview Questions: Rings, Reboots, N-Days and the First 24 Hours of a Critical CVE

Patching sounds like operations, but security interviews use it to test judgement: what to fix first, how to fix it without breaking production, and how to tell that the fix is in effect. Here are the questions that come up, and the points that move an answer from "we patch monthly" to a hire.

1. "How do you decide what to patch first?"

Not by CVSS alone. Exploitation evidence (CISA's Known Exploited Vulnerabilities catalog, EPSS), exposure (internet-facing first) and what the asset can reach set the deadline. Full answer: prioritising vulnerabilities.

2. "Walk me through how a patch reaches production."

Rings with health checks and rollback; platform specifics (Windows deadlines and restarts, Linux service restarts and live patching, containers rebuilt from fixed base images, appliances on failover pairs); verification from the running version. Full answer: how patching works in practice.

3. "A critical library CVE drops on Friday. What do you do?"

Run it as an incident with four tracks: exposure (SBOMs, images, runtime, vendor products), mitigation where you cannot patch tonight, remediation, and a hunt for exploitation before disclosure. Full answer: critical CVE: the first 24 hours.

4. "Why are VPN and firewall appliances such a problem?"

They face the internet, hold credentials and rarely run endpoint monitoring, and several have had pre-authentication bugs exploited within days. Patching may not remove persistence installed before the patch. Full answer: hardening routers and edge appliances.

5. "Why does publishing a patch increase risk?"

Patch diffing points attackers at the bug; the gap between upstream fixes and downstream releases widens it. Full answer: patch diffing and the n-day window.

6. "How do you handle phones that cannot be patched?"

Android fixes reach users through device makers, so patch levels vary; enforce minimum app versions on the server and use attested patch levels as risk signals. Full answer: mobile patching and minimum versions.

What separates senior answers

Senior candidates talk about patching as a measured pipeline with a deadline, not a calendar event. They separate deciding (what and how fast), delivering (rings, platforms, appliances) and proving (running versions, rescans, exceptions with owners and end dates). They know the emergency path exists before it is needed: pre-approved changes for exploited, exposed bugs, a way to collapse rings into hours, and mitigations ready for systems that cannot be patched in time. And they measure the right thing, the time from a fix being available to the fix being active on exposed systems, rather than the percentage of tickets closed.

The mistakes that cost offers

• Reporting "98 percent patched" from package state while services still run old code.
• No rollback plan, including for security agents (the 2024 CrowdStrike outage was a content update pushed everywhere at once).
• Treating a WAF rule as remediation.
• Ending an edge-device incident at "we patched".
• One deadline for every asset, regardless of exposure.

A compact model answer

"I prioritise by exploitation and exposure, deploy through health-gated rings with rollback, make sure fixes are active (restarts, reboots, redeploys) and verify from what is running. For exposed, exploited bugs I compress to days and mitigate where I cannot patch, and I hunt for exploitation that happened before the fix."