PeopleCert / AXELOSITILFND V57 domains

ITILFND V5 Exam Notes

Last-minute traps, must-know facts, and scenario tips for the ITIL Foundation (Version 5) exam.

General Exam Tips

1.Read ALL four answer options before selecting — ITIL questions often have two plausible-sounding answers where one has a subtle flaw in phrasing.
2.Watch for the word 'BEST' — it signals that multiple answers may be partially correct but only one is the most ITIL-aligned choice.
3.Answer based on ITIL definitions, not how your organization actually works. Real-world experience can actively mislead you.
4.There is no penalty for guessing — never leave a blank. If unsure, eliminate two and pick the better of the remaining two.
5.With 40 questions in 60 minutes, you have 90 seconds per question. Flag uncertain ones and return — don't get stuck.
6.Scenario questions describe a situation then ask which ITIL concept applies. Identify the key action or outcome in the scenario before evaluating answers.
7.The SVS domain (40% weight) alone could be the difference between passing and failing. Know all five components cold.
8.On guiding principle questions, look for the principle whose core purpose directly matches the scenario — not just one that could loosely apply.

Quick Navigation

Key ITIL Terms and Definitions The ITIL Service Value System Four Dimensions of Product and Service Management Product and Service Lifecycle Value Stream Identification, Mapping, and Management ITIL and Artificial Intelligence ITIL and Other Frameworks

Domain 130% of exam

Key ITIL Terms and Definitions

Must-Know Facts

Service = a means of enabling value co-creation by facilitating outcomes customers want to achieve, WITHOUT the customer having to manage specific costs and risks. The 'without managing costs and risks' part is tested.
Utility = fit for PURPOSE (what the service DOES, its functionality). Warranty = fit for USE (how WELL the service performs — availability, capacity, security, continuity). BOTH required for value.
Output = a tangible or intangible deliverable produced by an activity. Outcome = the result a stakeholder achieves through using a service or output — the actual change in state that matters.
Customer = defines requirements and is accountable for outcomes. User = uses the service daily. Sponsor = authorizes the budget. One person can hold multiple roles simultaneously.
Value co-creation: providers do NOT deliver value TO customers — value is co-created through active interaction between provider and consumer.
Risk = a possible event that could cause harm or loss. Services reduce risk for customers by taking on management of those activities.
XLA (Experience Level Agreement) = measures user experience and perceived value, subjective satisfaction. SLA = measures technical performance metrics (availability %, response times). An SLA-compliant service can still fail by XLA standards.
Product = a configuration of an organization's resources designed to offer value for a consumer. Products are offerings; services are how value is co-created through those products.

Common Traps

TrapUsing 'output' and 'outcome' interchangeably because both sound like 'what you get.'

RealityOutput = the deliverable (deployed software, generated report, configured server). Outcome = the change in state that results from using that deliverable (improved productivity, better decisions). Outputs enable outcomes. They are never the same thing.

TrapThinking a service with great utility (functionality) is valuable even if it has poor warranty (reliability).

RealityBOTH utility AND warranty must be present for a service to create value. Powerful software that crashes constantly has utility but no warranty. Perfectly available software that does nothing useful has warranty but no utility. Neither creates value alone.

TrapEquating 'customer' with 'user' because both interact with the service.

RealityThe customer defines requirements and is accountable for outcomes. The user runs the service day-to-day without owning requirements or outcomes. In an enterprise payroll scenario, the HR head (customer) owns requirements; HR staff (users) run payroll. Distinct roles with distinct responsibilities.

TrapThinking a service provider 'delivers value' to customers.

RealityITIL 5 is explicit: value is co-created, not delivered. The provider creates conditions for value; the customer participates through defining needs, using the service, and providing feedback. Questions that say 'the provider delivers value' are testing this exact trap.

TrapConfusing XLAs and SLAs as alternatives where one replaces the other.

RealityXLAs complement SLAs — they do not replace them. SLAs measure technical metrics; XLAs capture the human experience of the service. A high SLA score with low user satisfaction means the SLA is passing while the XLA is failing.

TrapTreating 'risk' as always negative in ITIL.

RealityITIL acknowledges that risk includes both negative potential (harm) and positive potential (opportunity). More importantly, services are valuable partly because they transfer risk from the customer to the provider — the customer no longer manages those uncertainties.

Confusing Pairs

OutputOutcome

Output = something produced (deployed app, generated report, configured server) — countable, visible. Outcome = the result that matters to the stakeholder (improved productivity, cost reduction, better customer satisfaction) — the reason the output was created. Key test: can you see/count it directly? Output. Is it the 'so what' behind the deliverable? Outcome.

UtilityWarranty

Utility = WHAT the service does (fit for purpose, functionality). Warranty = HOW WELL it performs (fit for use: availability, capacity, security, continuity). Exam trick: read the scenario carefully — does it describe functionality gaps (utility problem) or reliability/performance gaps (warranty problem)?

CustomerSponsor

Customer = defines requirements, accountable for outcomes the service supports. Sponsor = authorizes the budget and approves investment. In many scenarios the same person holds both roles, but when roles are separated: the executive who writes the check is the sponsor; the department head who specifies needs is the customer.

SLAXLA

SLA = formal agreement on measurable technical targets (availability %, response times, resolution times). XLA = measure of actual user experience and perceived value (satisfaction scores, sentiment). SLA answers: 'Did we meet the target?' XLA answers: 'Did users actually feel good about the service?'

RiskIssue

Risk = a possible future event that could cause harm or prevent objectives being met (uncertainty, not yet happened). Issue = a problem that has ALREADY occurred and needs management. Exam questions presenting past problems are describing issues; presenting potential future problems are describing risks.

Scenario Tips

If the question asks about:

When the scenario describes software that is available 99.9% of the time and meets all performance benchmarks, but users find it confusing and it does not support how they actually work...

Answer:

The service has high WARRANTY but lacks UTILITY. Performance = warranty. Functionality mismatch = utility problem.

Distractor to avoid:

Option 'lacks both utility and warranty' is tempting if you misread the uptime stats as not mattering. But those benchmarks clearly satisfy warranty. The functionality gap is the only problem.

If the question asks about:

When a question asks whether value is 'delivered by' the provider or 'co-created with' the consumer...

Answer:

Always co-created. ITIL 5 is explicit that value is not a one-way delivery — it emerges from the interaction between provider and consumer.

Distractor to avoid:

'The provider delivers value to the customer' is a natural-sounding phrase that appears as a trap answer. It is incorrect in ITIL 5 terminology.

If the question asks about:

When asked to identify the ITIL stakeholder role of someone who 'approves the annual IT budget for the service'...

Answer:

Sponsor. Budget authorization is the defining characteristic of the sponsor role.

Distractor to avoid:

A CFO who approves budgets might also 'benefit from' the service, making them seem like a customer. But the defining action here is budget authorization = sponsor.

If the question asks about:

When a question states that a service 'eliminates the need for customers to manage the associated risks and costs themselves' and asks what ITIL concept this illustrates...

Answer:

This is the value creation aspect of services — services transfer risk and cost management from the customer to the provider. This is part of the service definition itself.

Distractor to avoid:

Warranty sounds right because warranty guarantees reliability. But warranty addresses HOW WELL the service performs, not the transfer of risk/cost management to the provider. The risk-transfer aspect is part of what makes a service valuable by definition.

Last-Minute Facts

1Exam: 40 questions, 60 minutes, passing score 65% (26/40 correct). No negative marking — always answer every question.

2Utility = fit for PURPOSE. Warranty = fit for USE. Both required. Neither alone = value.

3Three stakeholder roles: Customer (defines requirements, owns outcomes), User (uses daily), Sponsor (approves budget).

4Value is co-created, not delivered. Provider + consumer interaction creates value.

5XLA = experience/satisfaction (subjective). SLA = technical performance (objective).

6Risk = possible future event. Issue = problem that has already occurred.

Domain 240% of exam

The ITIL Service Value System

Must-Know Facts

The SVS has exactly FIVE components: (1) Guiding Principles, (2) Governance, (3) Service Value Chain, (4) Practices, (5) Continual Improvement. Know this cold.
SVS inputs = opportunity and demand. SVS output = value. The SVS converts demand/opportunity into value.
All SEVEN guiding principles in order: Focus on Value, Start Where You Are, Progress Iteratively with Feedback, Collaborate and Promote Visibility, Think and Work Holistically, Keep It Simple and Practical, Optimize and Automate.
Guiding principles are RECOMMENDATIONS — universal guidance that can be applied in any circumstance but are NOT mandatory rules or compliance requirements.
The Service Value Chain has SIX activities: Plan, Improve, Engage, Design and Transition, Obtain/Build, Deliver and Support. These are NOT a linear sequence — they are flexible building blocks.
The Continual Improvement Model has SEVEN steps in order: What is the vision? → Where are we now? → Where do we want to be? → How do we get there? → Take action → Did we get there? → How do we keep the momentum going? The model is circular.
Governance EVALUATES, DIRECTS, and MONITORS — it is top-level oversight and direction, not day-to-day management.
Practices = sets of organizational resources (people, processes, technology, information) designed to achieve objectives. NOT the same as 'processes.'
The Continual Improvement Model applies at ALL levels: services, practices, teams, individuals — not just major IT transformation projects.
ITIL 5 adds the Product and Service Lifecycle (8 stages) as a new framework operating alongside the SVS. The Service Value Chain remains an SVS component; the 8-stage lifecycle is a separate, complementary delivery model for products and services.

Common Traps

TrapListing 'processes' as the fourth SVS component instead of 'practices.'

Reality'Practices' is the correct term in ITIL 5. A practice is broader than a process — it encompasses people, technology, and information, not just process steps. This exact substitution ('processes' vs 'practices') appears as a trap answer in SVS component questions.

TrapTreating the service value chain as a linear conveyor belt where activities follow a fixed sequence.

RealityThe service value chain activities can be combined in ANY order to form value streams. Different scenarios create different paths through the activities. No fixed sequence exists. Every activity can interact with every other activity, and all connect to 'Improve.'

TrapConfusing the SVS (the whole model) with the service value chain (one part of it).

RealityThe SVS is the complete model with 5 components. The service value chain is ONE of those 5 components, itself containing 6 activities. Questions about the SVS require naming all 5 components. Questions about the service value chain require naming the 6 activities.

TrapTreating governance and management as the same SVS component.

RealityGovernance = top-level evaluation, direction, and monitoring (oversight). Management = day-to-day execution of activities. Governance is explicitly a separate SVS component. 'Management' is NOT an SVS component — 'governance' is.

TrapTreating guiding principles as mandatory rules that must always be followed.

RealityThe word 'principle' is deliberate. They are recommendations that should be considered and applied as relevant to the situation. Not all principles apply equally in every scenario. The exam tests whether you know WHICH principle best fits a given context, not that all seven always apply.

TrapThinking the Continual Improvement Model is only for large projects or formal improvement programs.

RealityThe model applies at ALL levels — individual tasks, team practices, specific services, and organization-wide strategy. It is circular and continuous, not a one-time project framework.

TrapConfusing 'Optimize and Automate' with just 'automate.'

RealityThe correct sequence is: optimize FIRST (remove waste, simplify), THEN automate. Automating a broken or wasteful process scales the problems. This principle name and its sequence is testable.

Confusing Pairs

Service Value System (SVS)Service Value Chain

SVS = the complete model (5 components: guiding principles, governance, service value chain, practices, continual improvement). Service Value Chain = ONE component of the SVS, consisting of 6 activities. The SVS contains the chain; the chain is not the SVS. Key exam tell: if a question lists 'value streams' instead of 'service value chain' as the component, it is wrong.

Guiding PrinciplesGovernance

Guiding Principles = bottom-up universal recommendations anyone can apply in any situation. Governance = top-down oversight that evaluates, directs, and monitors to ensure accountability. Both are SVS components but serve completely different purposes. Guiding principles guide action; governance controls direction.

PracticesProcesses

Practice = a set of organizational resources (people, processes, technology, information) designed to achieve an objective. A process is one element within a practice. ITIL 5 uses 'practices' — using 'processes' as an SVS component is a deliberate trap answer.

Focus on Value (Principle 1)Keep It Simple and Practical (Principle 6)

Focus on Value = link everything to value creation for stakeholders — the WHY of any action. Keep It Simple and Practical = use minimum steps to achieve the objective, eliminate waste — the HOW of designing solutions. Scenario: 'why should this initiative exist?' = Focus on Value. 'This process has 12 redundant steps' = Keep It Simple.

Start Where You Are (Principle 2)Optimize and Automate (Principle 7)

Start Where You Are = before redesigning, assess what already exists and reuse what works. It is about avoiding waste of existing assets. Optimize and Automate = after you understand the current state, improve the workflow and automate the optimized version. Start Where You Are answers 'should we redesign from scratch?' (no). Optimize and Automate answers 'what do we do with the improved process?' (automate it).

Scenario Tips

If the question asks about:

When a question asks which guiding principle applies when a manager wants to 'rebuild everything from scratch' and a team member says 'we already have tools and data that work'...

Answer:

'Start Where You Are' — assess existing capabilities before discarding them. The team member is applying this principle to avoid wasting working assets.

Distractor to avoid:

'Keep It Simple and Practical' sounds right because starting from scratch seems overly complex, but that principle is about minimizing steps, not about preserving existing work.

If the question asks about:

When a question asks which component of the SVS is missing from a list and the list reads 'guiding principles, governance, service value chain, processes, continual improvement'...

Answer:

'Processes' should be 'Practices' — the correct fifth component is Practices (not processes). This is one of the most common SVS trap questions.

Distractor to avoid:

The list otherwise looks complete which makes 'processes' easy to accept. But ITIL 5 does not list 'processes' as an SVS component.

If the question asks about:

When the scenario shows an organization measuring both resolution times (improved) and user satisfaction (still low), and asks which step of the Continual Improvement Model they are in...

Answer:

'Did we get there?' — they are evaluating whether the improvement achieved its goals by measuring actual results. Finding a gap means the improvement was not sufficient.

Distractor to avoid:

'Where are we now?' is tempting because they are clearly assessing their situation. But that step is the initial baseline assessment, not the post-action evaluation. Measuring after taking action = 'Did we get there?'

If the question asks about:

When asked which SVS component enables governance in an organization, and the options include both 'governance' and 'guiding principles'...

Answer:

Governance — it is the SVS component that evaluates, directs, and monitors. Guiding principles guide individual decisions but are not governance.

Distractor to avoid:

Guiding principles can seem like governance because they guide behavior. But governance has specific authority to set direction and enforce accountability — guiding principles are voluntary recommendations.

If the question asks about:

When a question describes a team implementing improvements in small batches and reviewing results before making the next change...

Answer:

'Progress Iteratively with Feedback' — the defining characteristic is small iterations with review before proceeding.

Distractor to avoid:

'Collaborate and Promote Visibility' might seem right if the scenario mentions sharing results. But the core behavior is iterative delivery with feedback loops, not collaboration.

Last-Minute Facts

1SVS = exactly 5 components: Guiding Principles, Governance, Service Value Chain, Practices, Continual Improvement.

2Service Value Chain = exactly 6 activities: Plan, Improve, Engage, Design and Transition, Obtain/Build, Deliver and Support.

3Continual Improvement Model = exactly 7 steps (vision → now → target → plan → act → measure → sustain). Circular.

47 Guiding Principles: Focus on Value, Start Where You Are, Progress Iteratively with Feedback, Collaborate and Promote Visibility, Think and Work Holistically, Keep It Simple and Practical, Optimize and Automate.

5Governance = evaluate, direct, monitor. Not 'manage.'

6Principles are RECOMMENDATIONS, not rules. Apply as relevant.

7Optimize THEN automate — never automate first.

Domain 310% of exam

Four Dimensions of Product and Service Management

Must-Know Facts

The four dimensions: (1) Organizations and People, (2) Information and Technology, (3) Partners and Suppliers, (4) Value Streams and Processes. ALL four must be considered for any service or practice.
Organizations and People = team structures, culture, roles, competencies, responsibilities, staffing.
Information and Technology = data, knowledge, IT infrastructure, AI tools, communication systems, and emerging technologies.
Partners and Suppliers = external organizations contributing to service delivery: cloud providers, software vendors, outsourcing partners, service integrators.
Value Streams and Processes = specific activities, workflows, controls, and procedures that transform inputs into valuable outputs and outcomes.
PESTLE (Political, Economic, Social, Technological, Legal, Environmental) = external factors that sit OUTSIDE the four dimensions and influence all of them. Organizations cannot control PESTLE factors — they must respond to them.
Neglecting any ONE of the four dimensions creates service failures even if the others are well-managed.

Common Traps

TrapTreating PESTLE as a fifth dimension of service management.

RealityPESTLE is NOT a dimension — it is the external environment that constrains and influences all four dimensions from outside. There are four dimensions, not five. A PESTLE factor like new privacy legislation affects all four dimensions simultaneously.

TrapConfusing the four dimensions with the five SVS components.

RealityThe four dimensions and the SVS are separate ITIL frameworks. Dimensions are lenses for examining services; the SVS describes how value is created. A question asking about the SVS is not asking about the four dimensions.

TrapThinking 'Partners and Suppliers' only covers traditional procurement contracts.

RealityPartners and Suppliers includes any external organization contributing to service delivery: cloud providers (AWS, Azure), SaaS vendors, open-source communities, and strategic partners. The relationship type (partnership vs. commodity contract) also matters in this dimension.

Confusing Pairs

Organizations and PeopleValue Streams and Processes

Organizations and People = WHO does the work: team structure, roles, skills, culture, reporting lines. Value Streams and Processes = HOW the work flows: the specific activities, handoffs, controls, and workflows. Scenario about team ownership and staffing = O&P. Scenario about workflow steps and handoffs = VS&P.

Information and TechnologyPartners and Suppliers

Information and Technology = the tools, data, platforms, and infrastructure used internally. Partners and Suppliers = the EXTERNAL organizations that provide those tools or services. The cloud platform itself = I&T. The cloud vendor relationship = P&S.

PESTLE factorsFour Dimensions

Four dimensions = internal organizational perspectives for examining any service. PESTLE = external environment constraints the organization cannot control. PESTLE (Legal factor: new data privacy law) = outside the dimensions. An organization's response to that law across all four dimensions = inside the dimensions.

Scenario Tips

If the question asks about:

When the scenario describes 'new data privacy legislation requiring local data storage' forcing a cloud strategy review...

Answer:

This is a PESTLE external factor (specifically Legal) affecting all four dimensions. It is not 'a Partners and Suppliers dimension change' even though cloud providers are involved.

Distractor to avoid:

The cloud hosting angle makes Partners and Suppliers seem correct. But the question is about the forcing factor (legislation), not the affected dimension. Legislation = PESTLE = Legal.

If the question asks about:

When the scenario describes failing to define team ownership, training plans, or support staffing for a new service...

Answer:

Organizations and People dimension was neglected. Anything about WHO owns something, how people are trained, or how teams are structured = O&P.

Distractor to avoid:

Information and Technology is tempting if the scenario involves a technology rollout. But the gap described is about people/ownership/training, not the technology itself.

If the question asks about:

When the scenario describes mapping workflow steps and removing unnecessary approval handoffs...

Answer:

Value Streams and Processes dimension. Workflow analysis and handoff optimization = VS&P.

Distractor to avoid:

This might seem like an 'Improve' service value chain activity. But the question asks about which DIMENSION this work targets, not which SVC activity is happening.

Last-Minute Facts

1Four dimensions: Organizations and People, Information and Technology, Partners and Suppliers, Value Streams and Processes.

2PESTLE = external environment. NOT a fifth dimension.

3All four dimensions must be balanced. Neglecting any one = service failures.

4Dimensions ≠ SVS components. These are separate ITIL frameworks.

Domain 410% of exam

Product and Service Lifecycle

Must-Know Facts

Eight lifecycle stages, grouped in pairs: Discover+Design, Acquire+Build, Transition+Operate, Deliver+Support.
Discover = identify and prioritize needs and opportunities aligned with organizational strategy.
Design = create the service solution, architecture, and specifications (human-centered design applies here).
Acquire = obtain resources, third-party software, cloud infrastructure, and components BEFORE development begins.
Build = develop, configure, test, and validate the service or product.
Transition = move from development to live: data migration, user training, cutover coordination, go-live readiness.
Operate = keep the live service running day-to-day: monitoring performance, managing the live environment.
Deliver = the stage where users actively consume the service and value is realized.
Support = restore normal operations and resolve issues: incidents, service requests, problem escalations.
This 8-stage lifecycle is ITIL 5 specific. ITIL v3 used: Strategy, Design, Transition, Operation, Continual Service Improvement (5 stages). ITIL 4 used the Service Value Chain (6 activities: Plan, Improve, Engage, Design and Transition, Obtain/Build, Deliver and Support) — not a lifecycle model. The 8-stage lifecycle replaces the v4 service value chain as the primary product/service delivery model.

Common Traps

TrapUsing ITIL v3 lifecycle stage names (Strategy, Design, Transition, Operation, CSI) for ITIL 5 questions.

RealityITIL 5 uses an entirely different 8-stage lifecycle. The two overlap in some names (Design, Transition) but have different scopes and four entirely new stages (Discover, Acquire, Deliver, Support). Never use v3 stage names in v5 questions.

TrapConfusing the ITIL 4 Service Value Chain activities (Plan, Improve, Engage, Design and Transition, Obtain/Build, Deliver and Support) with the ITIL 5 product and service lifecycle stages.

RealityITIL 4 used a 6-activity Service Value Chain as the core operating model. ITIL 5 introduces the 8-stage Product and Service Lifecycle (Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support) as the primary delivery framework. These are different structures. Candidates with ITIL 4 experience must not map v4 SVC activities to ITIL 5 lifecycle stage questions.

TrapUsing non-ITIL terms like 'Develop,' 'Deploy,' 'Optimize,' or 'Retire' as lifecycle stage names.

RealityThese are not ITIL 5 lifecycle stage names. The correct terms are: Acquire (not 'procure' or 'source'), Build (not 'develop'), Transition (not 'deploy'), Operate (not 'run' or 'maintain'). Examiners use non-ITIL words as distractors.

TrapConfusing Operate and Support — both deal with a live service.

RealityOperate = keeping the service running normally day-to-day (proactive: monitoring, performance management). Support = restoring service when things go WRONG (reactive: incidents, outages, user issues). Operate is steady-state; Support is the exception-handling stage.

TrapConfusing Acquire and Build — both precede going live.

RealityAcquire = OBTAINING things from outside (purchasing licenses, provisioning cloud infrastructure, sourcing components). Build = CREATING things internally (coding, configuring, testing). If money is spent to get something external, it is Acquire. If internal teams are doing technical work, it is Build.

Confusing Pairs

AcquireBuild

Acquire = get what you need from outside the team (purchase, license, provision cloud infra). Build = create, configure, code, and test internally. Example: buying a monitoring tool = Acquire. Writing the application code = Build.

TransitionDeliver

Transition = the cutover process: moving from development to live, training users, migrating data, readiness checks. Deliver = after go-live, when users are actively using the service and receiving value. Transition ends when the service is live; Deliver is the ongoing provision of that live service.

OperateSupport

Operate = day-to-day management of a running service (monitoring, performance analysis, capacity management). Support = restoring service when something breaks (incident handling, problem escalation, service request fulfillment). Normal operations = Operate. Something went wrong = Support.

Scenario Tips

If the question asks about:

When a team is 'coordinating the cutover from old system to new one, including data migration, user training, and go-live readiness'...

Answer:

Transition. The defining indicators: cutover, migration, training before go-live, readiness verification.

Distractor to avoid:

Build is tempting because testing is also happening. But Build ends with completed/validated development. The described activities are all about moving an already-built system into production.

If the question asks about:

When a team is 'purchasing a third-party monitoring tool and allocating cloud infrastructure before development begins'...

Answer:

Acquire. Purchasing external tools and provisioning infrastructure = Acquire.

Distractor to avoid:

Design is tempting because this happens early in the lifecycle. But Design is about creating specifications and architecture. Acquiring resources is procurement, not design.

If the question asks about:

When asked about 'analyzing user feedback and performance metrics for a live portal to identify optimization opportunities'...

Answer:

Operate. Analyzing performance of a LIVE service = Operate.

Distractor to avoid:

Support is tempting because the team is 'reviewing issues.' But Support = something broke and needs fixing. Ongoing performance analysis of a running service = Operate.

Last-Minute Facts

18 lifecycle stages in pairs: Discover+Design, Acquire+Build, Transition+Operate, Deliver+Support.

2Acquire = buy/provision external things. Build = develop/test internally.

3Transition = go-live readiness and cutover. Operate = daily running of live service. Support = fix what breaks.

4ITIL v5 lifecycle ≠ ITIL v3 lifecycle (5 stages) ≠ ITIL v4 SVC (6 activities). Only ITIL 5 has the 8-stage product/service lifecycle.

5Non-ITIL terms (Deploy, Develop, Optimize, Retire) are trap answer options.

Domain 55% of exam

Value Stream Identification, Mapping, and Management

Must-Know Facts

A value stream = a series of steps an organization undertakes to create and deliver a product or service to a consumer.
Value streams are built from combinations of service value chain activities — they represent specific paths through the SVS for a given scenario.
Value stream MAPPING = a one-time diagnostic visual technique for documenting ALL steps, information flows, and handoffs in a value stream (both value-adding and non-value-adding).
Value stream MANAGEMENT = the ongoing daily practice of ensuring continuous workflow optimization. Distinct from the one-time mapping exercise.
Flow efficiency = value-adding time ÷ total lead time. Low flow efficiency means most time is spent waiting in queues, not doing actual work.
Waste in value streams = delays, unnecessary handoffs, rework, and activities that do not add value for the customer.

Common Traps

TrapTreating value stream mapping and value stream management as synonyms.

RealityMapping is a one-time diagnostic snapshot — you do it to see the current state. Management is the ongoing daily practice of optimizing workflow. Mapping diagnoses; management sustains and improves.

TrapThinking value stream mapping only documents value-adding steps.

RealityThe whole point of value stream mapping is to document EVERYTHING — value-adding AND non-value-adding steps. You cannot eliminate waste you have not yet seen. Mapping reveals both to enable targeted improvement.

TrapConfusing a value stream with the service value chain.

RealityService value chain = the six universal building-block activities (Plan, Improve, Engage, etc.) — the toolkit. A value stream = a specific sequence of those activities assembled for a particular service scenario (the use of the toolkit). The chain provides components; a value stream is a specific instance.

Confusing Pairs

Value Stream MappingValue Stream Management

Mapping = one-time visual diagnostic to document current state steps, flows, and handoffs. Management = ongoing daily practice of optimizing and improving workflow continuously. Mapping answers 'what is happening now?' Management answers 'are we keeping it optimized?'

Value StreamService Value Chain

Service Value Chain = the six activities that are the building blocks of all value creation (Plan, Improve, Engage, Design and Transition, Obtain/Build, Deliver and Support). Value Stream = a specific sequence of those activities assembled for one particular service scenario. The chain is the vocabulary; a value stream is a specific sentence written in that vocabulary.

Scenario Tips

If the question asks about:

When a team documents ALL steps involved in new employee onboarding, from HR submission through IT account creation and device provisioning...

Answer:

Value stream MAPPING — documenting all steps and handoffs for a specific scenario is the definition of value stream mapping.

Distractor to avoid:

Service value chain design is tempting because you are looking at activities. But the service value chain is the abstract set of 6 activities. Documenting a specific end-to-end flow for onboarding = mapping a value stream.

If the question asks about:

When a team finds a request takes 5 days total but only 4 hours involves actual value-adding work...

Answer:

This ratio (4 hours ÷ 5 days) represents FLOW EFFICIENCY — a key value stream performance metric revealing waste in queues and handoffs.

Distractor to avoid:

SLA compliance might seem relevant because it involves time metrics. But SLAs measure agreement targets. Flow efficiency specifically measures the ratio of value-adding time to total lead time.

Last-Minute Facts

1Value stream mapping = one-time diagnostic. Value stream management = ongoing optimization.

2Flow efficiency = value-adding time ÷ total lead time. Low = lots of waste.

3Mapping documents BOTH value-adding and non-value-adding steps — that is the point.

4Value stream ≠ service value chain. Chain = 6 building blocks. Value stream = one specific path through those blocks.

Domain 63% of exam

ITIL and Artificial Intelligence

Must-Know Facts

The 6C AI Capability Model: Creation (generates new content/code), Curation (improves data quality), Clarification (helps users understand complex info), Cognition (pattern detection and proactive insights), Communication (chatbots and natural language interfaces), Coordination (autonomous orchestration across systems).
Different 6C functions carry different risk levels and require different degrees of human oversight. Coordination is highest-risk (autonomous action); Curation is lower-risk.
AI governance in ITIL = oversight, transparency, accountability for AI outputs, escalation paths, and ethical use policies. Human oversight remains essential.
AI enhances ITIL practices — it does not replace them. AI accelerates monitoring, automates repetitive tasks, and supports decisions, but practices still govern the work.

Common Traps

TrapConfusing Cognition and Communication in the 6C model.

RealityCognition = detecting patterns in data to generate insights and proactive alerts (back-end analysis). Communication = providing natural language interfaces like chatbots for user interaction (front-end interaction). Pattern detection before users notice a problem = Cognition. Chatbot answering user questions = Communication.

TrapConfusing Creation and Curation.

RealityCreation = generating NEW content or code that did not exist before (auto-generating reports, writing configuration scripts). Curation = IMPROVING existing content quality (cleaning CMDB records, deduplicating assets, enriching data). New = Creation. Clean/improve existing = Curation.

TrapAssuming that once AI Coordination is properly configured, no human oversight is needed.

RealityITIL 5 is explicit that AI governance must ensure accountability for AI outputs, transparency in AI-mediated decisions, and escalation paths when AI coordination fails. The higher the autonomy, the more governance required — not less.

Confusing Pairs

CognitionCommunication

Cognition = AI analyzing data to find patterns, anomalies, and insights (proactive, analytical, back-end). Communication = AI providing natural language interfaces for users to interact with (conversational, front-end). An AI detecting performance anomalies = Cognition. A chatbot handling service requests = Communication.

CreationCuration

Creation = generating new content, code, or documentation from scratch. Curation = improving the quality, accuracy, or completeness of existing data and content. Writing new incident resolution scripts = Creation. Cleaning duplicate CMDB records = Curation.

ClarificationCommunication

Clarification = AI helping users understand complex information (explaining technical errors in plain language, summarizing long incident histories). Communication = AI providing conversational interfaces (chatbots, virtual assistants). Clarification is about comprehension aid; Communication is about interaction channel.

Scenario Tips

If the question asks about:

When the scenario describes AI 'detecting unusual patterns in service performance data and alerting the operations team before users are impacted'...

Answer:

Cognition — pattern detection and proactive insights from data is the defining characteristic of the Cognition 6C function.

Distractor to avoid:

Coordination is tempting because AI is 'doing something autonomously.' But Coordination specifically involves autonomous action across systems (routing, executing scripts). Detecting and alerting = Cognition.

If the question asks about:

When the scenario describes a service desk AI chatbot 'answering common user questions in natural language, reducing ticket volume'...

Answer:

Communication — natural language user interaction interfaces are the Communication 6C function.

Distractor to avoid:

Clarification sounds right because the chatbot is 'explaining things to users.' But Clarification is specifically about helping users understand complex information (e.g., technical errors). A chatbot that handles service requests = Communication.

Last-Minute Facts

16C model: Creation, Curation, Clarification, Cognition, Communication, Coordination.

2Cognition = detect patterns/insights. Communication = chatbots/natural language interfaces.

3Creation = generate new content. Curation = improve existing data quality.

4AI governance requires human oversight — higher autonomy = more governance needed.

5AI enhances ITIL practices, does not replace them.

Domain 72% of exam

ITIL and Other Frameworks

Must-Know Facts

ITIL + DevOps: complementary, not competing. DevOps = speed, collaboration, automation. ITIL = governance and service management structure. ITIL 5 was designed with DevOps compatibility in mind.
ITIL + Agile: compatible. The guiding principle 'Progress Iteratively with Feedback' directly aligns with Agile values of short iterations and feedback loops.
ITIL + PRINCE2: PRINCE2 manages the PROJECT that creates or changes a service. ITIL manages the SERVICE once it is live. They cover different lifecycle stages and are complementary, not alternatives.
No single framework covers everything — organizations should select complementary frameworks based on context.

Common Traps

TrapThinking ITIL and DevOps are in conflict because ITIL adds process overhead that slows down DevOps.

RealityITIL 5 was deliberately designed to be compatible with DevOps. The service value chain's flexibility enables DevOps pipelines. ITIL provides governance WITHOUT dictating rigid sequential processes. They complement each other.

TrapTreating PRINCE2 and ITIL as competing frameworks that do the same thing.

RealityThey operate in different phases. PRINCE2 manages a defined project with a start and end point (delivering the new service). ITIL manages the ongoing service after the project ends. The handoff point is when a project transitions a service into live operation.

Confusing Pairs

PRINCE2ITIL

PRINCE2 = project management (time-bounded, defined deliverable, clear end). ITIL = service management (ongoing, no end, continuous operation and improvement). A new ERP implementation = PRINCE2. Managing the ERP service for the next 10 years = ITIL.

DevOpsITIL

DevOps = cultural and technical practices for rapid, collaborative software delivery (CI/CD, automation, shared responsibility). ITIL = governance framework for managing services across their lifecycle. DevOps handles how software is built and deployed; ITIL handles how services are managed and governed. Complementary, not competing.

Scenario Tips

If the question asks about:

When the scenario describes a Scrum team deploying every two weeks while operations uses ITIL practices for incident management...

Answer:

This is a valid, complementary approach. Agile/Scrum for delivery + ITIL for service management = how modern organizations operate.

Distractor to avoid:

'Using both creates conflict' is the tempting wrong answer. ITIL 5 explicitly supports this combination.

If the question asks about:

When asked which ITIL guiding principle MOST directly aligns with Agile values...

Answer:

'Progress Iteratively with Feedback' — the iterative delivery and feedback loop is the direct Agile alignment.

Distractor to avoid:

'Focus on Value' also aligns with Agile's customer focus but is a broader principle. The MOST direct alignment is the iterative principle, which mirrors Agile's sprint structure.

Last-Minute Facts

1ITIL + DevOps = complementary. ITIL provides governance; DevOps provides speed. No conflict.

2ITIL + Agile = compatible. 'Progress Iteratively with Feedback' = the ITIL principle that most aligns with Agile.

3ITIL + PRINCE2 = different phases. PRINCE2 = project delivery. ITIL = service management after go-live.

4No single framework covers everything — use complementary combinations.

Feeling confident?

Put your knowledge to the test with a timed ITILFND V5 mock exam.