Vulnerability Management practice questions

In dynamic environments the asset inventory must identify assets by stable attributes, not by IP address.

The symptom is mis-attribution, not missed scanning. IP addresses in an autoscaling group are transient, so any record keyed by IP drifts. Using the cloud provider's instance or resource ID, enriched with owner and application tags from the inventory, keeps each finding tied to the right workload. Static IPs would work technically but violate the scaling constraint; hostnames in autoscaled fleets inherit the same reuse; daily scans do not change the key.

1. Identify the problem as findings attached to the wrong asset.
2. Recognize that IPs are reused in autoscaling fleets.
3. Discard the option that breaks the scaling constraint.
4. Choose a stable asset identifier from the inventory.

Exam tip: In the cloud, track assets by resource ID and tags, never by IP alone.

Scan scheduling balances coverage against business impact by using agreed maintenance windows.

Active scans add load to targets. Since the requirement is weekly coverage, the fix is to keep the frequency and move the run time to a window the business has agreed, typically off-peak. Removing the servers or reducing frequency breaks the requirement, and changing scanner location does not change when the load arrives.

1. Link the slowdown to the scan start time.
2. Keep the stated weekly requirement fixed.
3. Move the scan to a low-impact window.

Exam tip: Keep the cadence, move the clock: schedule scans in maintenance windows.

Scheduling must use each site's local maintenance window, and scanner placement affects network performance.

Two problems combine: 01:00 to 05:00 CET falls in APAC business hours, and remote scanning crosses constrained WAN links. Distributed scanner engines (managed centrally) solve both, because each scans locally and can be scheduled in local off-hours. Moving the central window only shifts which region suffers; trimming ports or frequency gives up coverage or breaks the weekly rule.

1. Convert the scan window to the remote sites' local time.
2. Note the separate WAN capacity problem.
3. Find the option that fixes timing and bandwidth while keeping weekly coverage.

Exam tip: Scan where the assets are, when they are quiet: local scanners, local windows.

Scan operations and performance: tune intrusiveness and concurrency for fragile systems instead of dropping them.

Scanners include checks that can disrupt services (denial-of-service style or exploit-based tests) and send many concurrent connections. For fragile legacy hosts, enabling safe checks avoids dangerous tests, and lowering concurrency limits the load. Removing credentials actually makes the scan rely more on network probing, a full port sweep adds load, and an external vantage point changes coverage without reducing the probes.

1. Identify the cause as intrusive or heavy scanning.
2. Pick settings that reduce test intrusiveness.
3. Pick settings that reduce load.
4. Reject options that add probes or reduce coverage.

Exam tip: Fragile host? Safe checks plus throttling, not exclusion.

Scan sensitivity levels (templates and policies) control how intrusive a scan is and are matched to each asset group.

Scanners ship templates ranging from discovery-only to full checks that may include intrusive tests. Sensitivity is chosen per group: production systems that cannot tolerate disruption get safe, non-intrusive policies; test or lab systems can take the full set, which also shows what the aggressive checks find before builds reach production. Using one policy everywhere either risks production or under-tests the lab.

1. List each group's tolerance for disruption.
2. Match a scan template's intrusiveness to that tolerance.
3. Confirm both groups still get a weekly vulnerability scan.

Exam tip: Match scan sensitivity to what the target can tolerate.

Asset and data sensitivity level drives scan frequency and depth in the scanning plan.

With limited capacity, scanning effort should follow risk. Systems holding restricted data receive the most frequent and thorough (credentialed) scans; lower classifications are still scanned on a longer cycle. A flat schedule ignores sensitivity, inverting priorities under-protects the most valuable data, and exclusion leaves assets permanently unassessed.

1. Rank the classes by data sensitivity.
2. Assign frequency and depth by rank.
3. Use remaining capacity for lower classes rather than excluding them.

Exam tip: More sensitive data, more frequent and deeper scans.