CompTIA CS0-003 Practice Test 21
Question 200
At Rail operator, the security team assesses customer account endpoint. The current issue is weak TLS protocol/cipher accepted; assessment evidence states: scanner completes TLS 1.0 handshake from internet. An analyst must separate confirmed impact from scanner assumptions. Which follow-up provides the strongest finding validation?
- Confirm the reported condition in the relevant asset context: recheck negotiated protocol with independent client across frontends
- Mark scanner completes TLS 1.0 handshake from internet resolved or confirmed solely from the scanner severity without recheck negotiated protocol with independent client across frontends
- Assume customer account endpoint is safe because another platform with similar software recently passed its own assessment
- Force a destructive proof-of-concept against customer account endpoint, ignoring that legacy barcode readers have separate integration API and a safer validation exist
Explanation
Correct Answer
A:Recheck negotiated protocol with independent client across frontends tests the reported condition scanner completes TLS 1.0 handshake from internet against actual deployment context (public web service for tickets). That is stronger evidence than simply copying a scanner label.
Incorrect Answers
B:scanner completes TLS 1.0 handshake from internet may be accurate but its actual occurrence and configuration on customer account endpoint must be established before calling it validated.
C:Security of an unrelated host cannot establish the state of customer account endpoint, whose reported issue is weak TLS protocol/cipher accepted.
D:A destructive proof is unnecessary when recheck negotiated protocol with independent client across frontends can provide authorized evidence and legacy barcode readers have separate integration API constrains production testing.
Question 201
At Rail operator, the security team assesses customer account endpoint. The current issue is weak TLS protocol/cipher accepted; assessment evidence states: scanner completes TLS 1.0 handshake from internet. 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 the highest nominal scanner severity first while ignoring public web service for tickets and the consequence to session confidentiality
- Give every vulnerability the same deadline despite weak TLS protocol/cipher accepted and business impact on session confidentiality
- Choose whatever finding on customer account endpoint was logged most recently, regardless of actual exploit path or priority
- Prioritize the confirmed exposure of customer account endpoint, accounting for session confidentiality and the real access path: public web service for tickets
Explanation
Correct Answer
D:Risk depends on practical reachability, threat activity and consequence. The issue weak TLS protocol/cipher accepted can affect session confidentiality through public web service for tickets; a higher base score on an isolated host is not automatically a higher business priority.
Incorrect Answers
A:CVSS describes technical characteristics, not the entirety of exposure and session confidentiality for this deployment.
B:Uniform priority ignores public web service for tickets, operational harm and session confidentiality; documented context makes triage defensible.
C:Discovery order is not evidence of urgency compared with the actual affected customer account endpoint.
Question 202
At Rail operator, the security team assesses customer account endpoint. The current issue is weak TLS protocol/cipher accepted; assessment evidence states: scanner completes TLS 1.0 handshake from internet. Testing confirms the reported vulnerability is exploitable in the described configuration. What lasting mitigation most directly addresses its underlying cause?
- Use edge termination with secure profile until backend rebuilt as permanent closure of the confirmed issue instead of deploying disable obsolete protocols and select modern cipher policy
- Leave weak TLS protocol/cipher accepted present indefinitely because no incident involving session confidentiality was recorded this week
- Implement and verify the root-cause fix: disable obsolete protocols and select modern cipher policy
- Sign an exception document but do not implement or test disable obsolete protocols and select modern cipher policy on customer account endpoint
Explanation
Correct Answer
C:Disable obsolete protocols and select modern cipher policy targets the mechanism weak TLS protocol/cipher accepted rather than only filtering symptoms. Verification must account for scanner completes TLS 1.0 handshake from internet and continued protection of session confidentiality.
Incorrect Answers
A:The interim control may reduce exposure, but it can leave the underlying weak TLS protocol/cipher accepted and should be time-limited with verification and owner oversight.
B:No observed attack does not correct the verified condition scanner completes TLS 1.0 handshake from internet or eliminate its potential impact on session confidentiality.
D:Risk acceptance paperwork does not itself remediate weak TLS protocol/cipher accepted on customer account endpoint; authorized, tested implementation is still required when the risk exceeds tolerance.
Question 203
At Rail operator, the security team assesses customer account endpoint. The current issue is weak TLS protocol/cipher accepted; assessment evidence states: scanner completes TLS 1.0 handshake from internet. A permanent correction cannot be deployed immediately because legacy barcode readers have separate integration API. Which interim treatment is the safest governed option?
- Push disable obsolete protocols and select modern cipher policy immediately to all production systems with no safe change window despite legacy barcode readers have separate integration API
- Accept continued exposure of session confidentiality without any owner, expiry or compensating verification because legacy barcode readers have separate integration API
- Claim weak TLS protocol/cipher accepted is patched when the change ticket opens, without confirming edge termination with secure profile until backend rebuilt or a planned permanent change
- Apply a time-bound compensating measure, edge termination with secure profile until backend rebuilt, record the residual risk owner and schedule the tested permanent fix
Explanation
Correct Answer
D:Edge termination with secure profile until backend rebuilt can reduce short-term exposure while legacy barcode readers have separate integration API delays full remediation. The exception must have a defined owner, expiry, monitoring and tested repair plan because session confidentiality remains at stake.
Incorrect Answers
A:Ignoring legacy barcode readers have separate integration API could cause avoidable service failure and is not a risk-aware remediation process.
B:Business criticality increases the need for accountable decisions and review; it does not make session confidentiality irrelevant.
C:A work item is not proof that weak TLS protocol/cipher accepted was corrected or even that edge termination with secure profile until backend rebuilt operates.
Question 204
At Rail operator, the security team assesses customer account endpoint. The current issue is weak TLS protocol/cipher accepted; assessment evidence states: scanner completes TLS 1.0 handshake from internet. The owner reports that disable obsolete protocols and select modern cipher policy has been deployed. What evidence should close the vulnerability item?
- Use an unrelated server’s clean findings to claim customer account endpoint is fixed without retesting the affected path
- Suppress future results for weak TLS protocol/cipher accepted so that the vulnerability dashboard shows a completed remediation
- Retest the originally affected configuration using recheck negotiated protocol with independent client across frontends, confirm the vulnerability is gone and record change evidence
- Close scanner completes TLS 1.0 handshake from internet after the deployment tool returns success, without verifying the current state of customer account endpoint
Explanation
Correct Answer
C:Closure requires checking the same affected path identified by scanner completes TLS 1.0 handshake from internet, plus regression impact on customer account endpoint. A change ticket alone is not proof of removal of weak TLS protocol/cipher accepted.
Incorrect Answers
A:The result must be tied to customer account endpoint and the actual exposure: public web service for tickets.
B:Suppression may hide a failed or incomplete fix, leaving session confidentiality exposed despite the administrative record.
D:Process completion is not evidence that scanner completes TLS 1.0 handshake from internet no longer applies to customer account endpoint.
Question 205
At National logistics operator, analysts apply the Diamond Model to reports concerning third-party tracking provider: vendor discloses credential compromise affecting shared fleet API. Evidence includes provider notification and local API access logs show abnormal read volumes, but no adversary has been reliably identified. Which representation preserves the observed relationships without invented attribution?
- Assign a specific nation-state to vendor discloses credential compromise affecting shared fleet API and consider all other Diamond Model elements established automatically
- Record third-party tracking provider as the observed victim, the technical action as the capability, any infrastructure evidenced by provider notification and local API access logs show abnormal read volumes, and adversary identity as unknown
- Treat third-party tracking provider as the attacker infrastructure and an unnamed public target as the only victim without analyzing the actual incident path
- Use the Diamond Model name as permission to delete raw provider notification and local API access logs show abnormal read volumes and replace it with a presumed actor narrative
Explanation
Correct Answer
B:The Diamond Model separates victim, capability, infrastructure and adversary. The logs support observed behavior at third-party tracking provider but do not establish a named adversary.
Incorrect Answers
A:Neither provider notification and local API access logs show abnormal read volumes nor event type identifies a particular actor; attribution requires additional independent intelligence.
C:The provided evidence names third-party tracking provider as the affected environment. Reversing roles obscures which entity is actually being victimized.
D:Modeling relates evidence; it does not replace source preservation or justify inventing a history of vendor discloses credential compromise affecting shared fleet API.
Question 206
At National logistics operator, the incident team supports third-party tracking provider. A new security event is reported: vendor discloses credential compromise affecting shared fleet API. The log clue is: provider notification and local API access logs show abnormal read volumes. The team expects later legal and technical review. Which acquisition step best preserves a defensible evidence trail?
- Rebuild third-party tracking provider first and collect the volatile evidence for vendor discloses credential compromise affecting shared fleet API afterward
- Alter original provider notification and local API access logs show abnormal read volumes entries to remove irrelevant records before preserving the forensic timeline
- Keep only a screenshot of provider notification and local API access logs show abnormal read volumes, discarding original artifacts such as preserve vendor advisory, local token logs and contract incident notifications
- Preserve and hash incident artifacts: preserve vendor advisory, local token logs and contract incident notifications
Explanation
Correct Answer
D:Preserve vendor advisory, local token logs and contract incident notifications retains relevant source context and integrity checks so the team can reconstruct vendor discloses credential compromise affecting shared fleet API and support an auditable chain of custody.
Incorrect Answers
A:Volatile evidence relevant to vendor discloses credential compromise affecting shared fleet API may disappear during remediation or reboot.
B:Changing the original provider notification and local API access logs show abnormal read volumes compromises provenance and makes later findings harder to verify.
C:A screenshot cannot replace the underlying preserve vendor advisory, local token logs and contract incident notifications needed to establish sequence and integrity.
Question 207
At National logistics operator, the incident team supports third-party tracking provider. A new security event is reported: vendor discloses credential compromise affecting shared fleet API. The log clue is: provider notification and local API access logs show abnormal read volumes. The incident remains active, but third-party tracking provider is operationally important. Which containment decision is most appropriate now?
- Disconnect every service at National logistics operator, regardless of whether it has a dependency on the affected third-party tracking provider
- Publish a speculative full-incident attribution notice before constraining the active behavior vendor discloses credential compromise affecting shared fleet API
- Erase provider notification and local API access logs show abnormal read volumes to reduce alert volume rather than isolating the observed attacker route
- Execute scoped containment: revoke shared integration tokens and restrict affected API scopes while maintaining manual routing
Explanation
Correct Answer
D:Revoke shared integration tokens and restrict affected API scopes while maintaining manual routing stops or limits the observed path while balancing continuity of third-party tracking provider. It is a response to the current incident, not a replacement for evidence handling.
Incorrect Answers
A:Broad interruption may unnecessarily affect third-party tracking provider; containment should be scoped to evidenced systems and approved critical-service requirements.
B:Communication matters, but active vendor discloses credential compromise affecting shared fleet API requires proportionate containment and evidence preservation first.
C:Erasing provider notification and local API access logs show abnormal read volumes neither blocks attacker access nor supports a reliable subsequent recovery decision.
Question 208
At National logistics operator, the incident team supports third-party tracking provider. A new security event is reported: vendor discloses credential compromise affecting shared fleet API. The log clue is: provider notification and local API access logs show abnormal read volumes. The active incident path is now isolated and evidence is retained. What should eradication focus on before service is restored?
- Restore third-party tracking provider without first correcting the access and persistence cause addressed by issue unique rotated credentials and remove undocumented shared accounts
- Use only the original firewall block and assume it has also removed all persistence behind vendor discloses credential compromise affecting shared fleet API
- Remove the attack’s established access and persistence: issue unique rotated credentials and remove undocumented shared accounts
- Rewrite the playbook for third-party tracking provider but leave the confirmed malicious access mechanism active
Explanation
Correct Answer
C:Issue unique rotated credentials and remove undocumented shared accounts targets the mechanism behind vendor discloses credential compromise affecting shared fleet API, reducing recurrence when third-party tracking provider returns to normal operations.
Incorrect Answers
A:Recovery before issue unique rotated credentials and remove undocumented shared accounts could reintroduce the same compromise path.
B:Containment can stop communication without eliminating the root access that produced provider notification and local API access logs show abnormal read volumes.
D:Updated paperwork does not eradicate the mechanism behind vendor discloses credential compromise affecting shared fleet API.
Question 209
At National logistics operator, the incident team supports third-party tracking provider. A new security event is reported: vendor discloses credential compromise affecting shared fleet API. The log clue is: provider notification and local API access logs show abnormal read volumes. Containment and eradication are complete. Which recovery acceptance test should precede release of third-party tracking provider to normal users?
- Perform controlled return-to-service validation: validate fleet tracking and API authorization with new keys across depots
- Expose third-party tracking provider to users before confirming that the conditions behind vendor discloses credential compromise affecting shared fleet API are absent
- Approve recovery of third-party tracking provider when it boots, without executing the test validate fleet tracking and API authorization with new keys across depots
- Delete preserved evidence including preserve vendor advisory, local token logs and contract incident notifications as soon as the service restarts
Explanation
Correct Answer
A:Validate fleet tracking and API authorization with new keys across depots demonstrates that the compromised pathway is absent while third-party tracking provider again supports legitimate business processes. Verified recovery differs from mere uptime.
Incorrect Answers
B:Without a clean functional/security validation, third-party tracking provider could immediately face the same exploit condition.
C:A boot event cannot prove validate fleet tracking and API authorization with new keys across depots or protect the service from recurrence of vendor discloses credential compromise affecting shared fleet API.
D:Evidence retention obligations continue beyond restart; preserve vendor advisory, local token logs and contract incident notifications may be required for subsequent review.
Question 210
At National logistics operator, the incident team supports third-party tracking provider. A new security event is reported: vendor discloses credential compromise affecting shared fleet API. The log clue is: provider notification and local API access logs show abnormal read volumes. The incident has been contained and normal service has resumed. A post-incident review identifies that single long-lived shared partner token lacked rotation owner. Which improvement should be prioritized?
- Discipline the whole on-duty response shift rather than examining the documented weakness single long-lived shared partner token lacked rotation owner
- Close the follow-up for third-party tracking provider merely because restoration completed, without addressing single long-lived shared partner token lacked rotation owner
- Write a lessons-learned memo about vendor discloses credential compromise affecting shared fleet API with no due date, control owner or validation activity
- Assign an owner and measurable corrective action addressing the root cause: single long-lived shared partner token lacked rotation owner, with a future effectiveness test
Explanation
Correct Answer
D:Single long-lived shared partner token lacked rotation owner was the systemic weakness that enabled or worsened vendor discloses credential compromise affecting shared fleet API. 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: single long-lived shared partner token lacked rotation owner.
B:Service restoration does not address single long-lived shared partner token lacked rotation owner; ignoring it leaves the next incident likely to follow the same route.
C:An unowned recommendation does not produce a verified control improvement for third-party tracking provider.
