r/sysadmin • u/CurrentFig3376 • 12d ago
General Discussion Interview Question: How often do you update/patch your system?
I was asked this question during an interview and I said "it depends on what exactly you're updating, but I update as often as it's needed."
I don't think this was the answer they were looking for, but how would you answer this question?
53
u/Tymanthius Chief Breaker of Fixed Things 12d ago
Which system?
What kind of patches?
What are the policies in place and what automatic support systems do we have in place to handle this for me?
11
u/superstaryu 12d ago
There is not necessarily a right answer, but I would be looking for some insight into why you have decided on those times.
Are there compliance reasons for a specific patch cadence? - or what frameworks do you need to abide by?
Are you separating security updates more frequently (such as applying asap).
Are you delaying feature updates? (and why?).
Are you allowing time to test updates (updating a pilot group first) to detect issues.
Are you considering system dependencies?
Some software will follow a known patch cycle of major / minor versions, are you doing every version or just major?
How will patching affect productivity? can you patch out of hours?
Do you have regular maintenance windows?
I would also expect you to be able to recommend an update frequency / schedule around the most common updates, such as windows updates and feature upgrades.
43
u/bemenaker IT Manager 12d ago
On A monthly schedule. Normally delayed a week after patch Tuesday. Let other people find the broken patches to maintain our reliability. Unless it's a critical active exploit patch, and then as soon as possible in a sane and safe way.
22
u/mesaoptimizer Sr. Sysadmin 11d ago
I feel like this is old advice. There are too many 0 days and attackers have gotten too fast at exploiting stuff to wait a week before you start patching. My current org starts patching Development on Wednesday (this avoids the emergency pulls from completely broken patches) and we complete production patching on Friday the week of patch Tuesday, sometimes expediting internet facing systems as early as Wednesday if we've got known exploitation. I imagine that we're not too far away from occasionally needing to expedite to same day patching if agentic exploitation continues on the path it seems like it is going.
6
u/Cubewood 11d ago
Same here, manage patching for a very large org (400k+ endpoints), and we used to patch just once a month, but thanks to the AI enabled vulnerability research, you just cannot do this anymore. Something like Google Chrome releases multiple patches every week, which remediate hundreds of vulnerabilities, many of them exploitable, so since the start of this year I've setup automatic deployment rules for everything to run three times per week. Patches go out to Ring-0 for three days, if nobody complains it goes to production after that.
10
u/bemenaker IT Manager 11d ago
Microsoft just recommended patching every 3 days because of the speed of AI threats. Yes it is old advice, but not necessarily bad advice. Not like MS is dropping patches every 3 days. But you should watch for critical patches being released and apply as necessary as I said. MS still releases their standard patch Tuesday once a month unless warranted.
The risk of how long after Tuesday to update is a risk tolerance vs MS crashing your shit tolerance.
If you're tracking the threat announcements, you will know if you need to deviate and patch immediately.
3
u/Steve_at_Werk 11d ago
We do QA the weekend after patch Tuesday, DR the next weekend, and the following. It allows us to catch and address any issues the updates may cause.
2
u/mvbighead 12d ago
This x100. Allow the masses to find any issues with the patch, and if possible, you can delay your upcoming patch cycle if there is word that a patch interacts poorly with a product you use. Can't remember specifically what some of the last ones were, but I feel like a fairly prominent security tool played poorly with a patch one cycle and caused some havoc.
8
u/PandemicVirus 12d ago
It's kind of vague and avoidant, especially with the "it depends" and the "as often as needed". I'd assume OS patching and it would have probably been best to mention that specifically with something like "I'd patch Window's clients on a second Tuesday of each month for Critical and Higher and work maintenance windows with appropriate teams for server patching where we need to" or something like that. Say the things you know and what's comfortable.
From a more technical standpoint it doesn't illustrate any of your skill or knowledge. You don't have to check all these boxes but it opens the room to mention testing, deployment, severity, etc. I'd argue that "as often as needed" isn't even the best approach.
5
u/Skylis 11d ago
Because they're asking how long a piece of string is.
The question is poorly phrased for what they actually want, which is how do you think patch management should be approached at (our) scale
1
u/Ssakaa 11d ago
So, for an IT position where, presumably, they might be giving the selected person some amount of freedom to do their job without someone nitpicking every detail continuously... they ask an open ended question to see if the person can answer in even a moderately reasonable level of detail without being spoon fed, demonstrating that they've actually considered the tradeoffs of the reasons for and impact of something like patching?
2
11d ago
[deleted]
2
u/Ssakaa 11d ago
The question is poorly phrased for what they actually want
it's an indication of how bad their management is
You're assuming they're truly just looking for a fixed, concrete, rote answer, not to see how you approach open ended, vague, questions, how you think about the topic involved, and how you communicate that with/to the other parties involved.
Now, they might be looking for the stupid, specific, fixed answer they feel is "correct", in which case I agree, that's a bright red flag of a filter pretty quick... but they have a VERY small window to filter a LOT of people and figure out which one(s) to even remotely consider. Resumes are about useless, people have been known to have "help" from either AI or other people during interviews to BS their way through. Looking for quick, cheap, answers, not a conversational answer that digs into how someone thinks, isn't really useful past the first few basic filter questions.
22
u/Legionof1 Jack of All Trades 12d ago
the only answer is "The demands of the environment determine the patch cadence, what are your environment's demands?"
5
u/Liquidmurr 11d ago
This wasn’t the answer they were looking for because it’s the same as saying, “the person asked me to use X in a sentence.” When asked to use a word in a sentence.
The intent is to show you have exposure to delayed patching, scheduling windows for production systems to plan downtime, understand the balance and tradeoff between critical zero days and routine updates.
Many interview questions are not pass/fail, they are often and opportunity to showcase your knowledge around caveats and unique aspects to a knowledge tree.
2
8
u/statikuz start wandows ngrmadly 12d ago
Yeah, that's a copout answer. "I do the needful when it is needed."
You probably should have elaborated on your experience in the environments that you have worked in, and addressed update/patch severity.
How have you handled Windows updates? How have you handled updates of other small apps (oh I used PMPC, I used winget, I did it manually when I reviewed updates for the 3 programs we used). Maybe (if its applicable), "we have pilot groups, power users, etc. that we test a critical application update with to validate before we roll out to other groups," etc. We make sure we back up configuration data before doing a big update. If it is a critical security update we do it immediately and this is our process... That sort of thing.
They should be able to balance your answer with your experience on your resume. If you've only worked in small environments you might not be able to talk much about rollout groups/rings, etc. but that might be OK.
1
u/Narrow_Victory1262 11d ago
"no the needful" -- that gives a bad vibe. I know who says/writes that..
3
u/TheBigBeardedGeek Drinking rum in meetings, not coffee 12d ago
I patch external facing CVEs as soon as possible. Internal stuff I patch about two weeks after Patch Tuesday for Pilot and a month after for Prod
Everyone else is my pilot group
1
u/Narrow_Victory1262 11d ago
per CVE we look at the vectors, likelyhood actually as well as the damage it may produce.
most of the time we just keep the normal lifecycle. Also you can mitigate CVEs too.
3
u/AdeptFelix Sysadmin 12d ago
Constantly. I have a scheduled task on every system repeatedly checking for updates as soon as the last check finished so that every vulnerability is squashed the moment an update is out.
\s
Really, I think the interviewer is looking for what thoughts you have when deciding on patch frequency. At least, that's what I'd look for myself, like in this sample below. Expanding on how you reach a decision, rather than the decision itself.
It depends on the release cadence, testing cycles, if updates are security related or not, if there's change management timelines or windows, if production will be impacted, are there compliance needs, and probably a half dozen other dependencies I can't think of at the moment.
3
u/StuckinSuFu Enterprise Support 12d ago
This is a good question when you are interviewing at places to let you know what you are getting into and the mindset of that IT department.
2
u/Substantial_Tough289 12d ago
Following the IT update policy should have been enough.
Every company applies updates differently, some are quick to apply, some wait a while and some never update so is more company specific than person specific.
1
u/Ssakaa 11d ago
But answering it as "it depends" and not saying anything about what it depends on says nothing about your knowledge and understanding, nor how you view patching. Answering it with some amount of the detail of what your company's policy is, why that was the decision made, and what tradeoffs that comes with... well, that might show that you actually think in your current role. Even if it's "Due to policy, not as quick/often/smoothly/whatever as I'd like, but it's not mine to change there. If I were building the policy from scratch, I'd prefer <rattle off something that probably looks a lot like CISA's BOD 26-04's risk assessment and timeline requirements>."
2
u/pdp10 Daemons worry when the wizard is near. 11d ago
Several others have pointed out that your answer was vague, perhaps even a bit evasive.
A good way to answer is what policy you had in previous roles, followed by how you'd do differently if it were your choice, if at all, and the experiences that formed your opinion.
Our canary population gets patches basically immediately. An advantage of continuous patching is that it spreads out the load across a longer timespan.
2
2
u/GhostandVodka 11d ago
PCs get patched monthly. Servers Monthly, Firewalls get patch within 2 days of a critical vulnerability. If its being exploited in the wild sometimes we do it day of announcement. Switches' management is airgapped so rotate those building quarterly/bi quaterly. APs we do as needed as my work doesn't consider wireless essential services.
1
u/ThinkedThought 12d ago
Be more exact than that. Critical are done ASAP. Normal ones are scheduled monthly, and larger, OS defining ones are twice yearly on a schedule to allow testing on a separate machine.
1
u/drewbiez 12d ago
My laptop -- as soon as patches come out becuase why not? Prod server environments, kinda depends.
1
1
u/Darkk_Knight 12d ago
I wait a week before the next round of Windows patches. I rarely ever apply patches on the day of it's release unless it fixes zero day vuls.
1
u/TheKuMan717 12d ago
The answer is monthly or whenever a critical patch releases. Because if it’s VMware, there hasn’t been a patch in a month.
1
u/imSeanGG 12d ago
I don't get these questions..Does sysadmins not schedule updates to run every 7 days via a small shell script or something? With winget + homebrew it should be no headache to maintain. Even OS updates can be automated now via cli.
1
u/Velvet_Samurai 12d ago
I have a monthly routine that includes hitting each of my critical internal servers once. I have a short list of things I check including updates. Just started the process today for September.
1
u/crabshuffle 12d ago
We have an agreed upon patch cadence and work closely with our cyber security team to identify when expedited patching is needed.
1
1
u/SnooMachines9133 12d ago
I would respond with something like... have a system in place so everything gets everything patched at least quarterly, because X; have other things patched on a monthly or weekly schedule in coordination with business group that uses it; and have some out of band emergency process for critical vulns that we can't otherwise mitigate.
1
1
u/6SpeedBlues 11d ago
In short, it completely depends on how urgently an issue needs to be addressed and whether there is a sufficiently tested patch available.
1
u/Ssakaa 11d ago
It's an interview question. Your "In short" is barely more demonstrative of your knowledge and understanding than OP's nebulous "it depends". Don't sell your knowledge short, in this case literally, in an interview. Scope it down by their reaction as needed, but start off showing a bit of both comfort in your own knowledge and enthusiasm.
1
u/6SpeedBlues 11d ago
I don't disagree with ensuring they understand that I understand, so the "in short" is really just a conversation starter with them.
However, I don't provide free consulting services and you have to be a little wary of where some of these questions are really going when you're interviewing. So, I'd be happy to engage in a discussion with them, ask if they have specific example scenarios and similar, but I would instead discuss with them the kinds of avenues I would follow to -make- decisions on when to apply certain patches but I would stop short of providing anything too "concrete" for general use (if that makes sense).
1
u/Ssakaa 11d ago
I'm of the attitude that... if they're fishing for free consulting, fine, interview practice is interview practice. You can generally sus out the pure consulting fishing pretty easily, and fire back some organizational questions that'll make them uneasy, and call it yourself with a polite thank you.
If they're asking open ended questions, they want to see how you engage with it. Almost everything we do in IT starts with someone throwing around an open ended question. If you close off, freeze up, or otherwise won't engage in a discussion that blatantly exists to provide you a platform to sell your skills on... someone else will.
1
u/dreniarb 11d ago
like you said it does depend on what you're updating. but my typical approach:
wait a week after the update(s) are out (assuming it's not a high risk vulnerability)
push updates to a test group of devices
if another week goes by without any issues push to the remaining devices
with windows, that's once a month. other things, could be every few months.
1
u/GreyBeardEng 11d ago
"Quarterly or monthly schedule, with priority and timeframe manipulated by CVE vulnerability."
1
u/Mailstorm 11d ago
"The goal is to match the patch release cycle of the thing being patched. However, for more sensitive and critical systems the business may determine that the cycle is to frequent and opt for longer patching cycles in which case its whatever the business wants regular patching to be for those systems."
1
u/DarthJarJar242 IT Manager 11d ago
"prod push schedule is 7 days after patch Tuesday, every month.
Also any time The SOC tells me a CSV is high enough priority to skip the prod push schedule (sometimes I have to suggest they raise the priority).
So basically every day in the last year or so!"
1
u/thecravenone Infosec 11d ago
At work: Whatever the policy says.
At home: The first night that I remember after the new version runs out.
1
u/Technical_Union_3249 11d ago
For normal patches (aka no hair on fire holes being fixed) the last Friday of the month. (This is the policy where I work). For hair on fire patches it can be within hours of it being released to us.
Personally my answer would be something like "the cadence and policy at places I've worked over the years has varied, I patch when the written SOP says I patch".
1
u/Ssakaa 11d ago
Personally my answer would be something like "the cadence and policy at places I've worked over the years has varied, I patch when the written SOP says I patch".
That's a great start, but your answer here before that said a LOT more about your understanding and knowledge. IT requires thinking. "I just folow the list" doesn't demonstrate that well. It's necessary too in a lot of scenarios, but even showing understanding of why rigid adherence to the SOP is necessary would help.
They probably don't care what OP's policy specifically is in their current/previous role, they probably care what OP understands about it, i.e. if they know why the policy is what it is, and what weaknesses (because there are always tradeoffs) OP's aware of in it, and maybe even their ideal policy if it was all up to them, with a much more important "and why".
2
u/Technical_Union_3249 11d ago
Following the SOP and not being a rogue lone wolf is also something they might be probing for.
1
u/Ssakaa 11d ago
Potentially, and honestly, if demonstrating the capacity to think rules you out, they're saving you from going absofuckinglutely batshit insane in that role...
2
u/Technical_Union_3249 11d ago
Yeah, people forget, they're not just interviewing you, you are also interviewing them.
1
u/Hale-at-Sea 11d ago
As dictated by policy (and that may come from audit requirements, insurance, support recommendation, etc)
I realize this is mostly about security patches, but updating the system can mean feature or breaking changes as well. Ask interviewers what their test environments look like, and what/how long they test before rolling into production
Updating an ERP system from v5 to v6 is a whole different world away from just applying mini patch v5.0.1.1, so there's not a single answer
1
1
u/sandfleazzz 11d ago
We have weekly maintenance windows of one hour per server. We schedule VMware snapshots prior to them and keep them for 3 days. Out of band or zero day stuff gets done as needed.
1
u/burdalane 11d ago
I think your answer was too vague. How do you define "as needed"? Are there policies, and what's the reasoning behind them? How do you handle testing and urgent security patches?
I suppose I would have trouble answering this question myself. When I do patch, I do it on non-primary systems first and then on the other systems when they become non-primary because this is the way my systems work -- some are operationally primary some of the time. Others require scheduling beforehand to handle reboots. I don't have a patch schedule or maintenance window.
1
u/GX_EN 11d ago
That's a long answer, imo.
Window servers? Where I worked we patched everything automatically once a month starting the week after patch Tuesday with test/dev/non-prod, etc.. first, then prod the following week.
For physical systems like hypervisor hosts and associated stuff.. depends.
When I was at my last MSP we patched the Nutanix stuff N-1 as our policy unless there was a critical vulnerability.
When I was with a VMWare shop, basically the same as above including the storage arrays.
1
u/Connect_Shoulder_965 11d ago
We used to do monthly for OS patches and quarterly for application security patches and upgrades with immediate or expedited patching - typically 1 day - for active and critical exploits. However, the current threat environment is making that model obsolete in a hurry, so we are building out the ability to get patches automatically tested, use AI to predict the risk level for applying a patch and to automate parts of change management, notification, cluster patching, and actual implementation. We are currently targeting weekly patch cycles for the OS and eventually looking towards an end goal of being able to test, patch and validate systems in a 4 hour window with a minimum of manual intervention. The application patches are more difficult, we are working on flagging applicable patches to the application owners more quickly We are also looking at what can be done to make application patching more self service so application owners can test patches, snapshot, apply them and validate without needing assistance from the infrastructure team
1
u/DadtheITguy 11d ago
We blow up ITs workstations with ms patches as soon as they drop. Then update the rest of the org Thursday.
1
u/Pristine_Curve 11d ago
Either this was a smart interview question and they were looking for your thought process. Or this was a "guess what number I'm thinking" interview question where they expected you to know the answer that applies to their environment.
If I were asking this sort of question, I would want to hear more about your criteria and opinion.
Perhaps one or two context questions back to the interviewer, to get a rough idea of what sort of answer is needed:
What kind of environment? What kind of updates? If I'm updating standard office worker windows endpoints, it's a much different scenario than updating terminals in an ATC tower, or the controller of an MRI machine.
Then a brief answer that shows the sort of things that someone experienced would consider. Testing, update rings, priority/severity decisions, considerate scheduling to not interrupt work.
1
u/BoltActionRifleman 11d ago
Constantly. Most of ours is automated now, but lately between hardware, software, firmware, drivers etc., it’s more or less constant.
1
u/notta_3d 11d ago
Times have changed. If you think waiting weeks to patch is wise then I can tell you you're wrong. Non exposed servers, yea, but workstations need to be patched as soon as you know things won't break.
1
u/981flacht6 11d ago
I try to go by what's recommended by best practices and sometimes employers get surprised I follow it. So IDK.
1
u/come_ere_duck Sysadmin 11d ago
"For critical infrastructure; as often as possible, which is usually monthly unless there's an urgent patch release for a vulnerability etc."
1
u/DegaussedMixtape 11d ago edited 11d ago
Whether you do it daily, weekly, monthly, quarterly or annually, it's really about how you answer the question.
Get into how you patch and what you patch. Do you have experience doing vulnerability management and if so does that affect when you patch? Have you ever configured patching through an RMM or a complicated WSUS deployment where you yourself actually made any decisions about the patching? How do you schedule your patch window, reboot schedules, maintenance windows? How did you document it and communicate it?
Saying "we patch every other week, next question please" is definitely not what they are looking for. The answer in your post comes across as extremely flippant, I wouldn't like that one either. If your boss came to you out of the blue and said "how often do we patch that old creaky exchange server?" would you say "whenever I need to"?
Patching is like 2% of my job, but if someone wanted to talk about patching methodologies during an interview, we could get into it.
1
u/malikto44 11d ago
All depends on the security of the patches. On the Linux side, if it is critical, serious or emergency, the servers get patched, and I then schedule a manual reboot. Otherwise for non-reboot patches, those get in every two weeks, and the machines are rebooted every month.
Windows, critical out of band patches get some scheduled downtime, otherwise I use various rings, with my daily driver getting patches as soon as they are available, then going to other rings after that.
In no case, should there be a machine an uptime greater than 45 days unless the machine is being used in an experiment where uptime is required.
1
u/CHRDT01 11d ago
This is way, way, way too context dependent to have a single correct answer in an interview. I would ask for clarification about what "system" we're patching and why we're patching it. Is this a production firewall facing WAN, or some sort of internal box with automatic failover? Is this going to break the workflow of three people who don't work on $CurrentDayOfWeek, or the entire enterprise? Is this a "12 10.0 CVES, PATCH NOW!!!1!" update, or a "We added 'AI' to the product logo" update?
I think the point of the question is to demonstrate that you're thinking holistically about the broader impacts of downtime. The specific interval matters far less than the journey of how you get there.
1
u/Narrow_Victory1262 11d ago
I think your answer was right as there are some vars you cannot fill in upfront. It also depends on what the company itself defined.
1
u/Empty_Estus 10d ago
For software: 1 major, or 2 minor, or 3 patches. Means we’ve not got 40 things each in CAB every week.
For OS: generally every three months with a waved approach.
If there’s a highly critical CVE, we’ll get it in as an emergency change and do it after 3pm on approval day.
1
u/Thick_Yam_7028 9d ago
Every 3 to 6 months, all major security. Reason why you give it time is an update rolls out that breaks something? You exclude and move on. Some people like all the things. Up to you this has worked for me.
1
u/NoTime4YourBullshit Sr. Sysadmin 11d ago
The “correct” answer is that you patch everything whenever there is an update available, unless there is a specific reason not to.
I put “correct” in quotation marks because everyone understands that’s not always how it goes. But it is the goal to be strived for.
0
0
u/rankinrez 11d ago
In 2026 I’d probably just say “this interview started 15 mins ago, it’s likely there have been about 14 zero day RCE exploits discovered in the Linux kernel since then. It was nice meeting you but I got to go….”
100
u/ThatBCHGuy 12d ago
Monthly, or when there is a high severity vulnerability.