ITIL Foundation V5 common mistakes
ITIL Foundation V5 · Understand the traps and how to avoid them.
Treating the seven guiding principles as a sequential checklist that must be completed in order before any decision is made, and then picking the 'first' or 'most important' principle as a single answer to a scenario question.
The principles are easy to memorise as a numbered list, so candidates import a procedural mental model from project-methodology exams and assume ordering implies priority. Questions rarely ask which principle applies alone; they describe a situation where several principles interact and ask what the guidance as a whole implies.
What to do instead
Learn each principle as a lens with a trade-off: focus on value vs start where you are, progress iteratively vs collaborate and promote visibility, keep it simple vs optimise and automate. For every practice question, ask what the scenario's constraint is (speed, cost, risk, adoption) and select the principle that resolves that constraint, accepting that several may be relevant. Be ready to explain why one is the best fit rather than the only one.
Reading 'focus on value' as 'deliver what the customer literally asks for' and choosing answers that satisfy a stated requirement even when the outcome for the consumer is worse.
Everyday service culture rewards requirement compliance, so candidates map 'value' onto 'delivered scope'. The exam instead defines value by the consumer's perception of outcomes, costs and risks, which can diverge sharply from the written request.
What to do instead
For any scenario, restate it in outcome, cost and risk terms from the consumer's side before looking at the options. Eliminate options that merely complete a deliverable without improving an outcome or reducing a consumer-side risk. Prefer options that verify the consumer's perception, such as validating outcomes with users, over options that confirm the specification was met.
Classifying a scenario as 'utility' or 'warranty' based on whether the topic sounds like a feature versus a support activity, rather than testing whether the described attribute is fitness for purpose or fitness for use.
Utility and warranty are short definitions that feel obvious, so candidates stop at keyword matching. Many scenario attributes (availability, capacity, security, continuity) sound like features but are warranty conditions, and some features are described in service-level language.
What to do instead
Apply a fixed two-question test to each attribute: does it make the service fit for purpose (utility, what it does), or fit for use (warranty, how well it performs under agreed conditions)? Memorise warranty's four dimensions as availability, capacity, continuity and security, and treat any attribute about assurance, resilience or assurance levels as warranty regardless of phrasing.
Describing the service value chain as a linear lifecycle, so that 'engage' is always first and 'improve' always last, and rejecting answers in which value chain activities are combined, repeated or entered at different points.
The familiar lifecycle shape of older frameworks encourages a stage-by-stage mental model. Candidates then misjudge questions about how activities interconnect, or about where a practice such as continual improvement touches the chain.
What to do instead
Draw the value chain as six activities (plan, improve, engage, design and transition, obtain and build, deliver and support) connected as a flexible system with no mandated start or end. Practise mapping a single scenario to two or three activities simultaneously, and note that improve is both a chain activity and an embedded concern across all the others.
Assuming the four dimensions are an ordered checklist or that one dimension (usually organisations and people, or value streams and processes) is the 'main' one, then choosing an answer that fixes only that dimension for a problem spanning several.
The dimensions are presented as a short list, so candidates default to prioritising the human or process dimension because those dominate day-to-day work. Real scenario questions often hinge on partners and suppliers or on information and technology, which candidates under-weight.
What to do instead
For every scenario, explicitly name the impact on all four dimensions before evaluating options: organisations and people, information and technology, partners and suppliers, value streams and processes. Eliminate any option that resolves the stated symptom in one dimension while leaving an obvious gap in another, and prefer options that address the dimension the scenario actually highlights.
Treating practices as rigid processes with mandatory inputs, outputs and owners, and selecting answers that prescribe a single 'correct' sequence of activities rather than the purpose and flexibility of the practice.
Practice names resemble process names, and many candidates have process-mapping habits. The exam emphasises purpose, and the flexibility of practices to be adapted, so sequence-fixated answers are usually distractors.
What to do instead
For each practice, memorise its purpose statement and the two or three key concepts, then ask what outcome the scenario needs rather than what step comes next. When two options both sound procedural, prefer the one that references the practice's purpose or a principle-consistent adaptation over the one that imposes a fixed workflow.
Confusing the purpose and scope of closely adjacent practices, such as incident management versus problem management, service request management versus incident management, or change enablement versus deployment management, and choosing the neighbouring practice's terminology.
These practice pairs share vocabulary (restore, cause, request, change, release) and candidates learn definitions in isolation without contrasting them, so under time pressure the nearest familiar word wins.
What to do instead
Build contrast pairs: incident restores service quickly while problem reduces the likelihood and impact of incidents by managing causes and known errors; a service request is a normal, pre-approved user request while an incident is an unplanned interruption or degradation; change enablement authorises change while deployment moves it into live use. For each scenario, identify whether the question is about restoring, preventing, fulfilling or authorising before reading the options.
Treating continual improvement as a post-incident or periodic review activity owned by a specialist team, and rejecting answers where improvement is continuous, embedded in daily work, or driven by measurement of the whole value system.
Improvement is often experienced as a retrospective or an annual programme, so candidates model it as an event with a start and end. The exam frames it as an ongoing activity that applies at every level and to every part of the value system.
What to do instead
Anchor on the improvement model as an iterative, non-linear cycle that can be entered at any point and repeated, and on the idea that everyone contributes to improvement. When an option says improvement happens only after a failure, only at set intervals, or only within one team, treat it as a likely distractor; prefer options that measure outcomes and feed learning back into the value system.
Answering organisational change questions with a purely technical or structural solution, such as updating a tool, redrawing an org chart, or issuing a new policy, when the scenario describes resistance, low adoption or unclear sponsorship.
Candidates with delivery or engineering backgrounds default to structural fixes, and change management content feels softer and less examinable, so it gets skimmed. Scenario questions deliberately describe people-side symptoms to test whether the candidate selects a people-side response.
What to do instead
When a scenario mentions resistance, adoption, motivation, communication or sponsorship, eliminate tooling and restructuring options first. Look for answers that address stakeholder engagement, clear and repeated communication of the why, visible sponsorship, and involvement of affected people early, and be able to distinguish these from the mechanics of managing a change to a service.
Choosing answers that describe what a practice or role does without linking it to value creation, such as picking an option that lists activities but never mentions outcomes, costs, risks or the consumer.
Definition recall is the easiest thing to revise, so candidates reward options that match memorised wording and overlook whether the option answers the question actually asked about value. Distractors are often accurate descriptions placed in the wrong context.
What to do instead
Before selecting, check the chosen option against the question's stem: does it address the outcome the scenario needs, or does it merely describe a correct-sounding activity? Prefer options that connect the activity to a consumer outcome, a reduced risk, or an optimised cost, and treat technically accurate but context-free descriptions as traps.