CompTIA CS0-003 Practice Test 33
Question 320
At Water utility, the security team assesses SCADA controller. The current issue is unpatched PLC service but active probes cause faults; assessment evidence states: passive inventory reports vulnerable model and old firmware. An analyst must separate confirmed impact from scanner assumptions. Which follow-up provides the strongest finding validation?
- Assume SCADA controller is safe because another platform with similar software recently passed its own assessment
- Force a destructive proof-of-concept against SCADA controller, ignoring that 24/7 treatment operation forbids intrusive scanning and a safer validation exist
- Mark passive inventory reports vulnerable model and old firmware resolved or confirmed solely from the scanner severity without verify with vendor advisory, passive version collection and maintenance engineers
- Confirm the reported condition in the relevant asset context: verify with vendor advisory, passive version collection and maintenance engineers
Explanation
Correct Answer
D:Verify with vendor advisory, passive version collection and maintenance engineers tests the reported condition passive inventory reports vulnerable model and old firmware against actual deployment context (isolated OT cell bridged through historian). That is stronger evidence than simply copying a scanner label.
Incorrect Answers
A:Security of an unrelated host cannot establish the state of SCADA controller, whose reported issue is unpatched PLC service but active probes cause faults.
B:A destructive proof is unnecessary when verify with vendor advisory, passive version collection and maintenance engineers can provide authorized evidence and 24/7 treatment operation forbids intrusive scanning constrains production testing.
C:passive inventory reports vulnerable model and old firmware may be accurate but its actual occurrence and configuration on SCADA controller must be established before calling it validated.
Question 321
At Water utility, the security team assesses SCADA controller. The current issue is unpatched PLC service but active probes cause faults; assessment evidence states: passive inventory reports vulnerable model and old firmware. Another internal test host has a higher numerical scanner severity but is segregated and has no customer-data access. Which finding should receive risk-based attention first?
- Choose whatever finding on SCADA controller was logged most recently, regardless of actual exploit path or priority
- Give every vulnerability the same deadline despite unpatched PLC service but active probes cause faults and business impact on drinking water availability
- Prioritize the confirmed exposure of SCADA controller, accounting for drinking water availability and the real access path: isolated OT cell bridged through historian
- Choose the highest nominal scanner severity first while ignoring isolated OT cell bridged through historian and the consequence to drinking water availability
Explanation
Correct Answer
C:Risk depends on practical reachability, threat activity and consequence. The issue unpatched PLC service but active probes cause faults can affect drinking water availability through isolated OT cell bridged through historian; a higher base score on an isolated host is not automatically a higher business priority.
Incorrect Answers
A:Discovery order is not evidence of urgency compared with the actual affected SCADA controller.
B:Uniform priority ignores isolated OT cell bridged through historian, operational harm and drinking water availability; documented context makes triage defensible.
D:CVSS describes technical characteristics, not the entirety of exposure and drinking water availability for this deployment.
Question 322
At Water utility, the security team assesses SCADA controller. The current issue is unpatched PLC service but active probes cause faults; assessment evidence states: passive inventory reports vulnerable model and old firmware. Testing confirms the reported vulnerability is exploitable in the described configuration. What lasting mitigation most directly addresses its underlying cause?
- Use firewall allowlist and jump-host segmentation until safe outage as permanent closure of the confirmed issue instead of deploying vendor-approved patch during safety-tested outage
- Sign an exception document but do not implement or test vendor-approved patch during safety-tested outage on SCADA controller
- Implement and verify the root-cause fix: vendor-approved patch during safety-tested outage
- Leave unpatched PLC service but active probes cause faults present indefinitely because no incident involving drinking water availability was recorded this week
Explanation
Correct Answer
C:Vendor-approved patch during safety-tested outage targets the mechanism unpatched PLC service but active probes cause faults rather than only filtering symptoms. Verification must account for passive inventory reports vulnerable model and old firmware and continued protection of drinking water availability.
Incorrect Answers
A:The interim control may reduce exposure, but it can leave the underlying unpatched PLC service but active probes cause faults and should be time-limited with verification and owner oversight.
B:Risk acceptance paperwork does not itself remediate unpatched PLC service but active probes cause faults on SCADA controller; authorized, tested implementation is still required when the risk exceeds tolerance.
D:No observed attack does not correct the verified condition passive inventory reports vulnerable model and old firmware or eliminate its potential impact on drinking water availability.
Question 323
At Water utility, the security team assesses SCADA controller. The current issue is unpatched PLC service but active probes cause faults; assessment evidence states: passive inventory reports vulnerable model and old firmware. A permanent correction cannot be deployed immediately because 24/7 treatment operation forbids intrusive scanning. Which interim treatment is the safest governed option?
- Claim unpatched PLC service but active probes cause faults is patched when the change ticket opens, without confirming firewall allowlist and jump-host segmentation until safe outage or a planned permanent change
- Accept continued exposure of drinking water availability without any owner, expiry or compensating verification because 24/7 treatment operation forbids intrusive scanning
- Apply a time-bound compensating measure, firewall allowlist and jump-host segmentation until safe outage, record the residual risk owner and schedule the tested permanent fix
- Push vendor-approved patch during safety-tested outage immediately to all production systems with no safe change window despite 24/7 treatment operation forbids intrusive scanning
Explanation
Correct Answer
C:Firewall allowlist and jump-host segmentation until safe outage can reduce short-term exposure while 24/7 treatment operation forbids intrusive scanning delays full remediation. The exception must have a defined owner, expiry, monitoring and tested repair plan because drinking water availability remains at stake.
Incorrect Answers
A:A work item is not proof that unpatched PLC service but active probes cause faults was corrected or even that firewall allowlist and jump-host segmentation until safe outage operates.
B:Business criticality increases the need for accountable decisions and review; it does not make drinking water availability irrelevant.
D:Ignoring 24/7 treatment operation forbids intrusive scanning could cause avoidable service failure and is not a risk-aware remediation process.
Question 324
At Water utility, the security team assesses SCADA controller. The current issue is unpatched PLC service but active probes cause faults; assessment evidence states: passive inventory reports vulnerable model and old firmware. The owner reports that vendor-approved patch during safety-tested outage has been deployed. What evidence should close the vulnerability item?
- Suppress future results for unpatched PLC service but active probes cause faults so that the vulnerability dashboard shows a completed remediation
- Retest the originally affected configuration using verify with vendor advisory, passive version collection and maintenance engineers, confirm the vulnerability is gone and record change evidence
- Use an unrelated server’s clean findings to claim SCADA controller is fixed without retesting the affected path
- Close passive inventory reports vulnerable model and old firmware after the deployment tool returns success, without verifying the current state of SCADA controller
Explanation
Correct Answer
B:Closure requires checking the same affected path identified by passive inventory reports vulnerable model and old firmware, plus regression impact on SCADA controller. A change ticket alone is not proof of removal of unpatched PLC service but active probes cause faults.
Incorrect Answers
A:Suppression may hide a failed or incomplete fix, leaving drinking water availability exposed despite the administrative record.
C:The result must be tied to SCADA controller and the actual exposure: isolated OT cell bridged through historian.
D:Process completion is not evidence that passive inventory reports vulnerable model and old firmware no longer applies to SCADA controller.
Question 325
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. How should an analyst apply an attack-method framework at this point without overclaiming who the attacker is?
- Map the observed behavior in package checksums differ from signed release manifest and build logs show unexplained mirror upload to a technique-level ATT&CK or kill-chain hypothesis and record confidence
- Treat an ATT&CK label for a vendor installer update is replaced with a malicious unsigned package on distribution mirror as a complete recovery instruction without checking evidence or impact
- Attribute a vendor installer update is replaced with a malicious unsigned package on distribution mirror to a named foreign intelligence service using only package checksums differ from signed release manifest and build logs show unexplained mirror upload
- Assign a final attack-chain stage to signed build pipeline without confirming what behavior actually occurred in package checksums differ from signed release manifest and build logs show unexplained mirror upload
Explanation
Correct Answer
A:A vendor installer update is replaced with a malicious unsigned package on distribution mirror and package checksums differ from signed release manifest and build logs show unexplained mirror upload support classification of observed attacker behavior, not confident attribution to a specific actor. Technique mapping helps correlate and anticipate later actions.
Incorrect Answers
B:A taxonomy is not an incident response plan for signed build pipeline; scope and safety constraints still matter.
C:Neither a vendor installer update is replaced with a malicious unsigned package on distribution mirror nor package checksums differ from signed release manifest and build logs show unexplained mirror upload establishes uniquely identifying actor evidence.
D:Attack frameworks describe observable stages and techniques; the package checksums differ from signed release manifest and build logs show unexplained mirror upload must substantiate whichever stage is assigned.
Question 326
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. The team expects later legal and technical review. Which acquisition step best preserves a defensible evidence trail?
- Keep only a screenshot of package checksums differ from signed release manifest and build logs show unexplained mirror upload, discarding original artifacts such as collect signed artifact manifest, repository audit and suspect package without executing it
- Rebuild signed build pipeline first and collect the volatile evidence for a vendor installer update is replaced with a malicious unsigned package on distribution mirror afterward
- Alter original package checksums differ from signed release manifest and build logs show unexplained mirror upload entries to remove irrelevant records before preserving the forensic timeline
- Preserve and hash incident artifacts: collect signed artifact manifest, repository audit and suspect package without executing it
Explanation
Correct Answer
D:Collect signed artifact manifest, repository audit and suspect package without executing it retains relevant source context and integrity checks so the team can reconstruct a vendor installer update is replaced with a malicious unsigned package on distribution mirror and support an auditable chain of custody.
Incorrect Answers
A:A screenshot cannot replace the underlying collect signed artifact manifest, repository audit and suspect package without executing it needed to establish sequence and integrity.
B:Volatile evidence relevant to a vendor installer update is replaced with a malicious unsigned package on distribution mirror may disappear during remediation or reboot.
C:Changing the original package checksums differ from signed release manifest and build logs show unexplained mirror upload compromises provenance and makes later findings harder to verify.
Question 327
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. The incident remains active, but signed build pipeline is operationally important. Which containment decision is most appropriate now?
- Execute scoped containment: halt affected distribution and isolate download mirror while notifying authorized clients privately
- Publish a speculative full-incident attribution notice before constraining the active behavior a vendor installer update is replaced with a malicious unsigned package on distribution mirror
- Erase package checksums differ from signed release manifest and build logs show unexplained mirror upload to reduce alert volume rather than isolating the observed attacker route
- Disconnect every service at Industrial firmware producer, regardless of whether it has a dependency on the affected signed build pipeline
Explanation
Correct Answer
A:Halt affected distribution and isolate download mirror while notifying authorized clients privately stops or limits the observed path while balancing continuity of signed build pipeline. It is a response to the current incident, not a replacement for evidence handling.
Incorrect Answers
B:Communication matters, but active a vendor installer update is replaced with a malicious unsigned package on distribution mirror requires proportionate containment and evidence preservation first.
C:Erasing package checksums differ from signed release manifest and build logs show unexplained mirror upload neither blocks attacker access nor supports a reliable subsequent recovery decision.
D:Broad interruption may unnecessarily affect signed build pipeline; containment should be scoped to evidenced systems and approved critical-service requirements.
Question 328
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. The active incident path is now isolated and evidence is retained. What should eradication focus on before service is restored?
- Use only the original firewall block and assume it has also removed all persistence behind a vendor installer update is replaced with a malicious unsigned package on distribution mirror
- Rewrite the playbook for signed build pipeline but leave the confirmed malicious access mechanism active
- Remove the attack’s established access and persistence: replace tampered package, rotate publishing credentials and restore signed provenance
- Restore signed build pipeline without first correcting the access and persistence cause addressed by replace tampered package, rotate publishing credentials and restore signed provenance
Explanation
Correct Answer
C:Replace tampered package, rotate publishing credentials and restore signed provenance targets the mechanism behind a vendor installer update is replaced with a malicious unsigned package on distribution mirror, reducing recurrence when signed build pipeline returns to normal operations.
Incorrect Answers
A:Containment can stop communication without eliminating the root access that produced package checksums differ from signed release manifest and build logs show unexplained mirror upload.
B:Updated paperwork does not eradicate the mechanism behind a vendor installer update is replaced with a malicious unsigned package on distribution mirror.
D:Recovery before replace tampered package, rotate publishing credentials and restore signed provenance could reintroduce the same compromise path.
Question 329
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. Containment and eradication are complete. Which recovery acceptance test should precede release of signed build pipeline to normal users?
- Delete preserved evidence including collect signed artifact manifest, repository audit and suspect package without executing it as soon as the service restarts
- Expose signed build pipeline to users before confirming that the conditions behind a vendor installer update is replaced with a malicious unsigned package on distribution mirror are absent
- Perform controlled return-to-service validation: independently verify downloaded digest and signature from clean distribution points
- Approve recovery of signed build pipeline when it boots, without executing the test independently verify downloaded digest and signature from clean distribution points
Explanation
Correct Answer
C:Independently verify downloaded digest and signature from clean distribution points demonstrates that the compromised pathway is absent while signed build pipeline again supports legitimate business processes. Verified recovery differs from mere uptime.
Incorrect Answers
A:Evidence retention obligations continue beyond restart; collect signed artifact manifest, repository audit and suspect package without executing it may be required for subsequent review.
B:Without a clean functional/security validation, signed build pipeline could immediately face the same exploit condition.
D:A boot event cannot prove independently verify downloaded digest and signature from clean distribution points or protect the service from recurrence of a vendor installer update is replaced with a malicious unsigned package on distribution mirror.
Question 330
At Industrial firmware producer, the incident team supports signed build pipeline. A new security event is reported: a vendor installer update is replaced with a malicious unsigned package on distribution mirror. The log clue is: package checksums differ from signed release manifest and build logs show unexplained mirror upload. The incident has been contained and normal service has resumed. A post-incident review identifies that unmonitored mirror upload permission lacked release signature enforcement. Which improvement should be prioritized?
- Discipline the whole on-duty response shift rather than examining the documented weakness unmonitored mirror upload permission lacked release signature enforcement
- Assign an owner and measurable corrective action addressing the root cause: unmonitored mirror upload permission lacked release signature enforcement, with a future effectiveness test
- Close the follow-up for signed build pipeline merely because restoration completed, without addressing unmonitored mirror upload permission lacked release signature enforcement
- Write a lessons-learned memo about a vendor installer update is replaced with a malicious unsigned package on distribution mirror with no due date, control owner or validation activity
Explanation
Correct Answer
B:Unmonitored mirror upload permission lacked release signature enforcement was the systemic weakness that enabled or worsened a vendor installer update is replaced with a malicious unsigned package on distribution mirror. An assigned, testable correction and later validation strengthen preparation against recurrence.
Incorrect Answers
A:A personnel-only response lacks support from the documented root cause: unmonitored mirror upload permission lacked release signature enforcement.
C:Service restoration does not address unmonitored mirror upload permission lacked release signature enforcement; ignoring it leaves the next incident likely to follow the same route.
D:An unowned recommendation does not produce a verified control improvement for signed build pipeline.
