Cyber Security Quiz: Vulnerability Prioritization
10 questions · exam conditions
0:00
Vulnerability PrioritizationQuestion 1 of 10

A remote-management vulnerability was previously assigned low priority because the affected interface was available only on a private operations network. During an emergency continuity change, the organization publishes the interface through a network address translation rule so contractors can connect from the internet. Multifactor authentication is not enabled, and the vendor reports active exploitation of the same vulnerability. The underlying asset and technical impact have not changed.

How should the vulnerability's priority change?

Decrease because publishing the interface through address translation obscures the asset's internal network address
Remain unchanged because vulnerability priority should be based on the original scanner score and affected software
Increase sharply because external exposure and current exploitability increased even though technical impact remained constant
Remain low because only a change in business impact can justify reprioritizing an existing vulnerability
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Vulnerability Prioritization

Practice Vulnerability Prioritization 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 Prioritization, 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

A remote-management vulnerability was previously assigned low priority because the affected interface was available only on a private operations network. During an emergency continuity change, the organization publishes the interface through a network address translation rule so contractors can connect from the internet. Multifactor authentication is not enabled, and the vendor reports active exploitation of the same vulnerability. The underlying asset and technical impact have not changed.

How should the vulnerability's priority change?

  1. Decrease because publishing the interface through address translation obscures the asset's internal network address
  2. Remain unchanged because vulnerability priority should be based on the original scanner score and affected software
  3. Increase sharply because external exposure and current exploitability increased even though technical impact remained constant (correct answer)
  4. Remain low because only a change in business impact can justify reprioritizing an existing vulnerability
Explanation: When assessing vulnerability priority, you need to think beyond the static technical score and consider the full risk equation: likelihood × impact. Technical impact (what damage exploitation causes) is only one variable. Exposure and exploitability — how reachable and actively targeted the vulnerability is — are equally critical inputs. In this scenario, the technical impact hasn't changed, but two major risk factors shifted dramatically: the interface moved from a private network to the public internet, and active exploitation is now confirmed by the vendor. Both changes make a successful attack far more probable. This is precisely why C is correct — external exposure and confirmed exploitability are legitimate grounds for sharply increasing priority, even when the underlying asset and technical impact remain constant. A is wrong because NAT does not provide meaningful security. Hiding an internal IP address behind a translated public address does nothing to prevent an attacker from reaching and exploiting the published interface — the vulnerability is just as accessible. B reflects a common misconception: that the original scanner score is the final word on priority. Scanner scores capture technical severity at a point in time, but they don't account for changes in exposure or real-world exploitation status. Treating scores as immutable ignores dynamic threat context. D is a trap because it inverts the logic. Business impact can drive reprioritization, but it isn't the only factor. Threat context — especially confirmed exploitation in the wild — independently justifies raising priority. Your study takeaway: on risk and vulnerability management questions, always ask yourself whether exposure, exploitability, or business impact has changed. Any one of these can override a static severity score.

Question 2

A backlog contains four unpatched findings. An eight-year-old high-severity flaw affects an internet-facing payment tokenization service and has a reliable public exploit. A newly disclosed critical flaw affects a segmented test server containing synthetic data and requires access from the test administrator subnet. A recently disclosed high-severity flaw affects a public marketing site but only permits modification of temporary cached content. A critical flaw with no known remote vector affects an offline forensic workstation used under direct supervision.

Which finding should be placed first in the remediation queue?

  1. The marketing-site flaw because public content modification is automatically more urgent than payment-service compromise
  2. The test-server flaw because newly disclosed critical vulnerabilities should precede older high-severity vulnerabilities
  3. The payment-service flaw because reliable exploitation, public exposure, and payment-system impact outweigh its age and rating (correct answer)
  4. The forensic-workstation flaw because a critical base rating should take precedence over remote reachability and operating state
Explanation: When prioritizing vulnerability remediation, you must weigh multiple risk factors together rather than relying on any single attribute. The key dimensions are: exploitability (is there a reliable public exploit?), exposure (is the asset internet-facing?), impact (what data or function is at risk?), and compensating controls (are there mitigating factors like network segmentation or offline status?). The payment-service flaw in choice C wins on nearly every dimension simultaneously. It has a reliable public exploit, meaning exploitation requires minimal attacker skill. The service is internet-facing, meaning no internal access is required. And it protects payment tokenization, placing it squarely in scope for financial and regulatory harm. Its age actually reinforces urgency — it has been exploitable for eight years, meaning the window of risk is already massive, not shrinking. Choice A is wrong because public content modification of temporary cached data on a marketing site represents low-impact, easily reversible damage. "Public-facing" alone does not automatically elevate severity above a payment-system compromise. Choice B falls into the trap of treating recency as a proxy for urgency. The test server is segmented, contains only synthetic data, and requires access from a restricted subnet — three compensating controls that dramatically reduce real-world risk despite the critical CVSS rating. Choice D makes the opposite mistake: it treats a high base CVSS score as the deciding factor. The forensic workstation is offline, supervised, and lacks a remote attack vector — environmental context reduces effective risk to near zero regardless of the base rating. Your study tip: CVSS base scores measure theoretical severity in isolation. Always apply environmental and temporal metrics — exposure, exploitability, and compensating controls — before finalizing remediation priority.

Question 3

A public web gateway contains an exploitable server-side request forgery flaw. The flaw lets an unauthenticated attacker send requests to several otherwise isolated administrative services. One such service has a critical command-injection vulnerability, while the others expose sensitive configuration functions. Engineers can safely patch either the gateway flaw or the command-injection flaw during the current window, but not both.

Which remediation should be performed first to maximize immediate risk reduction?

  1. Patch whichever flaw has existed longer because vulnerability age is the best proxy for successful exploitation
  2. Patch the command-injection flaw because critical impact always outweighs the gateway's broader attack-path role
  3. Patch neither flaw because fixing only one component cannot eliminate every possible administrative-service weakness
  4. Patch the gateway flaw because it removes the external path to multiple isolated administrative services (correct answer)
Explanation: When assessing which vulnerability to patch first, think in terms of attack chains: most real-world exploits require multiple steps, and eliminating an early link in that chain blocks every downstream path simultaneously. Here, the SSRF flaw in the public gateway acts as the sole external entry point into the isolated administrative network. Patching the gateway (D) severs the attacker's ability to reach all administrative services at once — the command-injection target, the sensitive configuration endpoints, and any vulnerabilities that haven't even been discovered yet. One fix, maximum coverage. Why the distractors fail: A is wrong because vulnerability age is a poor prioritization metric — what matters is exploitability, exposure, and impact, not how long a flaw has existed. A newly disclosed flaw can be far more dangerous than an old one. B tempts you with the logic that "critical severity = fix first," but this ignores architectural reality: if the command-injection flaw is only reachable through the gateway, patching it while leaving the gateway open still exposes every other administrative service to a now-unobstructed attacker. Severity ratings describe potential damage, not strategic priority. C is a classic all-or-nothing fallacy — partial remediation meaningfully reduces risk even when it can't eliminate it entirely. Refusing to act because you can't fix everything is not a valid security strategy. Study tip: On security exam questions involving multi-stage attack paths, always ask yourself "which fix collapses the most attack routes?" Patching a prerequisite vulnerability (a chokepoint) almost always outperforms patching a downstream one, regardless of individual severity ratings.

Question 4

A remediation team must select one vulnerability for an emergency change window. Finding Alpha is an unauthenticated remote-code-execution flaw on an internet-facing customer identity service; exploitation attempts matching the flaw are appearing in application logs, and compromise could expose authentication tokens. Finding Bravo has a higher CVSS base score on an internal backup controller, but it is reachable only from a restricted backup subnet. Finding Charlie is an internet-facing denial-of-service flaw on a product catalog protected by a content-delivery network with tested rate limiting. Finding Delta is a local privilege-escalation flaw on administrator workstations protected by application allowlisting.

Which finding should be remediated first based on exploitability, exposure, and impact?

  1. Finding Alpha, because observed exploitation and direct internet exposure threaten high-impact authentication assets (correct answer)
  2. Finding Bravo, because its higher base score outweighs the restricted network path to the controller
  3. Finding Charlie, because any internet-facing vulnerability should precede vulnerabilities on internal systems
  4. Finding Delta, because administrator workstations always take priority over customer-facing application servers
Explanation: When prioritizing vulnerabilities for remediation, you should weigh three dimensions together: exploitability (how easily and actively is it being exploited?), exposure (how reachable is it by attackers?), and impact (what damage results from compromise?). A high CVSS score alone is insufficient — context transforms raw scores into real-world risk. Finding Alpha checks every critical box simultaneously. It is unauthenticated and remotely executable, meaning no credentials or insider access are required. It faces the public internet directly. Active exploitation attempts are already appearing in logs — this isn't theoretical risk, it's an ongoing attack. And compromise exposes authentication tokens, which could cascade into account takeovers across your entire customer base. That combination of active exploitation, direct exposure, and high-value targets makes A the clear priority. B is tempting because higher CVSS scores feel authoritative, but CVSS base scores deliberately ignore network topology and compensating controls. Finding Bravo sits behind a restricted backup subnet, meaning an attacker must first breach that perimeter — a meaningful barrier that reduces real-world exploitability significantly. C applies a flawed heuristic: "internet-facing always wins." Finding Charlie is internet-facing, but a CDN with tested rate limiting substantially mitigates a denial-of-service flaw. Exposure matters, but so do compensating controls already in place. D contains a similarly flawed absolute rule. Administrator workstations are high-value, but local privilege escalation requires an attacker to already have local access — and application allowlisting further raises that bar. Study tip: On risk-prioritization questions, watch for answers that rely on a single factor (score, location, or asset type alone). Real prioritization multiplies exploitability × exposure × impact — and active exploitation evidence is the strongest multiplier of all.

Question 5

A scanner reports a critical unauthenticated flaw in a web component and a high-severity authenticated flaw in a partner API. For the web component, the vulnerable route is disabled at the reverse proxy, direct reachability testing confirms that requests cannot reach it, and configuration monitoring alerts on route changes. The partner API is exposed to the internet, credentials are issued to many external organizations, and the security team has observed requests matching a working exploit. Both flaws could provide equivalent control of the underlying application host.

Which prioritization decision best accounts for the compensating controls and current threat evidence?

  1. Prioritize the web component because an unauthenticated critical flaw remains inherently riskier than an authenticated flaw
  2. Prioritize the partner API because its reachable attack path and observed exploitation outweigh the web flaw's base rating (correct answer)
  3. Assign equal priority because both flaws ultimately provide equivalent control of their respective application hosts
  4. Defer the partner API because requiring credentials is sufficient to prevent exploitation by an external threat actor
Explanation: When prioritizing vulnerabilities, you must go beyond the base CVSS score and evaluate residual risk — what remains after compensating controls are applied — alongside threat intelligence signals like observed exploitation. A critical-rated flaw with zero reachability is far less urgent than a lower-rated flaw actively being exploited in the wild. The partner API (answer B) is the correct priority. Despite its "high" severity rating, every risk factor amplifies its danger: it's internet-exposed, credentials are distributed broadly across many external organizations (meaning the authentication barrier is weak), and — critically — the security team has already observed traffic matching a working exploit. That last point means the threat is no longer theoretical; exploitation is actively occurring. The web component flaw, while rated critical, has three layered controls reducing its residual risk: the vulnerable route is blocked at the proxy, reachability testing confirms inaccessibility, and monitoring would catch any configuration drift. Answer A falls into the classic trap of trusting base severity ratings without accounting for compensating controls. A disabled route changes the effective risk dramatically. Answer C ignores both the compensating controls protecting the web component and the active exploitation evidence against the API — equal priority is unjustified when the risk profiles are so different. Answer D is dangerously wrong: credentials distributed to many external organizations provide weak protection, especially when an observed working exploit already exists. "Requires credentials" does not mean "protected from external actors." Your study tip: on questions like this, always ask "what is the actual exploitability after controls?" and "has exploitation been observed?" — those two factors can override any base severity rating.

Question 6

A security team is reviewing four findings. Finding One has a CVSS score of 9.89.8 and low predicted exploitation probability; it is on a public server, but the vulnerable feature is disabled. Finding Two has a CVSS score of 8.08.0, appears in a catalog of vulnerabilities known to be exploited, and is reachable on a public appliance running an affected configuration. Finding Three has a CVSS score of 9.19.1 and high predicted exploitation probability, but it exists only in a sandbox with no route from production or untrusted networks. Finding Four has a CVSS score of 7.57.5 and affects a public service, but its denial-of-service effect has been reproduced only above a tested rate limit.

Which finding should receive the highest immediate remediation priority?

  1. Finding One, because its CVSS score is the highest among the externally located findings
  2. Finding Two, because known exploitation aligns with a reachable and affected public configuration (correct answer)
  3. Finding Three, because predicted exploitation probability should override network isolation and asset context
  4. Finding Four, because confirmed public exposure is more important than exploitation type or mitigating controls
Explanation: When prioritizing vulnerability remediation, CVSS scores alone are insufficient — you must weigh exploitability in context. Frameworks like SSVC (Stakeholder-Specific Vulnerability Categorization) and CISA's KEV catalog push practitioners to ask: is this vulnerability actually being exploited, and can an attacker realistically reach it? That combination — known exploitation plus a reachable, affected target — defines true immediate risk. Finding Two checks every critical box: a CVSS of 8.08.0, confirmed presence in a known-exploited-vulnerabilities catalog (meaning real threat actors are actively using it), and a public appliance running a vulnerable configuration with no compensating controls mentioned. This is the definition of an actionable, high-priority finding, making B the correct answer. A is tempting because Finding One carries the highest CVSS score (9.89.8), but CVSS measures theoretical severity, not real-world risk. The vulnerable feature is disabled, which is a concrete mitigating control. High score ≠ high priority when exploitability is neutralized. C fails because predicted exploitation probability is a forecast, not a confirmed event — and more importantly, network isolation is a decisive mitigating factor. No route from production or untrusted networks means an attacker cannot reach the vulnerability, rendering the high probability irrelevant in practice. D misreads the situation. Finding Four's denial-of-service impact is only reproducible above a rate limit that is already enforced, meaning the threat is effectively mitigated by an existing control, regardless of public exposure. Study tip: On security exams, always ask "reachable + exploited = priority." Known exploitation evidence (KEV catalogs, threat intel) paired with a reachable, unmitigated target should immediately jump to the top of your triage list over higher CVSS scores with compensating controls.

Question 7

Application-aware validation produces four results. A critical parsing flaw is present in a library packaged with an internet service, but the application never loads the affected module. A high-severity injection flaw is exercised by a public request handler, and testing confirms that untrusted input reaches the vulnerable function. A critical local flaw is installed on a powered-off disaster-recovery image that is not bootable without administrative action. A high-severity server flaw exists on an internal test host accessible only through a segmented laboratory network.

Which result should be ranked highest for near-term remediation?

  1. The packaged parsing flaw, because software presence is enough to establish internet-reachable exploitability
  2. The public injection flaw, because validated input reachability combines credible exploitation with external exposure (correct answer)
  3. The disaster-recovery image flaw, because its critical rating remains unchanged while the image is powered off
  4. The laboratory server flaw, because a running internal host is necessarily riskier than a public application
Explanation: When prioritizing vulnerabilities for remediation, raw severity scores alone are insufficient — you must assess exploitability in context. The critical factors are: (1) can the flaw actually be reached by an attacker, and (2) is that attacker likely external or internal? This combination of validated reachability plus exposure level drives real-world risk ranking. The public injection flaw described in answer B earns the top remediation priority because testing has confirmed that untrusted external input reaches the vulnerable function through a public request handler. This isn't theoretical — the attack path is validated end-to-end. High severity plus confirmed external reachability makes this the most immediately actionable and dangerous finding on the list. Answer A is a classic trap. Software being present in a package doesn't mean it's exploitable — if the application never loads the affected module, there is no execution path for an attacker to follow. Exploitability requires reachability, not just installation. Answer C misapplies severity ratings. A critical flaw on a powered-off image that requires administrative action to boot carries near-zero near-term exploitability. The rating reflects potential severity if exploited, not current risk. Prioritizing it over an actively reachable internet-facing flaw would misallocate resources. Answer D inverts the logic. A running internal host inside a segmented laboratory network is harder for an attacker to reach than a public-facing application. Network segmentation meaningfully reduces exposure even for running systems. Strategy tip: On vulnerability prioritization questions, train yourself to evaluate the full attack chain — severity × reachability × exposure. A critical flaw with no viable attack path ranks below a high-severity flaw with a confirmed, external-facing one.

Question 8

The same remotely exploitable vulnerability is present on four servers. Network exposure, exploit prerequisites, patch complexity, and likelihood of successful exploitation are equivalent for all four. The servers have different business functions.

Which server should receive the highest remediation priority based on potential impact?

  1. An update-signing server whose service account can distribute trusted packages to all managed endpoints (correct answer)
  2. A payroll reporting server containing encrypted salary exports and recoverable nightly backup copies
  3. A public status server containing cached availability information regenerated from monitored services
  4. An engineering wiki containing internal procedures but no production credentials or executable packages
Explanation: When assessing remediation priority, the key variable here isn't data sensitivity alone — it's blast radius: how far can an attacker pivot if they compromise this system? Think in terms of trust relationships and downstream impact, not just what data sits on the server. Answer A describes an update-signing server whose service account can push trusted packages to all managed endpoints. This is a supply-chain compromise scenario. An attacker who controls this server doesn't just steal data — they can deploy malicious software organization-wide, signed with a trusted certificate, bypassing endpoint defenses entirely. That cascading, organization-wide reach makes it uniquely dangerous and earns it the highest priority. Answer B is tempting because "payroll" and "salary data" sound critical. But notice the data is encrypted and backed up nightly — meaning confidentiality impact is reduced and availability impact is recoverable. The harm is bounded and reversible compared to A. Answer C is a public-facing status server with cached, regenerated data. Compromising it would have minimal confidentiality or integrity impact — the data is already public and automatically refreshed. This is the lowest-impact target of the four. Answer D, the engineering wiki, contains internal documentation but explicitly no credentials or executable packages. Without those elements, an attacker gains information but limited capability to escalate further. It's sensitive, not critical. Study tip: On impact-prioritization questions, always ask: "What can an attacker do next from here?" A server that grants trusted execution across the entire environment will almost always outrank servers that hold sensitive-but-static data, no matter how sensitive that data sounds.

Question 9

An internet-facing support portal has a moderate-severity flaw that discloses a temporary service token. Because of an unintended trust relationship, that token can call an internal management API. The management API contains a critical deserialization flaw that can compromise the production orchestration environment, but it is not reachable from any other untrusted source. The organization can deploy only one fix today: eliminate token disclosure in the portal or patch the internal deserialization flaw.

Assuming no other known path reaches the management API, which action provides the greatest immediate reduction in external attack risk?

  1. Fix the portal token disclosure because it removes the exposed entry point needed to reach the critical internal flaw (correct answer)
  2. Patch the deserialization flaw because the vulnerability with the greatest standalone technical severity must be fixed first
  3. Delay both fixes until they can be deployed together because neither vulnerability independently completes the entire attack chain
  4. Accept the portal flaw because a moderate-severity finding cannot materially affect prioritization of a critical internal flaw
Explanation: When evaluating multi-stage attack chains, your goal isn't to fix the most technically severe vulnerability in isolation — it's to identify which fix collapses the entire chain for an attacker. Think of it like a bridge: removing one critical span makes the whole crossing impossible, regardless of how dangerous the destination is. Here, the attack path has two required steps: steal the portal token, then exploit the deserialization flaw through the management API. Because no other path reaches the management API, these two vulnerabilities are chained dependencies, not independent risks. Fixing the portal token disclosure (A) severs the only known route into the management API entirely. An attacker can't exploit a flaw they can never reach. This makes A the correct choice — it neutralizes the critical internal vulnerability without even patching it, by eliminating access. B is tempting but reflects a common trap: prioritizing by standalone CVSS severity rather than exploitability in context. The deserialization flaw may be critical, but it's currently unreachable from untrusted sources. Patching it first leaves the exposed portal token in place — and if a second path to the API is ever discovered, you're still exposed. C is wrong because waiting introduces unnecessary window of exposure. The chain is already exploitable today, so deferring both fixes only benefits attackers. D is wrong because severity labels on individual findings don't account for chained impact. A "moderate" flaw that unlocks a "critical" flaw is effectively critical in combined risk. Study tip: On chain-exploitation questions, always ask "which fix makes the most downstream vulnerabilities unreachable?" — that fix almost always wins, regardless of individual severity scores.

Question 10

A vulnerability team must choose between several remediation campaigns. One campaign addresses a critical remote flaw on a disposable internet demonstration server that holds no credentials and is rebuilt daily. Another addresses a high-severity privilege-escalation flaw on hundreds of employee endpoints; threat actors are actively combining it with a common phishing foothold to disable security tools and deploy ransomware. A third addresses a critical flaw on an isolated training appliance used only during supervised exercises. A fourth addresses a high-severity information disclosure on a segmented development server containing synthetic data.

Which campaign should be prioritized to reduce the greatest overall organizational risk?

  1. The demonstration-server campaign because a critical internet-facing flaw always dominates aggregate endpoint risk
  2. The development-server campaign because information disclosure should precede vulnerabilities requiring an existing foothold
  3. The training-appliance campaign because critical severity should outweigh whether the appliance is routinely exposed
  4. The employee-endpoint campaign because active attack chaining, broad prevalence, and ransomware impact increase expected loss (correct answer)
Explanation: When prioritizing vulnerability remediation, resist the instinct to sort purely by CVSS severity score. The real goal is minimizing expected loss, which combines the probability of exploitation, the breadth of impact, and the potential business damage. A useful mental formula is: Risk = Likelihood × Impact × Exposure. The employee-endpoint campaign (D) wins on every dimension simultaneously. Threat actors are actively chaining the privilege-escalation flaw with a known phishing foothold — meaning exploitation probability is high and the attack path already exists in the wild. Hundreds of endpoints means the attack surface is enormous. And the end goal is ransomware deployment with security-tool disablement, which represents catastrophic business disruption. That combination of active exploitation, broad prevalence, and severe operational impact drives expected loss far above the other campaigns. Choice A is tempting because "critical + internet-facing" sounds alarming, but context dismantles it: the server holds no credentials, contains nothing sensitive, and is rebuilt daily. Compromise yields an attacker almost nothing. High severity plus negligible business value does not equal high risk. Choice C makes a similar mistake — treating critical severity as a trump card. The training appliance is isolated, supervised-use only, and presumably holds no production data. Network isolation and limited exposure dramatically reduce real-world impact regardless of the CVSSscore. Choice B misapplies a remediation-ordering heuristic. Information disclosure is serious, but the development server holds only synthetic data on a segmented network — its business impact ceiling is low, and prioritizing it over active ransomware campaigns would be a costly miscalculation. Study tip: On exam questions about prioritization, always ask three things: Is it being actively exploited? How many assets are exposed? What's the worst realistic outcome? Those three factors together — not severity alone — determine where to act first.