Cyber Security Quiz: Vuln Scanning Vs Pen Testing
10 questions · exam conditions
0:00
Vuln Scanning Vs Pen TestingQuestion 1 of 10

An administrator supplies a security tool with domain credentials. The tool logs in to each server, enumerates installed packages, compares configuration settings with known checks, and reports missing patches. It does not attempt privilege escalation, evade controls, or use identified weaknesses to pursue an objective.

How should this activity be classified?

It is a penetration test because using valid credentials simulates an attacker who has compromised an account.
It is an authenticated vulnerability scan because credentials improve inspection depth without changing the assessment objective.
It is an unauthenticated vulnerability scan because the tool does not attempt to exploit any reported weakness.
It is a penetration test because local package enumeration provides proof that the discovered issues are exploitable.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Vuln Scanning Vs Pen Testing

Practice Vuln Scanning Vs Pen Testing 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 Vuln Scanning Vs Pen Testing, 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

An administrator supplies a security tool with domain credentials. The tool logs in to each server, enumerates installed packages, compares configuration settings with known checks, and reports missing patches. It does not attempt privilege escalation, evade controls, or use identified weaknesses to pursue an objective.

How should this activity be classified?

  1. It is a penetration test because using valid credentials simulates an attacker who has compromised an account.
  2. It is an authenticated vulnerability scan because credentials improve inspection depth without changing the assessment objective. (correct answer)
  3. It is an unauthenticated vulnerability scan because the tool does not attempt to exploit any reported weakness.
  4. It is a penetration test because local package enumeration provides proof that the discovered issues are exploitable.
Explanation: When classifying a security assessment activity, focus on two independent dimensions: whether credentials are used and what the tool actually does with what it finds. These two dimensions are often conflated, which is exactly what this question tests. The scenario describes a tool that logs in with supplied credentials, enumerates packages, compares configurations against known benchmarks, and reports gaps — nothing more. That combination defines an authenticated vulnerability scan. The credentials allow the tool to see deeper into each system (installed packages, local settings) than an unauthenticated probe could, but the objective remains purely identification and reporting. B is correct because it accurately captures both elements: credentials improve inspection depth, and the scope never expands beyond assessment. A is wrong because using valid credentials does not, by itself, make something a penetration test. A penetration test requires attempting to exploit weaknesses and pursue an objective (e.g., lateral movement, data exfiltration, privilege escalation). Simulating a compromised account is a methodology choice, not a classification criterion. C is wrong because it misreads what "unauthenticated" means. Unauthenticated scans run without supplying login credentials, relying on external-facing probes only. The absence of exploitation does not make a scan unauthenticated — those are separate attributes entirely. D is wrong because local enumeration does not constitute proof of exploitability. Proof-of-concept exploitation — actually demonstrating that a weakness can be leveraged — is what a penetration test provides. Listing installed packages is inventory work, not exploitation. Study tip: On exam questions like this, always ask two questions separately: Were credentials used? and Was exploitation attempted? Conflating those two axes is the most common trap in assessment-classification questions.

Question 2

A business owner asks a security team to assess a production payment platform. The request says, "Prove whether an attacker can alter transactions, but do not exploit vulnerabilities, modify data, or perform any action that could affect a transaction."

What should the security team do FIRST?

  1. Run a vulnerability scan and state that any critical finding conclusively proves transactions can be altered.
  2. Begin penetration testing because proof of impact automatically overrides restrictions in the assessment request.
  3. Clarify the rules of engagement and agree on safe validation methods or a representative test environment. (correct answer)
  4. Perform only passive discovery because vulnerability scanning and penetration testing both require modifying production data.
Explanation: When a security assessment involves a production environment — especially one handling financial transactions — you're immediately in the territory of rules of engagement (ROE) and professional ethics. The core tension here is that the client wants proof of a vulnerability's real-world impact, but has simultaneously prohibited any action that could actually demonstrate that impact. That contradiction must be resolved before any testing begins. This is why C is correct. Clarifying the rules of engagement and agreeing on safe validation methods — such as testing in a staging environment that mirrors production — is the only responsible first step. It protects the client's live data, keeps the team legally covered, and ensures the assessment can actually answer the client's question without violating their own constraints. A is wrong because a vulnerability scan alone never proves exploitation is possible — it identifies potential weaknesses. Telling a client that a critical finding "conclusively proves" impact is technically dishonest and oversteps what scanning can establish. B contains a dangerous misconception: no security team has unilateral authority to override a client's stated restrictions, regardless of their justification. Proof of impact does not automatically grant permission. Proceeding without client agreement exposes the team to serious legal liability. D oversimplifies the situation. Not all scanning modifies data, and some forms of active testing can be performed safely in isolated environments. Defaulting to passive-only without discussion unnecessarily limits the assessment. A good study tip: whenever an exam question involves a production system with restrictions, your default first action should always be communication and scoping — never unilateral technical action.

Question 3

A vulnerability scanner identifies a critical remote-code-execution issue by detecting an affected software version. During a later penetration test, the tester cannot obtain code execution because a runtime mitigation blocks the available payload and network controls prevent the required outbound connection.

Which conclusion is MOST appropriate?

  1. The scanner finding is necessarily a false positive because exploitation did not succeed during the penetration test.
  2. The penetration test proves the vulnerability cannot be exploited by any attacker under future conditions.
  3. The scanner identified potential exposure, while the penetration test evaluated exploitability under the tested conditions. (correct answer)
  4. The penetration test result should replace the scanner result because manual testing always has greater coverage.
Explanation: When you see a question comparing scanner results to penetration test results, the core concept being tested is the difference between vulnerability existence and exploitability under specific conditions. These two assessments answer fundamentally different questions, and conflating them is a dangerous mistake in real-world security. A vulnerability scanner detects indicators of a problem — typically a software version, a configuration signature, or a known fingerprint — and flags potential exposure. It doesn't attempt live exploitation. A penetration test actively tries to exploit that finding, but always within a constrained environment: specific tools, specific payloads, specific network paths, and a specific point in time. That distinction is exactly what C captures. The scanner correctly identified that a vulnerable version exists (potential exposure), while the penetration test revealed that, under the conditions tested, exploitation was blocked by a runtime mitigation and network controls. Both results are valid and complementary. A is wrong because a failed exploit during a pen test doesn't invalidate the scanner finding. The vulnerability still exists in the software; the environment simply prevented this particular exploitation path. Calling it a false positive would be technically inaccurate and could lead to unpatching a real issue. B is wrong because penetration tests are inherently scoped and time-bound. A motivated attacker with different tools, a zero-day bypass for the mitigation, or changed network rules could succeed where the tester failed. A single test never proves universal unexploitability. D is wrong because manual pen testing doesn't automatically have greater coverage — it's often narrower in scope than automated scanning, which checks far more hosts and configurations systematically. Your takeaway: on security exams, never treat a pen test failure as proof a vulnerability is harmless. Think about conditions tested, not universal truth.

Question 4

A scanner reports three medium-severity issues on an internet-facing application: user identifiers are predictable, password-reset responses disclose whether an account exists, and an internal service accepts requests from the application without reauthentication. A tester combines these conditions to reset a privileged account and access internal records.

What does this scenario BEST demonstrate about penetration testing compared with vulnerability scanning?

  1. Penetration testing can evaluate chained weaknesses whose combined impact exceeds their individual scanner ratings. (correct answer)
  2. Vulnerability scanning cannot identify configuration weaknesses unless the scanner is given administrative credentials.
  3. Penetration testing converts all successfully exploited medium findings into critical software vulnerabilities.
  4. Vulnerability scanning is unnecessary when a tester can manually identify one path to sensitive information.
Explanation: When you see a question comparing penetration testing to vulnerability scanning, focus on what each method can and cannot reveal on its own. Scanners identify and rate individual weaknesses in isolation — they cannot simulate how an attacker would chain multiple flaws together into a single, escalating attack path. That's exactly what this scenario illustrates. Each issue alone was rated medium-severity: predictable user IDs, account enumeration via password-reset responses, and an unauthenticated internal service. None individually screamed "critical." But the tester combined all three — enumerate a valid privileged account, trigger a reset, then pivot to the internal service without reauthentication — achieving an outcome far more damaging than any single finding suggested. This is the defining strength of penetration testing: demonstrating chained exploitation, which makes A the correct answer. B is a distractor that confuses scanner capabilities with scanner design purpose. Scanners can detect many configuration issues without admin credentials; the real limitation isn't credential-gating, it's that scanners don't simulate multi-step attack logic. C misrepresents what penetration testing does. It doesn't reclassify vulnerabilities as critical software flaws — it demonstrates real-world impact. A medium finding doesn't change its CVSS score just because it was exploited; the combined business risk increases, not the individual label. D flips the relationship between the two techniques. Penetration testing and vulnerability scanning are complementary, not substitutes. Eliminating scanning because a tester found one path would leave countless other weaknesses undiscovered. For the exam, remember: pentest = chain + context; scanner = individual + rating. When a question describes multiple medium findings leading to a major breach, it's almost always testing your understanding of attack chaining.

Question 5

A vulnerability-scanning report lists 1,200 findings across 300 hosts. A penetration-testing report from the same environment documents three successful attack paths and 14 supporting weaknesses. An executive concludes that the scanner was more effective because it found far more issues.

Which explanation BEST corrects the executive's conclusion?

  1. The reports are comparable only after every scanner finding is assigned the same severity as the nearest penetration-test weakness.
  2. The penetration test was less effective because any valid manual assessment should reproduce every finding generated by the scanner.
  3. The scanner was more effective because automated findings always represent independent exploitable paths rather than duplicated evidence.
  4. Finding counts are not directly comparable because scanning emphasizes broad detection while penetration testing emphasizes validated attack paths. (correct answer)
Explanation: When you see a question comparing different security assessment methodologies, your first instinct should be to ask: what is each tool actually designed to do? Vulnerability scanners and penetration tests serve fundamentally different purposes, so measuring them against the same metric — raw finding counts — is like comparing a fishing net to a spear based on how many fish each one touched. Vulnerability scanners are built for breadth: they automatically probe hundreds of hosts looking for known misconfigurations, missing patches, and exposed services. A scanner's strength is coverage. Penetration testing, by contrast, is built for depth: a skilled tester chains weaknesses together to demonstrate real-world attack paths, confirming which vulnerabilities are actually exploitable in context. Three attack paths and 14 supporting weaknesses could represent a catastrophic risk — far more dangerous than 1,200 unvalidated scanner alerts. D correctly captures this distinction: the finding counts reflect different methodologies, not different levels of effectiveness. A is wrong because assigning matching severity scores to scanner and penetration-test findings doesn't make them comparable — they're measuring different things entirely, not just rated differently. B is wrong and reverses what a penetration test is supposed to do; manual testers aren't expected to reproduce automated scanner output — they're expected to validate exploitability, which is a narrower and harder task. C is wrong because scanner findings are frequently duplicated, theoretical, or false positives — they do not automatically represent independent exploitable paths. Remember this pattern: on security exams, questions about assessment tools almost always test whether you understand purpose over quantity. More findings ≠ more effective.

Question 6

An organization performs monthly vulnerability scans and an annual penetration test. The latest penetration test found no viable path from the internet to the customer database. A manager proposes suspending scans until the next annual test because the penetration test used more realistic attack techniques.

Which response BEST addresses the manager's proposal?

  1. Suspend the scans because a penetration test provides complete assurance until the assessed architecture changes.
  2. Replace monthly scans with monthly penetration tests because both activities provide equivalent coverage at different depths.
  3. Continue scanning because new vulnerabilities and configuration drift can arise after the point-in-time penetration test. (correct answer)
  4. Continue scanning only the database because the penetration test cleared every system on the external attack path.
Explanation: When you see a question comparing one-time assessments to continuous monitoring, the core concept being tested is the difference between point-in-time and ongoing security assurance. A penetration test is a snapshot — it tells you what was exploitable on the day it was performed. The moment it concludes, the environment begins to change: vendors release new CVEs, administrators push misconfigured updates, and developers deploy new code. Monthly vulnerability scans exist precisely to catch this configuration drift and newly disclosed vulnerabilities between those annual snapshots. That's why C is correct — suspending scans creates a blind spot lasting up to twelve months, during which real attackers aren't pausing. A is wrong because it treats the penetration test as a guarantee of ongoing security. No single assessment provides "complete assurance" into the future — this is a dangerous misconception the exam frequently tests against. B is wrong because penetration tests and vulnerability scans are not interchangeable. Scans are automated and frequent; penetration tests are manual, expensive, and time-intensive. Running a full penetration test monthly isn't operationally realistic, and the two activities serve complementary rather than equivalent roles. D is wrong because it misreads what the penetration test actually confirmed. Clearing a path to the database doesn't mean every system along that path is vulnerability-free — other systems could be exploited for lateral movement, pivoting, or entirely different attack chains. Study tip: On security exams, anytime a question asks whether a periodic manual test can replace continuous monitoring, the answer is almost always no — they're complementary layers of defense-in-depth.

Question 7

A weekly vulnerability scan reports no critical findings on an externally accessible appliance. During a penetration test, a tester logs in using vendor-default credentials, changes a nonpersistent setting, and reaches an internal management interface. The scanner had performed version checks but did not attempt authentication with default passwords.

Which interpretation BEST reconciles the two results?

  1. The penetration test result is invalid because a clean vulnerability scan establishes that no critical exposure exists.
  2. The scanner missed an attack path outside its enabled checks, while the penetration test demonstrated practical impact. (correct answer)
  3. The scanner produced a false positive by reporting no findings, while the penetration test corrected its severity score.
  4. The penetration test created the vulnerability because changing any setting makes earlier scan results unreliable.
Explanation: When a question compares scanner results to penetration test results, you should immediately think about scope of checks — scanners only find what they're configured to look for, while skilled testers explore the full attack surface creatively. In this scenario, the scanner performed version checks but never attempted authentication with default credentials. That means the attack path — login with vendor defaults → reach internal management interface — was simply outside the scanner's enabled checks. The scanner wasn't wrong about what it tested; it just didn't test for credential hygiene. The penetration tester then demonstrated that this gap had real, practical impact by actually reaching an internal system. That's exactly what B describes: a missed attack path due to limited scanner configuration, confirmed as exploitable by the pen test. A is wrong because a clean scan does not establish that no critical exposure exists — it only establishes that no critical exposure was found within the scanner's configured checks. Confusing "not found" with "doesn't exist" is a classic and dangerous mistake. C contains a fundamental terminology error: a false positive means the scanner incorrectly reported a finding that doesn't exist. Here the scanner reported nothing, so there's no false positive involved. D is backwards — changing a nonpersistent setting doesn't create a vulnerability retroactively. The default credentials existed before the pen test; the tester discovered the weakness, not caused it. Study tip: On security exams, always distinguish between a tool's capabilities and its configuration. A scanner with limited checks enabled is not the same as a scanner with no findings — this distinction appears frequently in questions comparing automated scanning to manual testing.

Question 8

A penetration test showed that an attacker could combine server-side request forgery with an overly permissive cloud identity role to retrieve stored documents. After remediation, a scanner confirms that the vulnerable application component was upgraded and reports no known software vulnerabilities.

What is the MOST appropriate way to verify remediation?

  1. Close the issue because a clean scan confirms that the upgraded component eliminates the complete penetration-test attack path, including the cloud permissions.
  2. Repeat the full enterprise penetration test because scanner results, even for upgraded components, cannot contribute meaningful evidence to remediation verification.
  3. Review the change-management upgrade record because administrative evidence of the patch action is stronger than either automated scanning or targeted exploitation testing.
  4. Use the scan as patch evidence for the upgraded component and perform a targeted retest of the original attack path and the cloud identity permissions. (correct answer)
Explanation: When verifying remediation after a penetration test, you need to think carefully about scope. A scanner and a penetration test measure different things — scanners detect known vulnerabilities in software components, while penetration tests validate entire attack chains. The original finding here involved two weaknesses working together: an SSRF vulnerability in the application and an overly permissive cloud IAM role. Remediating one leg of a multi-step attack path doesn't automatically close the other. Answer D is correct because it uses each tool for what it does best. The vulnerability scanner provides solid evidence that the software component was patched — that's a legitimate and efficient use of scan data. But because the original attack path also depended on excessive cloud permissions, a targeted retest is needed to confirm those permissions were also corrected. Together, scan results plus targeted exploitation testing give you full confidence that the complete attack chain is broken. Answer A is the classic trap here — it assumes that fixing the application component automatically addressed the cloud identity misconfiguration. It didn't. A clean scan only speaks to known CVEs in software; it says nothing about IAM policy configuration. Answer B overcorrects in the opposite direction, dismissing scanner results entirely. Scanners are imperfect but genuinely useful for confirming patch application — throwing away valid evidence is wasteful and inefficient. Answer C mistakes administrative proof for technical proof. A change-management record tells you a patch was applied, not that the vulnerability was eliminated or that the broader attack path no longer works. Your study takeaway: whenever a finding involves chained vulnerabilities, verify each link in the chain independently — don't let evidence about one component stand in for the whole.

Question 9

A company wants to assess a customer portal hosted by a software-as-a-service provider. The contract permits ordinary use of the portal but says nothing about security testing. An engineer argues that an automated vulnerability scan may be launched without approval because only penetration testing counts as an attack.

Which action is MOST appropriate?

  1. Obtain explicit authorization and define permitted scanning and penetration-testing methods before assessing the hosted portal. (correct answer)
  2. Run the vulnerability scan without approval, but request authorization before manually exploiting any reported finding.
  3. Perform only an unauthenticated scan because authorization is required solely when valid customer credentials are used.
  4. Begin penetration testing without approval because the existing service contract authorizes all normal network connections.
Explanation: When you see a question about security assessments on third-party or cloud-hosted systems, your first instinct should be: who owns the infrastructure, and what has been explicitly authorized? This is the foundation of ethical hacking and professional penetration testing — authorization must come before any assessment activity, not just exploitation. The key principle here is that all security testing — including automated vulnerability scanning — requires explicit written authorization from the asset owner. A SaaS provider owns the infrastructure hosting the portal, meaning the customer company does not have unilateral rights to scan it, regardless of their service contract. Scanning without permission can violate computer fraud laws, disrupt services, and breach the SaaS agreement. Option A is correct because it requires obtaining explicit authorization and defining the full scope — both scanning and penetration testing — before anything begins. This is the only approach that protects the engineer, the company, and the relationship with the provider. Option B is dangerously wrong because it treats scanning as a harmless first step that needs no approval — but unauthorized scanning is itself a violation. Waiting until exploitation to seek permission is far too late. Option C introduces a false rule: authentication status has nothing to do with whether authorization is required. Both authenticated and unauthenticated scans require permission. Option D misreads the service contract entirely — permission to use a portal as a customer is categorically different from permission to test its security. No reasonable interpretation of a service contract implies attack authorization. Remember this rule for the exam: any active probing of a system — scan or exploit — requires explicit, written, scoped authorization from the system owner. When in doubt, get it in writing first.

Question 10

An organization has five days to assess 800 servers before a data-center migration. Security leadership wants a repeatable inventory of missing patches and insecure configurations, minimal operational disruption, and evidence about whether the most serious exposures can actually be used to reach regulated data.

Which assessment approach BEST satisfies these objectives?

  1. Perform a credentialed vulnerability scan, then conduct a scoped penetration test against selected high-risk findings. (correct answer)
  2. Conduct a broad penetration test first, then scan only the hosts that the testers successfully compromise.
  3. Perform a credentialed vulnerability scan and treat every critical scanner finding as proof of exploitable impact.
  4. Conduct a penetration test of every server and omit automated scanning because exploitation produces stronger evidence.
Explanation: When you see a scenario combining scale, time pressure, operational constraints, and a need to prove real-world impact, you're being asked to distinguish between vulnerability scanning and penetration testing — and understand when to combine them intelligently. Credentialed vulnerability scanning uses valid system credentials to enumerate missing patches and misconfigurations across hundreds of hosts quickly, with minimal disruption. It produces the repeatable, comprehensive inventory the organization needs. A penetration test, by contrast, simulates an attacker — it's slower, more disruptive, and best applied narrowly where the evidence truly matters. The right approach is to run the scan first to identify the full landscape, then focus human-driven exploitation only on the highest-risk findings to confirm whether those exposures actually provide a path to regulated data. That's exactly what A describes, making it the best fit for all stated objectives simultaneously. B inverts the logical order — penetrating first and scanning only compromised hosts wastes time, misses hosts that aren't exploited, and produces an incomplete inventory. You'd likely fail to assess all 800 servers in five days. C makes a critical conceptual error: scanner findings represent potential vulnerabilities, not confirmed exploitability. Treating every critical finding as proven impact inflates risk and bypasses the need for validation through testing. D is operationally unrealistic — manually exploiting all 800 servers in five days is impossible, and abandoning automated scanning eliminates the systematic, repeatable inventory leadership explicitly requested. For the exam, remember this pattern: scan broadly to inventory, then test narrowly to validate. Any answer that skips the scan, reverses the order, or conflates detection with exploitation should raise a red flag.