SY0-701 Security Operations Practice Question
A Linux host is patched, but the scanner still flags the package as vulnerable. The vendor advisory says the distribution backported the fix, so the package version did not change. What should the analyst do before closing the ticket?
⚠ Common exam trap
Watch out — candidates often assume a patched system always has a newer package version, but CompTIA tests the understanding that backported fixes keep the same version string, requiring manual verification of the changelog or vendor advisory.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify the vendor advisory and package metadata, then document evidence of the fixed build.
When a vendor backports a security fix to an older package version without incrementing the version number, the vulnerability scanner may still flag the package based on its version string. The analyst must verify the vendor advisory and package metadata (e.g., using `rpm -q --changelog` or `dpkg --status`) to confirm the fix is present, then document this evidence to close the ticket with proper justification.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Verify the vendor advisory and package metadata, then document evidence of the fixed build.
Why this is correct
A version number alone can be misleading when a vendor backports a fix without changing the upstream version. The analyst should confirm the remediation using vendor notes, package release metadata, or other authoritative evidence. That ensures the finding is truly remediated before the ticket is closed and prevents a false assumption based only on a scanner result.
- ✗
Close the ticket immediately because the patch was installed successfully.
Why it's wrong here
A successful package install transaction only proves dpkg/rpm recorded the package as present; it does not prove the vulnerability is actually undone. Vendors often backport security fixes to older package versions without bumping the visible version string, so the binary can be patched while scanner-based version matching still flags the old CPE. For kernel or daemon fixes, the running process must also be restarted or reloaded; otherwise the old vulnerable code remains resident even though the on-disk package is new. Treat install success as a prompt for verification, not as remediation evidence.
- ✗
Raise the severity of the finding because the scanner still reports it.
Why it's wrong here
Raising the finding's severity converts an unvalidated false positive into a fabricated risk decision and can distort stakeholder priorities. Severity should be derived from CVSS v3/v4 metrics, reachability, and compensating controls — not from the scanner's continued flag after an attempted patch. If the underlying flaw is genuinely unfixed, you must first prove that with package metadata or an exploitability test; otherwise you are escalating noise instead of characterizing a real exposure.
- ✗
Disable the scanner until the next maintenance window to avoid repeated alerts.
Why it's wrong here
Disabling the scanner until the next maintenance window removes the alert from the dashboard rather than explaining why the package is still flagged, and it may violate change-management or compliance requirements to maintain scanning coverage. If the flag is a false positive, the correct action is to tune the scanner's plugin or CPE matching after you have captured evidence of the fixed build. Hiding repeated alerts also makes it more likely the finding is forgotten and leaves the organization unaware if the scanner remains disabled after the window.
Go deeper
Related to this question
Learn chapter
Patch and Vulnerability Management
Key term
Security
Security in IT is the practice of protecting systems, networks, and data from unauthorized access, damage, or theft.
Key term
Vulnerability
A vulnerability is a weakness in a system, network, or software that could be exploited by a threat to cause harm or unauthorized access.
About these practice questions
This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.