220-1102 Question 737
Single answerIncident documentationA help desk technician receives a call from an employee who reports that several project files were suddenly encrypted and renamed, and a ransom note appeared on the desktop. The technician isolates the workstation from the network and escalates the issue to the security team. Before handing off the incident, which action is MOST appropriate to include in the incident documentation?
- A
Record the time the issue was reported, affected system details, observed symptoms, and the containment step that was taken
- B
Wait to document anything until the security team confirms whether the event is actually malware
- C
Write only a brief note stating that the PC was infected so the ticket can be closed quickly
- D
Delete temporary files and clear the user's desktop so the documentation reflects the system's cleaned state
Show answer and explanation
Correct answer: A
Explanation
Incident documentation in A+ Core 2 focuses on creating an accurate, objective, and timely record of what happened, what was observed, and what actions were taken. In a potential malware or ransomware event, the technician should document the report time, user details, affected device, symptoms, scope if known, and containment steps such as disconnecting the machine from the network. This supports escalation, preserves important facts for security teams, and aligns with standard incident response practices such as maintaining a clear timeline and avoiding unnecessary changes to the affected system. Good documentation is specific and factual, while poor documentation is delayed, vague, or destructive to evidence.
- A. Correct.
Correct. Good incident documentation should capture factual, time-based details such as when the issue was reported, which asset was affected, what symptoms were observed, and what immediate actions were taken. In this scenario, documenting the ransom note, encrypted files, hostname or asset tag, user report, and network isolation provides a clear record for escalation, investigation, and possible chain-of-custody needs.
- B. Incorrect.
Incorrect. Documentation should begin as soon as the incident is identified, not after full confirmation. Waiting can lead to lost details, incomplete timelines, and poor handoff to security personnel. Early, accurate notes are a standard best practice in incident response.
- C. Incorrect.
Incorrect. A vague statement such as 'PC was infected' is insufficient for incident documentation. It omits key facts needed for troubleshooting, escalation, trend analysis, and post-incident review. Incident records should be specific, objective, and complete enough for another technician or analyst to continue the work.
- D. Incorrect.
Incorrect. Deleting files or altering the workstation before proper investigation can destroy evidence and make the incident harder to analyze. Documentation should reflect what was observed and what containment actions were performed, not a modified or sanitized view of the system.