Free ITIL Foundation V5 Exam Flashcards

v5 broadens the scope so products and services are managed together, reflecting how modern providers bundle a digital product (e.g. a SaaS platform) with the service actions that help consumers use it. Naming both signals that products are first-class value objects, not just containers for services, which is why v5 adds a Product and Service Lifecycle alongside the Value System.

A product is a configuration of an organization's resources designed to offer value to a consumer; ownership can be transferred. A service is the means of enabling value co-creation by facilitating outcomes the consumer wants, without the consumer managing the specific costs and risks. Products can be sold outright; services are consumed through a relationship.

A digital service is delivered through digital channels (an online booking flow, a managed API) where the consumer interacts without owning the underlying platform. A digital product is the asset itself (the app, the platform) that a provider configures and offers. The exam tests whether you can tell a service relationship from a product sale.

Goods are tangible or transferable items a consumer can take ownership of (e.g. a laptop handed over as part of an onboarding offering). Ownership transfers to the consumer, unlike access to resources or service actions where the provider retains the asset. Spotting 'ownership transfers' is the fastest way to identify the goods component.

1) Goods — ownership transfers to the consumer. 2) Access to resources — granted under agreed terms, ownership stays with the provider (e.g. a managed analytics platform). 3) Service actions — performed by the provider on request (e.g. resetting a password). Mix the three to build an offering; confusing 'access' with 'goods' is a common exam trap.

Utility is fitness for purpose — what the service does and which constraints it removes for the consumer. Warranty is fitness for use — the assurance the service will perform as agreed (capacity, availability, security, continuity). A service can have utility without warranty (right thing, unreliably) or warranty without utility (reliable but wrong thing); both are needed for value.

Value is the perceived benefit, usefulness, and importance of something, and it is defined by the consumer, not the provider. v5 stresses co-creation: the provider's offering only creates value when the consumer actively uses it, supplies feedback, and accepts costs and risks. Treating value as something the provider ships one-way is the v3-era mistake v5 explicitly rejects.

A service relationship is the cooperation between a service provider and a service consumer. On the consumer side three roles appear: the customer defines requirements and takes responsibility for outcomes, the user uses the service, and the sponsor authorizes budget. A single person can hold multiple roles, but the roles themselves are distinct.

An output is a tangible or intangible deliverable produced by an activity (a report generated, a ticket closed). An outcome is the result a stakeholder experiences because of one or more outputs (a faster decision, fewer outages). Outputs are easy to count; outcomes are what customers actually value, and confusing them leads teams to optimize for activity over impact.

UX is the experience of the person directly using the service — usability, friction, task completion. CX is the experience of the person who commissions or buys the service, covering the whole relationship including contractual and outcome dimensions. The user and the customer can be different people with different success criteria.

1) Organizations and people — culture, roles, skills, structure. 2) Information and technology — data, knowledge, platforms, tools. 3) Partners and suppliers — external relationships and supply chains. 4) Value streams and processes — how work flows and is organized. All four must be considered together; optimizing one in isolation causes failures in the others.

Covers culture, leadership, workforce skills, role design, team structure, and ways of working. If a GenAI rollout fails here, it is usually because roles and culture were not prepared — not because the technology was wrong. This is where 'people and culture eat strategy for breakfast' shows up in v5.

Covers relationships with external organizations that supply goods, services, or capabilities the provider relies on — including SaaS vendors, outsourced operations, and contractors. When a critical SaaS supplier changes its data retention policy, this dimension is the first thing to review, while still checking the impact on the other three.

Covers the knowledge, data, platforms, and technology used to manage products and services — including the information needed to make decisions and the tools that store, process, and secure it. A common mistake is to equate this dimension with 'IT' in the narrow sense; it explicitly includes information and knowledge management, not just hardware and software.

PESTLE = Political, Economic, Social, Technological, Legal, Environmental. These are external factors that affect all four dimensions from outside the organization. v5 insists on a holistic approach because a change that looks purely technical (e.g. a new AI feature) ripples through people, partners, and processes, and is shaped by PESTLE forces.

Discover, design, acquire, build, transition, operate, deliver, support. v5 splits the old ITIL 4 value chain activities into these eight lifecycle activities, which are iterative and non-linear — you can move back and forth between them rather than marching top to bottom.

Discover explores what is needed, what opportunities exist, and what value could be created for which stakeholders. It is the research and opportunity-shaping activity that precedes design — understanding problems before committing to solutions. Skipping discover is a classic reason products get built that nobody wants.

Design shapes how a product or service should work, feel, integrate, and meet stakeholder needs — including user experience, architecture, and service levels. It is concerned with intent and fit, not with building. Human-centred design techniques belong here.

Acquire obtains external resources or capabilities the organization does not build itself — buying a SaaS platform, contracting a supplier, licensing a dataset. Build constructs or assembles internally. v5 keeps them separate so providers can mix buy and make deliberately rather than defaulting to 'build it ourselves'.

Transition moves a product, service, or change safely into live use — including validation, release planning, and cutover. It is the bridge between build and live consumption. Done badly, transition is where outages, rollback failures, and unhappy users are created.

Operate keeps live products and services reliable, secure, and performing as expected (monitoring, event handling, runbook execution). Deliver provides the service to consumers as agreed (service levels, access provisioning). Support helps users and consumers when they have questions or issues — the three are related but distinct, and v5 lists them as separate lifecycle activities.

1) Focus on value. 2) Start where you are. 3) Progress iteratively with feedback. 4) Collaborate and promote visibility. 5) Think and work holistically. 6) Keep it simple and practical. 7) Optimize and automate. They are universally applicable, enduring, and meant to guide decisions — not be followed once and discarded.

Every decision should be judged by what value it creates for the consumer and the organization, including sustainability and outcomes rather than just output. The trap is internal optimization (e.g. shipping the easiest-to-build feature) that delivers no consumer value. If a choice does not improve outcomes for someone who matters, it fails this principle.

Before building new, assess what already exists and works — current services, data, tools, processes, and capabilities. Reusing and improving current state is usually cheaper and less risky than greenfield rebuilds. The principle protects against the 'not invented here' bias that destroys working assets.

Break work into small, manageable increments, release them, and use the feedback to adjust the next increment. Big-bang delivery delays feedback and magnifies risk; small increments surface problems early. This is why v5 aligns with Agile and Lean ways of working.

Work across boundaries (silos, teams, providers, consumers) and make work, decisions, and status visible to those affected. Hidden work creates hidden failures; visible work creates shared accountability. Acting on this principle means involving the right stakeholders and removing information asymmetry, not just 'being nice'.

No dimension, practice, value chain activity, or team is sufficient on its own. A change to a mobile app must consider user experience, service desk impact, supplier readiness, security, and release workflow together. Holistic thinking is the antidote to optimizing one dimension at the expense of the other three.

Keep it simple and practical means use only the processes, tools, and metrics that actually create value — strip out the rest. Optimize and automate means simplify and improve a process BEFORE automating it; automating a broken process just produces failures faster. The implied order is always optimize first, then automate.

Guiding principles, governance, the value chain, management practices, practice guides, the operating model, metrics, critical success factors, and the continual improvement model. Together they form the system that turns demand into value; the Value Chain is one component, not the whole system.

Governance is the act of directing and controlling an organization by setting objectives, policies, and constraints, and by evaluating outcomes — it sits above and around delivery. Management activities plan, design, deliver, and operate within the boundaries governance sets. Confusing the two leads either to over-managed teams with no direction, or over-directed teams with no execution.

v5 replaces the six ITIL 4 value chain activities with the eight-activity Product and Service Lifecycle. 'Plan' and 'Improve' move up into the Value System as governance and continual-improvement concerns; 'Engage' is distributed across activities such as discover, deliver, and support; 'Design and transition' is split into Design and Transition; 'Obtain/build' is split into Acquire and Build; 'Deliver and support' is split into Operate, Deliver, and Support.

An operating model describes how an organization configures its practices, people, partners, technology, and value streams to deliver its strategy. In v5 the operating model is part of the Value System, not a separate layer — it operationalizes governance and guiding principles into day-to-day work. It is the 'how we actually run' answer to the 'what we aim to do' of strategy.

Value chain activities are not a fixed sequence — they are combined and repeated to deliver value. A single change might touch discover, design, build, transition, operate, deliver, and support several times. The exam tests whether you treat the chain as a linear waterfall or as a flexible, combinable set of activities that can be revisited.

v5 Foundation scope uses two practice groups: general practices and product and service management practices. This replaces the ITIL 4 grouping of general, service management, and technical management practices. Use v5 wording in the exam — calling them 'service management practices' or 'technical management practices' is the older ITIL 4 frame.

A release is a version of a service or product — or a set of changes to a service or product — made available for use at one time. It is the unit of transition into live use. A release bundles one or more changes so consumers experience them together; releasing is not the same as building, deploying, or approving a change.

An event is any detectable occurrence that has significance for the management of a product or service (a login, a threshold crossing, a deployment). An incident is an unplanned interruption or reduction in the quality of a service. Incidents are usually preceded by events, but most events are not incidents — the distinction matters for monitoring and prioritization.

A problem is a cause, or potential cause, of one or more incidents. An error is an identified defect or flaw — once the cause is found, the problem becomes an error. A known error is an error that has been analyzed but not yet resolved, and for which a workaround exists. The progression is problem → error → known error, with workarounds distinguishing the last.

CI/CD is the practice of continuously integrating code and deploying it through automated pipelines, shortening the build-to-release cycle. SRE (Site Reliability Engineering) applies engineering practices to operations — error budgets, service levels as objectives — to keep live services reliable. Observability is the ability to infer a system's internal state from its external outputs (logs, metrics, traces), going beyond monitoring to enable diagnosis.

Practice Guides are ITIL publications that give detailed, practical guidance on individual management practices. A practice success factor (PSF) is a statement of what a practice must do to succeed — a capability condition, not a task. PSFs explain why a practice exists and what 'good' looks like; they are distinct from metrics, which measure whether the PSF is being achieved.

1) What is the vision? 2) Where are we now? 3) Where do we want to be? 4) How do we get there? 5) Take action. 6) Did we get there? 7) How do we keep the momentum going? The model is iterative — step 7 loops back to step 1 as the vision and context evolve.

Without a clear vision, improvement has no direction and no way to judge whether any change is an improvement. The vision aligns the initiative to organizational strategy and to value, so later steps (where are we, where do we want to be) have a reference point. Skipping it produces effort that solves the wrong problem.

'Where are we now?' establishes the honest baseline — current metrics, capability, and pain points. 'Where do we want to be?' defines the target state, expressed as measurable improvements against the vision. The gap between them is what the 'How do we get there?' step must close; without both, you cannot size the work.

A CSF is a statement of what must be true for success — a condition (e.g. 'incidents resolved within agreed time'). A metric is a measurable value used to track progress against a CSF (e.g. 'average resolution time 4.2 hours'). CSFs define the why and what; metrics quantify the how-well. Confusing them produces vanity metrics that look good but do not indicate success.

A core value stream directly delivers value to an external customer (e.g. the stream that onboards a new paying user). An enabling value stream supports the core by providing capabilities the core depends on (e.g. the internal hiring stream that staffs the support team). Cutting an enabling stream to save money usually breaks a core stream later.

Value stream mapping is a one-time exercise that visualizes the steps, handoffs, delays, and waste in a stream so you can see how value flows today. Value stream management is the ongoing governance — designing, monitoring, and continuously improving streams over time. Mapping produces a snapshot; management keeps the stream healthy.

A value stream map typically shows the steps, the actors at each step, the flow of information and materials, the time each step takes, and the wait times between steps. Complexity thinking matters because value streams are systems with feedback loops and emergent behavior — linear fixes often cause new bottlenecks elsewhere. Useful maps surface waits and rework, not just the visible work.

AI is the broad capability of machines to perform tasks that normally require human intelligence. GenAI produces new content (text, code, images) from learned patterns. Agentic AI goes further — it can take actions and make decisions toward a goal with limited human oversight. v5 treats them as distinct maturity points, not synonyms, and the AI Capability Model places them at increasing capability levels.

AI governance ensures AI is used ethically, safely, and in line with organizational policy — covering accountability, transparency, bias, data privacy, and risk. Without it, AI-assisted lifecycle automation (e.g. auto-triaging incidents, GenAI-generated knowledge articles) can create compliance and reputational harm faster than it creates value. Governance is what lets v5 organizations use AI without losing control of it.

ITIL provides the governance, value system, and practices that define what 'good service management' looks like; DevOps provides the culture, automation, and flow practices (CI/CD, small batches, shared ownership) that make delivery fast and reliable. They are not rivals — ITIL gives DevOps a management frame, and DevOps gives ITIL practical ways to flow value. Picking 'one or the other' loses both.

PRINCE2 is a project management method — it controls defined, bounded projects with a start and end. ITIL manages the ongoing products and services those projects create, across their whole lifecycle. PRINCE2 governs project delivery; ITIL governs service and product operation and improvement. Using PRINCE2 to run a service, or ITIL to run a one-off project, misapplies both.