Cyber Security Quiz: Vulnerability Scanning Tools
10 questions · exam conditions
0:00
Vulnerability Scanning ToolsQuestion 1 of 10

Administrators patch a confirmed vulnerability on 20 servers. During the validation scan, the finding no longer appears on 18 servers. The remaining two servers time out before the relevant check completes.

Which conclusion is best supported by the validation scan?

The scan supports remediation on 18 servers, while the two timed-out servers remain unverified.
All 20 servers are remediated because the validation report contains no new vulnerability instances.
None of the servers are remediated because a timeout anywhere invalidates the entire scan job.
The two timed-out servers remain vulnerable, while the status of the other 18 is unknown.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Vulnerability Scanning Tools

Practice Vulnerability Scanning Tools in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Vulnerability Scanning Tools, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Administrators patch a confirmed vulnerability on 20 servers. During the validation scan, the finding no longer appears on 18 servers. The remaining two servers time out before the relevant check completes.

Which conclusion is best supported by the validation scan?

  1. The scan supports remediation on 18 servers, while the two timed-out servers remain unverified. (correct answer)
  2. All 20 servers are remediated because the validation report contains no new vulnerability instances.
  3. None of the servers are remediated because a timeout anywhere invalidates the entire scan job.
  4. The two timed-out servers remain vulnerable, while the status of the other 18 is unknown.
Explanation: When interpreting validation scan results, you need to evaluate only what the scan actually confirmed — not what it failed to check. A scan result is meaningful only where the check completed successfully. In this scenario, 18 servers returned clean results, meaning the vulnerability check ran to completion and found no finding. That's genuine, positive evidence of remediation. The remaining two servers timed out — meaning the scanner never finished the relevant check. A timeout isn't a "pass"; it's an absence of data. Those two servers are simply unverified, not confirmed clean or confirmed vulnerable. This makes A the correct conclusion: the scan supports remediation on 18 servers, and the two timed-out servers remain in an unknown state requiring follow-up. B is wrong because it assumes a silent or incomplete result counts as confirmation. If the two servers never completed the check, the report can't logically claim they're remediated — it simply has no data on them. Absence of a reported finding is not the same as a confirmed negative. C is wrong because it over-applies a "chain is only as strong as its weakest link" fallacy. Scan jobs don't invalidate previously completed, successful checks just because a subset of targets failed. The 18 clean results stand on their own merit. D is wrong because it reverses the logic — it treats the 18 confirmed clean servers as unknown while asserting the timed-out servers are confirmed vulnerable. Neither part of that claim is supported by the evidence. Study tip: On security exam questions involving scan results, always ask: "Did the check actually complete?" Incomplete = unverified, not remediated and not vulnerable.

Question 2

A scanner engine is functioning normally, but its vulnerability plugin feed has not been updated for three months. The organization has continued running weekly scans with the same policy.

What is the most significant limitation of the recent reports?

  1. Every existing finding is automatically a false positive because plugin logic becomes invalid after each weekly scan cycle completes.
  2. The reports cannot identify live hosts because host-discovery routines depend entirely on up-to-date vulnerability plugin definitions.
  3. The scanner will lock out all credentialed accounts because outdated plugin feeds trigger an internal authentication reset mechanism.
  4. Recently disclosed vulnerabilities may be missed because the scanner lacks current detection logic for new and updated checks. (correct answer)
Explanation: When you see a question about vulnerability scanners and outdated plugin feeds, focus on what plugins actually do: they contain the detection logic that tells the scanner how to identify specific vulnerabilities. Without current plugins, the scanner is essentially working from an outdated rulebook. This is exactly why D is correct. Vulnerability plugins are updated whenever new CVEs are disclosed or existing checks are refined. A three-month-old feed means any vulnerability discovered in that window — potentially dozens of critical ones — has no corresponding detection logic in the scanner. The scanner runs normally, produces clean-looking reports, and the organization gains false confidence. The scans aren't broken; they're just blind to anything new. Choice A is a fabricated concept. Plugin logic doesn't "expire" after each scan cycle, and existing findings from stable, well-documented vulnerabilities remain valid. Outdated plugins create gaps, not blanket invalidation of prior results. Choice B is similarly fictional — host discovery relies on network-level techniques like ICMP, TCP handshakes, and ARP, none of which depend on vulnerability plugin definitions. The scanner can still find live hosts just fine. Choice C describes a mechanism that simply doesn't exist. Outdated plugin feeds do not trigger authentication resets or account lockouts; that would make vulnerability management tools dangerously unpredictable by design. As a study tip, watch for distractors on security exams that invent plausible-sounding technical mechanisms. A, B, and C each describe consequences that sound technical but have no basis in how scanners actually work. When in doubt, trace the real-world function: plugins = detection logic, nothing more.

Question 3

A company scans the same Linux servers twice. An unauthenticated scan reports only exposed-service findings. A credentialed scan performed one hour later reports those findings plus missing operating-system patches and insecure local configurations. The network and servers were unchanged between scans.

Which explanation best accounts for the difference in results?

  1. The credentialed scan probably installed temporary agents that introduced additional vulnerabilities.
  2. The credentialed scan could inspect local packages and settings that were not observable remotely. (correct answer)
  3. The unauthenticated results are invalid because remote scans cannot identify any real vulnerabilities.
  4. The additional findings are probably duplicates generated when the scanner reused cached service banners.
Explanation: When you see a question comparing unauthenticated and credentialed scans, think about access levels — what information is visible from outside a system versus what requires logging in. An unauthenticated (or "remote") scan sees only what the network exposes: open ports, service banners, and protocol responses. It's essentially a stranger peering through a window. A credentialed scan, however, logs into the system using valid credentials and can read the filesystem, installed package lists, kernel versions, configuration files, and user settings — information that is never transmitted over the network and therefore invisible to a remote probe. This is exactly why B is correct: the credentialed scan revealed missing OS patches and insecure local configurations because it could directly inspect local packages and settings that have no network-facing representation. A is a fabrication. Credentialed scanners authenticate and query the system; they do not install agents or introduce vulnerabilities as a side effect of scanning. This option tries to mislead you with a plausible-sounding but invented mechanism. C is an overstatement and factually wrong. Unauthenticated scans absolutely identify real vulnerabilities — exposed services, unencrypted protocols, and banner-disclosed software versions with known CVEs are all legitimate findings. Remote scans are limited in scope, not in validity. D invents a technical artifact. Scanners may cache data for efficiency, but reusing cached banners does not generate duplicate or new findings of an entirely different category like patch status. A useful rule of thumb: remote scans = attack surface; credentialed scans = internal health. Exam questions will often test whether you understand that these are complementary, not redundant.

Question 4

A production environment contains fragile legacy systems. The scan policy offers authenticated configuration checks, ordinary remote probes, and intrusive denial-of-service tests. Management wants useful coverage while minimizing the chance of an outage.

Which scanning approach best meets the requirement?

  1. Enable every intrusive test immediately because complete coverage is more important than production availability.
  2. Use authorized non-intrusive and authenticated checks, reserving disruptive tests for an approved controlled environment. (correct answer)
  3. Disable all vulnerability checks and rely only on service discovery to avoid any operational risk.
  4. Run intrusive tests anonymously so production systems cannot associate the activity with scanner credentials.
Explanation: When you see a question involving vulnerability scanning in a production environment with legacy systems, your first instinct should be risk-tiering: match the aggressiveness of your tests to what the environment can tolerate. Not all scanning techniques carry equal risk, and responsible security practice means calibrating your approach accordingly. The strongest choice here is B. Authenticated scans and non-intrusive remote probes gather meaningful security intelligence — misconfigurations, missing patches, weak credentials — without sending malformed packets or flooding services. Legacy systems are especially brittle, so you preserve availability while still producing actionable findings. Intrusive tests (like denial-of-service simulations) aren't abandoned entirely; they're simply relocated to a controlled, non-production clone where an outage won't cost the business anything. A is wrong because framing "complete coverage" as more important than production availability is a false trade-off. A scanner-induced outage on a fragile legacy system could cause more damage than the vulnerability it was meant to find. Coverage is never worth guaranteed downtime. C swings too far in the opposite direction. Disabling all vulnerability checks and running only service discovery leaves you nearly blind — you'd know what ports are open but nothing about whether those services are exploitable. That's not a security assessment; it's a network inventory. D introduces a dangerous misconception. Running intrusive tests anonymously doesn't make them less disruptive to the target system — packets that crash a service don't care about credentials. It also bypasses authorization controls, potentially making the activity unauthorized and legally problematic. On security exams, watch for answer choices that present a false binary between complete safety and complete coverage — the correct answer almost always threads the middle path by segmenting risk thoughtfully.

Question 5

During an authorized scan of a corporate subnet, the scanner discovers an active server that is absent from the asset inventory. It reports a critical remotely exploitable vulnerability on the host. The scan authorization covers the subnet but prohibits disruptive testing.

What should the analyst do next?

  1. Launch disruptive exploit checks immediately because the critical severity overrides the testing restriction.
  2. Validate the evidence non-disruptively, identify the asset owner, and initiate the approved response process. (correct answer)
  3. Delete the finding because systems missing from inventory cannot be included in vulnerability reports.
  4. Reclassify the host as an external asset because its ownership is not yet documented internally.
Explanation: When you encounter vulnerability management scenarios on security exams, ask yourself two questions simultaneously: What does the authorization scope allow? and What does responsible disclosure practice require? Both constraints must be respected, even when a finding looks severe. Here, the scan authorization explicitly prohibits disruptive testing, and a critical vulnerability has appeared on an untracked host. The professional response — answer B — is to validate the finding using only non-disruptive techniques (banner analysis, version correlation, additional passive checks), determine who owns the asset through network records, DHCP logs, or IT contacts, and then escalate through your organization's established incident or vulnerability response process. This approach respects the authorization boundary while ensuring the risk is communicated and acted upon appropriately. A is a dangerous misconception: severity level never overrides the legal and ethical boundaries of your testing authorization. Launching disruptive exploits without permission — even against a critical finding — exposes you and your organization to legal liability and potential system damage. Authorization is non-negotiable. C reflects a fundamental misunderstanding of vulnerability management. Unknown or untracked assets are exactly the kind of finding that demands attention — they represent shadow IT, which often carries the highest risk precisely because no one is patching or monitoring them. Deleting the finding would be professionally irresponsible. D is a logical error. Lack of internal documentation doesn't change an asset's physical location or ownership — it just means the inventory is incomplete. Reclassifying it externally without evidence is fabricating a conclusion. Your study takeaway: authorization scope is a hard boundary on every engagement — critical findings increase urgency but never grant permission that wasn't already given.

Question 6

A vulnerability report contains two confirmed findings. Finding 1 has a critical base score but affects an isolated laboratory server with no route from production networks. Finding 2 has a high base score, has a public exploit, and affects an internet-facing gateway that processes customer traffic.

Which remediation decision is most defensible?

  1. Remediate Finding 1 first because a critical base score always overrides environmental conditions.
  2. Remediate both only after the scanner recalculates them to have identical severity scores.
  3. Prioritize Finding 2 because exposure, exploit availability, and business function increase its practical risk. (correct answer)
  4. Prioritize Finding 1 because isolation makes exploitation more likely to remain undetected by the scanner.
Explanation: When you see a vulnerability prioritization question, resist the instinct to rank purely by base score. CVSS base scores measure inherent severity in a vacuum — they deliberately ignore your specific environment. Real-world remediation decisions require layering in contextual factors: network exposure, exploit availability, and the business value of affected assets. Finding 2 checks every box that elevates practical risk. It sits on an internet-facing gateway handling customer traffic, meaning attackers can reach it directly. A public exploit exists, dramatically lowering the skill and effort required to weaponize the vulnerability. Even though its base score is "only" high, the combination of reachability, exploit maturity, and critical business function makes it the most dangerous finding in your environment right now. C is the correct and most defensible choice because it reflects how mature security programs actually operate — using environmental and threat context to translate scores into action. A is the classic trap this question is designed to expose. A critical base score means the vulnerability is severe if exploited, but an isolated lab server with no production route gives attackers no path to it. Isolation dramatically reduces exploitability, so blindly prioritizing by base score wastes resources. B is impractical and backwards — remediation decisions shouldn't be held hostage to score recalculation; you act on available information. D inverts logic entirely: isolation doesn't increase undetected exploitation likelihood, it decreases attacker access in the first place. Your study takeaway: on exam questions about vulnerability prioritization, always ask "can an attacker realistically reach this, and does a working exploit exist?" Those factors override raw severity scores every time.

Question 7

A scanner flags a server because its HTTP banner contains a software version associated with a known vulnerability. The system administrator states that the operating-system vendor backported the security fix without changing the banner's upstream version number.

Which action would best determine whether the finding is a false positive?

  1. Suppress every finding based on version banners because banner checks are inherently unreliable.
  2. Increase the scanner severity so the administrator must replace the server immediately.
  3. Repeat the same unauthenticated scan until the software banner reports a different version.
  4. Compare the installed package revision with the vendor advisory and inspect the scanner's detection evidence. (correct answer)
Explanation: When a scanner flags a vulnerability based purely on a version banner, you're being tested on the concept of false positives in vulnerability management — specifically, how to distinguish between a real vulnerability and an artifact of imprecise detection methods. The key insight is that operating-system vendors (like Red Hat or Debian) routinely backport security patches into older package versions without incrementing the upstream version number shown in banners. The banner says "Version 2.4.1," but the actual installed package might be "2.4.1-3.el8," where that suffix encodes the applied fix. D is correct because it attacks the problem at both ends: you check the installed package's full revision number against the vendor's security advisory (which lists exactly which package revisions contain the backported fix), and you review what evidence the scanner actually used to reach its conclusion. If the installed revision is patched and the scanner relied only on the banner string, you have confirmed a false positive with documented evidence — which is what proper vulnerability triage requires. A is wrong because it overcorrects dangerously. While banner checks can produce false positives, wholesale suppression means you'd miss real vulnerabilities flagged by banner evidence. That's a policy failure, not a solution. B is wrong because increasing severity doesn't verify anything — it just escalates noise into crisis without gathering facts. C is wrong because re-running an unauthenticated scan cannot reveal backported patches; the banner will never self-report a different version, so you'd loop indefinitely without resolution. Your takeaway: whenever you see "false positive" questions, look for the answer that gathers evidence specific to the detection method used rather than suppressing, escalating, or repeating the same flawed check.

Question 8

A general network vulnerability scan of an application server reports no critical findings. The scan tested common ports without application credentials. A later review shows that a custom web application on an uncommon port requires login and may expose other users' records when object identifiers are changed.

Which next step most directly addresses the remaining assessment gap?

  1. Accept the clean report because authorization flaws always produce a critical network-scanner finding.
  2. Repeat only the common-port scan from another subnet to confirm that the operating system is reachable.
  3. Perform an authorized authenticated web-application assessment against the custom port and relevant user roles. (correct answer)
  4. Run a credentialed patch scan of the operating system because missing packages cause all record-access flaws.
Explanation: When you see a scenario where a general scan returns clean results but a specific application remains untested, you're being asked to recognize the gap between network-layer scanning and application-layer security assessment. These are fundamentally different activities, and a clean network scan says nothing about whether a web application properly enforces authorization controls. The vulnerability described — changing an object identifier (like a user ID in a URL) to access another user's record — is a classic Broken Object Level Authorization (BOLA/IDOR) flaw. Detecting this requires an authenticated tester who can actually log in, manipulate requests, and compare what different user roles can access. A network scanner probing common ports with no credentials cannot discover this; it never touched the custom port or the application's logic. Option C directly closes that gap by specifying an authorized, authenticated, application-level assessment targeting the correct port and the relevant roles — exactly the conditions needed to surface authorization flaws. A is wrong because it contains a false premise: IDOR and authorization vulnerabilities routinely go undetected by network scanners, which don't understand application logic. Accepting a clean report here would be a genuine security failure. B is wrong because rescanning common ports from a different subnet tests network reachability and firewall rules — not the custom-port application or its access controls. D is wrong because missing OS patches and object-level authorization are entirely separate issue classes; a credentialed patch scan evaluates installed software versions, not whether the application checks user permissions correctly. Your study tip: whenever a question pairs "network scanner found nothing" with "application has a logic flaw," the answer almost always involves moving to an authenticated, application-layer test — because scanners see ports and versions, not broken business logic.

Question 9

A credentialed scan targets 100 workstations. The report shows successful authentication to 85 systems. The other 15 systems report only a few remotely observable findings and no local patch information.

How should the analyst treat the 15 systems?

  1. Mark them compliant because the scanner did not identify missing local patches on those systems.
  2. Remove them from scope because authentication failure means they are not active network assets.
  3. Record a coverage gap and troubleshoot credentials or access before drawing conclusions about patch status. (correct answer)
  4. Assume they are fully compromised because failed scanner authentication proves hostile credential changes.
Explanation: When evaluating credentialed scan results, you need to distinguish between "the scanner found nothing wrong" and "the scanner was unable to fully assess the system." These are very different situations, and confusing them is one of the most common mistakes analysts make. In a credentialed scan, the scanner authenticates locally to each target, allowing it to inventory installed patches, running services, and configuration details invisible from the network. When authentication fails on those 15 systems, the scanner falls back to a remote-only perspective — essentially blind to anything requiring local access. That means you have incomplete data, not clean data. C is correct because the professional response is to flag the coverage gap and investigate the root cause (wrong credentials, firewall rules, disabled services, locked accounts) before making any statement about those systems' patch posture. You simply cannot conclude anything about local vulnerabilities you never examined. A is dangerously wrong — it confuses absence of evidence with evidence of absence. The scanner didn't find missing patches because it couldn't look, not because the patches are present. B is wrong because authentication failure says nothing about whether a system is active; the scanner clearly reached those systems (it observed remote findings). D overcorrects in the opposite direction — a failed authentication could mean a misconfigured credential or a policy restriction, not a hostile takeover. A useful rule of thumb for the exam: whenever scan coverage is incomplete, the correct answer almost always involves documenting the gap and investigating further rather than drawing a positive or negative conclusion from missing data. Incomplete scans produce incomplete answers.

Question 10

An internal vulnerability scanner detects a vulnerable HTTPS service on a server. A scanner located on the public internet does not detect the service. The security team is trying to determine whether customers can reach the vulnerable service.

What is the best interpretation of these results?

  1. The external scanner lacked a reachable path during the scan; internet exposure should be checked against routing and filtering controls. (correct answer)
  2. The internal finding must be a false positive because a genuinely vulnerable service is visible from every scanner location.
  3. The server is fully protected because one external scan did not detect its HTTPS service.
  4. The public scanner automatically remediated the service before completing its vulnerability checks.
Explanation: When a vulnerability scanner finds a service internally but an external scanner misses it, you're being tested on network segmentation, access controls, and what scanner results actually tell you. The key insight is that a scan result only reflects reachability from that scanner's vantage point — it says nothing definitive about what customers on the internet can or cannot reach. Choice A is correct because it accurately captures this limitation. The external scanner may have failed to detect the HTTPS service due to firewall rules, routing restrictions, network address translation, or other filtering controls blocking its path to the server. To truly determine customer exposure, the security team must cross-reference scanner results with actual network topology — examining firewall policies, routing tables, and ACLs to confirm whether inbound customer traffic can reach that service. Choice B is a dangerous misconception. A genuine vulnerability doesn't need to be visible from every scanner location. Services can be legitimately segmented so that only internal scanners can reach them. Dismissing an internal finding as a false positive simply because an external scanner missed it is exactly the kind of reasoning that leads to unaddressed vulnerabilities. Choice C represents overconfidence in a single scan. One external scan not detecting a service is not proof of protection — it only means the scanner couldn't reach it from that position. The service may still be reachable through other paths. Choice D describes something scanners simply don't do. Vulnerability scanners are passive detection tools; they identify weaknesses but never modify or remediate services during a scan. Study tip: On security exams, always ask from where a scan was conducted. Scanner results are vantage-point-dependent — treat them as partial evidence, not absolute truth about network exposure.