ITIL Management Practices →mediumMultiple Choice

ITIL4F ITIL Management Practices Practice Question

An organization identifies that a recurring incident is caused by a faulty network cable. According to ITIL 4, when should this be documented as a known error?

⚠ Common exam trap

Candidates often confuse the timing of documenting a known error with the timing of implementing the permanent fix, mistakenly thinking the known error is only recorded after the cable is replaced or the problem is fully resolved.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

After root cause analysis and a workaround is found

In ITIL 4, a known error is documented after root cause analysis has been performed and a workaround has been identified, even if the permanent fix has not yet been implemented. This allows the service desk to quickly resolve future incidents caused by the same underlying problem using the documented workaround. The faulty network cable is a recurring incident, so the problem management process would first diagnose the root cause (the faulty cable) and then create a known error record with the workaround (e.g., replacing the cable or using a spare port).

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
When the problem record is closed
Why it's wrong here
A known error is identified and documented during the problem management process, specifically after root cause analysis has been completed but typically before the problem record is closed. The problem record might remain open for an extended period while a permanent solution is being developed or implemented. Closing the problem record usually signifies that the underlying issue has been permanently resolved or accepted, which is a stage beyond the initial identification of a known error and its workaround.
✗
When the incident is first reported
Why it's wrong here
When an incident is first reported, its underlying cause is typically unknown, making it impossible to classify it as a known error at this initial stage. At the point of first report, it is merely an unplanned interruption to a service, requiring immediate restoration efforts. Identifying a known error requires subsequent investigation, diagnosis, and root cause analysis, which are activities performed as part of the problem management practice, not during initial incident logging.
✓
After root cause analysis and a workaround is found
Why this is correct
A known error is formally identified in ITIL when the root cause of one or more recurring incidents has been determined, and a temporary workaround has been successfully developed and documented. This critical step allows for quicker restoration of service for future occurrences of the same incident, even if a permanent solution is not yet implemented. This status transitions an unknown problem into a manageable known error, enabling proactive incident management and improving service desk efficiency.
✗
After the cable is replaced
Why it's wrong here
Replacing a faulty cable constitutes a resolution to a specific incident, restoring service functionality and bringing the incident to a close. While this action might resolve the immediate incident, it does not inherently define a 'known error' in ITIL terms. A known error specifically refers to a problem whose root cause is understood and for which a documented workaround exists, even if the underlying issue persists or a permanent fix is pending. Resolving an incident focuses on service restoration, whereas identifying a known error is about understanding and managing the underlying problem.

Visual reference

Go deeper

ITIL4F ITIL Management Practices Practice Question

Why each option matters

Option-by-option breakdown

Related to this question