The short version: Security+ vulnerability management questions usually test judgment, not trivia. Know how to read a scan result, rank risk, choose a remediation path, handle business exceptions, and prove the fix worked. The exam loves scenarios where “patch everything immediately” sounds safe but is not the best operational answer.
If you are studying for Security+, vulnerability management sits right between technical security and real workplace process. You need to understand scanners, CVSS, asset criticality, patch windows, compensating controls, change management, false positives, and the difference between finding a weakness and actually reducing risk.
Use these practice questions as a scenario drill. Read the situation first, pick the answer, then read the explanation. If you can explain why the wrong answers are tempting, you are much closer to exam-ready than someone memorizing acronyms at 1 AM.
For a broader cert path, pair this with the Security+ study plan template, the Security+ incident response practice questions, and the Security+ risk management practice questions.
Quick vulnerability management cheat sheet
| Scenario clue | Likely concept |
|---|---|
| Scan finds missing patches or misconfigurations | Vulnerability scanning |
| Score includes exploitability and impact | CVSS |
| Important system cannot be patched yet | Compensating controls or exception process |
| Scanner reports something that is not actually vulnerable | False positive |
| Patch caused trouble in production before | Test and change management |
| System is public-facing and exploited in the wild | Prioritize remediation fast |
| Vendor has no patch available | Mitigation, isolation, monitoring, or workaround |
| Fix was applied but needs proof | Rescan or validation |
The exam usually rewards a risk-based process: identify, prioritize, remediate or mitigate, validate, document, and keep improving. It does not reward panic-clicking every patch button in sight.
Question 1: Critical vulnerability on a public server
A vulnerability scan finds a critical remote code execution vulnerability on a public-facing web server. The vendor has released a patch, and active exploitation is being reported. What should the security team do first?
A. Wait until the next quarterly maintenance window
B. Prioritize emergency remediation through the change process
C. Disable all vulnerability scans until the server is patched
D. Mark the finding as accepted risk because the server is monitored
Answer: B. Prioritize emergency remediation through the change process.
Public-facing, critical, remotely exploitable, and actively exploited is the exam’s way of screaming, “do not sit on this.” That does not mean cowboy patching with no notes. It means using the emergency change path, communicating impact, backing up if needed, applying the patch, and validating afterward.
A normal maintenance window may be too slow. Monitoring helps, but it does not remove the vulnerability. Turning off scans is just putting tape over the check engine light.
Question 2: High CVSS score on a low-value lab host
A scanner rates a vulnerability as high severity on an isolated lab machine with no sensitive data and no production connectivity. A medium vulnerability is also found on a domain controller. What is the best next step?
A. Fix the high CVSS vulnerability first because the score is higher
B. Fix the domain controller issue first if asset criticality makes it higher risk
C. Ignore both vulnerabilities until the next annual audit
D. Delete the lab host without telling anyone
Answer: B. Fix the domain controller issue first if asset criticality makes it higher risk.
CVSS matters, but it is not the whole story. Asset value, exposure, business impact, exploit availability, and compensating controls affect priority. A medium issue on a domain controller can be more urgent than a high issue on an isolated test box.
Security+ wants you to think in risk, not just severity labels. Severity is a strong signal. Context decides the queue.
Question 3: Patch breaks a business application
A recent operating system patch fixes an important vulnerability, but testing shows it breaks a business-critical application. The application owner says the system cannot be patched this week. What is the best response?
A. Do nothing because the application owner refused the patch
B. Create a documented exception, apply compensating controls, and set a review date
C. Patch anyway without telling the business owner
D. Remove the system from the vulnerability report
Answer: B. Create a documented exception, apply compensating controls, and set a review date.
Real vulnerability management is full of annoying tradeoffs. If a patch cannot be applied immediately, the risk still exists. Document the exception, get the right approval, add temporary controls, monitor the system, and set a deadline to revisit.
Compensating controls might include network isolation, firewall rules, endpoint controls, disabling the vulnerable feature, extra logging, or vendor workaround steps. The key is that “not patched” becomes a managed risk, not a forgotten shrug.
Question 4: False positive in a scan
A scanner reports that a server is vulnerable because it detects an old software banner. The admin confirms the software was backported by the vendor and includes the security fix, even though the version string still looks old. What should the team do?
A. Treat it as a confirmed vulnerability forever
B. Validate the finding, document evidence, and mark it as a false positive if appropriate
C. Disable the scanner permanently
D. Reinstall the operating system immediately
Answer: B. Validate the finding, document evidence, and mark it as a false positive if appropriate.
Scanners are useful, not magical. They can flag version strings without understanding vendor backports, configuration details, or environment-specific mitigations. The right move is to validate the finding and keep evidence.
Do not ignore scanner results just because one finding was wrong. Also do not blindly open emergency tickets for every banner match. Mature teams verify.
Question 5: Vulnerability with no patch available
A vendor announces a serious vulnerability in a product your company uses, but no patch is available yet. The affected service is internal but reachable from most user subnets. What should you recommend?
A. Wait silently until the vendor releases a patch
B. Apply mitigations such as restricting access, disabling vulnerable features, monitoring, or vendor workarounds
C. Publicly disclose your internal architecture
D. Close the finding because there is no patch
Answer: B. Apply mitigations such as restricting access, disabling vulnerable features, monitoring, or vendor workarounds.
No patch does not mean no action. You may be able to reduce attack surface, limit who can reach the service, disable a risky component, increase logging, add detection, or apply a vendor workaround.
This is where vulnerability management overlaps with network segmentation and incident readiness. If the service does not need to be reachable from every user subnet, do not leave it that way just because the patch is not ready.
Question 6: Scan credentials failed
A vulnerability report shows very few findings on a Windows server group. The security analyst notices the scan used unauthenticated checks because the scanner credentials failed. What is the best interpretation?
A. The servers are definitely secure
B. The scan may be incomplete and should be fixed before trusting the results
C. Unauthenticated scans are always illegal
D. The servers should be decommissioned immediately
Answer: B. The scan may be incomplete and should be fixed before trusting the results.
Authenticated scans usually see more detail: installed patches, local configuration, services, and software inventory. If credentials fail, the scan may miss important vulnerabilities.
Security+ may phrase this as “low findings after a broken scan.” The safe answer is not “great, no problems.” The safe answer is to fix the scan method and rerun it.
Question 7: Remediation versus mitigation
A team disables a vulnerable service on a server because the feature is not used. Which term best describes this action?
A. Mitigation
B. Phishing
C. Federation
D. Tailgating
Answer: A. Mitigation.
Remediation removes the vulnerability, often by patching or configuration correction. Mitigation reduces risk without necessarily removing the underlying vulnerability. Disabling an unused vulnerable service can be a strong mitigation and sometimes a complete configuration fix, depending on the finding.
The exam cares about this distinction because real environments do not always get perfect fixes immediately.
Question 8: Vulnerability exception request
A department asks for a six-month exception for an unpatched system because replacing it will take time. What should the security team require?
A. A business justification, risk owner approval, compensating controls, and an expiration date
B. A verbal promise that the system is important
C. No documentation, because exceptions are temporary
D. Removing the system from asset inventory
Answer: A. A business justification, risk owner approval, compensating controls, and an expiration date.
Exceptions are not blank checks. They need ownership, justification, controls, and review. Otherwise “temporary” turns into “we found this during next year’s audit and nobody remembers why it exists.”
A good exception says what is vulnerable, why it cannot be fixed yet, who accepts the risk, what reduces exposure, and when the exception expires.
Question 9: Proof that a fix worked
An admin says a vulnerable package was updated on several Linux servers. What is the best way for the security team to confirm closure?
A. Trust the update note and close every finding
B. Validate with a rescan or other evidence showing the vulnerable version/configuration is gone
C. Delete the vulnerability management ticket
D. Wait for an attacker to prove it
Answer: B. Validate with a rescan or other evidence showing the vulnerable version/configuration is gone.
Closure needs evidence. A rescan, package inventory, configuration output, or endpoint management report can prove the vulnerable state changed. The exact method depends on the environment, but “someone said it was fixed” is weak.
This is also good help desk behavior. If you fix a recurring issue, verify the actual condition instead of closing because you performed a task.
Question 10: Prioritizing a patch queue
A small IT team has limited patching time this week. Which vulnerability should usually be prioritized first?
A. Low-severity vulnerability on an internal printer
B. Critical vulnerability on an internet-facing VPN appliance with known exploitation
C. Medium vulnerability on a disconnected training laptop
D. Informational finding about a test server banner
Answer: B. Critical vulnerability on an internet-facing VPN appliance with known exploitation.
Internet-facing remote access systems are attractive targets. Add critical severity and known exploitation, and that item jumps to the front of the line.
This does not mean the other findings disappear. It means the queue starts with the risk most likely to hurt the organization soon.
Common Security+ vulnerability management traps
Trap 1: treating CVSS as the only priority
CVSS is useful, but Security+ questions often add context for a reason. Public exposure, exploit activity, asset importance, sensitive data, and business dependency matter. Read the whole scenario before choosing.
Trap 2: confusing mitigation with remediation
Patching usually remediates. Blocking access, disabling a service, adding monitoring, or using a workaround usually mitigates. Both can be valid, but they are not always the same thing.
Trap 3: accepting exceptions with no owner
If nobody owns the risk, nobody will fix it later. Exceptions should have an approver, business reason, compensating controls, expiration date, and review process.
Trap 4: believing every scan result blindly
Scanners can miss findings when credentials fail. They can also report false positives. The mature answer is validation, not blind trust or blind dismissal.
Trap 5: forgetting change management
Security urgency does not erase operations. Emergency changes still need communication, rollback planning where possible, documentation, and validation. The exam likes answers that balance speed with control.
How to study this topic without getting lost
Use a simple loop: identify, prioritize, remediate or mitigate, validate, document. Apply that to VPN appliances, old servers, SaaS findings, workstations, and unsupported software.
For adjacent practice, review Security+ access control practice questions for identity-related scenarios and A+ Windows command line practice questions for operational troubleshooting reps.
FAQ
Is vulnerability scanning the same as penetration testing?
No. Vulnerability scanning identifies known weaknesses and misconfigurations, often automatically. Penetration testing attempts to validate and exploit weaknesses in a controlled scope. Scanning is usually more routine; pentesting is deeper and more hands-on.
Do I need to memorize CVSS math for Security+?
You should understand what CVSS is for: comparing severity using factors like exploitability and impact. You usually need judgment about priority more than manual score calculation.
What is the safest answer when a patch cannot be installed?
Do not ignore it. Document the risk, get the right approval, apply compensating controls, monitor, and set a review or expiration date. If the system is exposed to serious risk, escalate.
How do I know if a finding is a false positive?
Validate it with evidence: vendor advisory details, installed package info, configuration output, scanner plugin notes, or another trusted tool. Then document why it is not exploitable or not applicable.
Bottom line
Security+ vulnerability management questions reward calm prioritization. Find the weakness, understand the asset, reduce the actual risk, verify the fix, and document the decision. That is less exciting than yelling “patch everything,” but it is how real security work survives contact with production.