Prioritizing and mitigating vulnerabilities

Key: C

1. AProd-App is internal, not KEV-listed, and has a patch, so it is not the most urgent, and isolating it until a maintenance window is not the answer.
2. BDev-Test is internet-facing but not KEV-listed and has a patch, so it can follow the normal cycle.
3. CCorrect: Prod-Web is internet-facing and listed in CISA's Known Exploited Vulnerabilities catalog, so it comes first; with no patch available, apply compensating controls (such as a WAF rule, access restriction or disabling the affected feature) now.
4. DDev-DB has the highest CVSS score (9.8) but is internal, not known to be exploited and patchable, so a high score alone doesn't make it most urgent.

Key: D

1. AThe medium flaw sits on the internet-facing workload while this answer targets the internal database, so it gets the target wrong.
2. BBeing outside the compliance scope wouldn't raise its priority, and the stem says nothing about compliance boundaries.
3. CNothing in the stem says the software can't be patched, and being unpatchable wouldn't explain why exposure drives priority.
4. DCorrect: Exposure to the internet and administrative privileges make a medium flaw easier to reach and more damaging than a high flaw on a tightly segmented internal service.

Key: A

1. ACorrect: If all three paths pass through one chokepoint, hardening that single point cuts the attacker off from the database with the least work.
2. BFixing the lowest-CVSS findings first leaves the actual path to the database open and does nothing to reduce reachability.
3. CPatching every web server vulnerability works, but it is the most fixes instead of the fewest.
4. DDisabling all external access removes reachability by breaking the business, which is not a remediation plan.

Key: C

1. ASignature updates affect what the scanner detects; they don't change the fact that a static scan is not the same as what is actually exposed at runtime.
2. BRegistries don't patch images automatically, but this belief isn't the error in recommending a shutdown based on scan counts.
3. CCorrect: An image scan lists vulnerable packages without measuring exposure; whether those packages are loaded, reachable or covered by runtime controls decides the real risk.
4. DScanning overhead is a performance concern and not the flaw in a decision to shut down production.

Key: A

1. ACorrect: A known exploited RCE on a system that falls under the 14-day regulatory rule goes first, both because of active exploitation and the compliance deadline.
2. BStarting with the lowest-CVSS items leaves the most dangerous, exploited flaw open longest.
3. CPatching non-regulated systems first delays the asset that has both active exploitation and a regulatory deadline.
4. DGiving every asset the same priority ignores exploitation, data classification and the regulatory deadline.

Key: B

1. AA compensating control lowers risk but does not remove it, and deferring every item that has one can leave exploited flaws open indefinitely.
2. BCorrect: Combine CVSS with exploit evidence, asset value, exposure and compensating controls, then put findings into SLA buckets so that each one has a deadline.
3. CPutting isolated assets first regardless of exploitation flips the logic, because exposure and active exploitation should raise priority.
4. DA uniform 30-day deadline ignores the context the scanner data gives you, so critical exploited items wait as long as trivial ones.

Key: D

1. ARegulated data raises the impact of a compromise, so lowering priority goes the wrong way.
2. BKeeping the old schedule ignores that the asset's value and regulatory impact have changed.
3. CRemoving a regulated-data asset from scans creates a blind spot and would likely breach compliance requirements.
4. DCorrect: Holding regulated data raises the asset's criticality, so its vulnerabilities should get higher priority and shorter remediation deadlines.

Key: C

1. ACompliance documentation may use validated results, but it is not why you validate findings.
2. BAn overall security score is a reporting metric and is separate from checking whether individual findings are real.
3. CCorrect: Validation checks whether a finding is real and exploitable in your environment, which removes false positives and focuses effort on actual risk.
4. DAssigning work to system owners is remediation workflow that comes after validation and prioritization.

Key: A

1. ACorrect: Close only after the rescan confirms the fix and a defined monitoring period shows latency and error rates back within agreed thresholds.
2. BChecking that transactions succeed without latency thresholds ignores the performance degradation the patch has already caused.
3. CAutomated configuration checks confirm settings but cannot show that the service is performing normally after the patch.
4. DClosing on a clean rescan alone ignores the new latency and errors, so a security fix that broke service would go unnoticed.

Key: C

1. ARolling straight into production with no lab or pilot testing risks outages across mixed hardware, and snapshots don't replace testing.
2. BA pilot on identical hardware misses problems on the other models in a mixed fleet, and jumping straight to a full rollout gives no staged checkpoints.
3. CCorrect: Test in a lab, pilot on a representative mix of hardware, widen in growing cohorts and then roll out fully, with rollback checkpoints at each stage.
4. DValidating in the lab after a full production deployment gets the order backwards, because issues are found only after they hit every system.

Key: D

1. AA business impact statement explains why the fix matters, but on its own it gives the implementer nothing to act on.
2. BA CVE ID and CVSS score identify the flaw but don't say how to fix it safely or when.
3. CA patch link without version data doesn't tell the implementer which versions are affected or what to install.
4. DCorrect: A change on a critical production server needs a rollback plan and a maintenance (or emergency change) window so the fix can be applied safely and undone if it breaks something.

Key: B

1. AChanges inside a container don't corrupt the host OS; the problem is that the fix doesn't last.
2. BCorrect: Containers are meant to be immutable, so a package installed in a running container disappears when it is replaced; fix the image, rebuild and redeploy it.
3. COrchestrators don't roll back manual changes; they replace containers from the original image on restart, which quietly undoes the fix.
4. DThe fix belongs in the image build, but the shell approach is wrong because of the immutability principle, and no rule requires updating CI at the same time.

Key: D

1. AOne regex applied before storage can't cover every output context, and regex-based XSS filters are easy to bypass.
2. BRejecting special characters everywhere breaks legitimate input and still misses context-specific payloads, because XSS is fixed by encoding at output.
3. CEncoding only for HTML leaves attribute and JavaScript contexts open, and browsers don't encode output for you.
4. DCorrect: Encode output for each context it goes into (HTML body, attribute, JavaScript), and add a Content Security Policy as a second layer.

Key: D

1. AA buffer overflow writes past the end of a memory buffer, a memory-safety flaw that has nothing to do with using input to run server commands.
2. BAn on-path (man-in-the-middle) attack intercepts traffic between two parties and does not rely on unvalidated input to the application.
3. CCross-site scripting injects script that runs in the victim's browser instead of commands on the server.
4. DCorrect: command injection passes unvalidated input to a system shell or command, so the server runs commands the attacker chose.

Key: B

1. ADisciplinary reports don't reduce the vulnerability risk and push shadow IT further out of sight.
2. BCorrect: Bring the assets into the inventory, assess their risk, then decide whether to integrate them into normal management or decommission them.
3. CShutting everything down at once can break business processes that depend on these resources, without any risk assessment.
4. DIgnoring them leaves unmanaged, unpatched systems on the network, which is exactly why shadow IT is a risk.