ITIL 4 Foundation — Exam Prep
*60 minutes standard duration; eligible candidates taking the exam in a language that is not their native or working language may receive 25% extra time. There is no negative marking, so never leave a question blank.
How to approach this exam
ITIL 4 Foundation is primarily a recall-and-understanding exam, not a test of whether you can run production operations. Your experience is a real advantage, but it can also create traps when your team's everyday wording differs from ITIL's definitions. For this exam, prefer the ITIL meaning over local process habits.
Exam blueprint — where the 40 points come from STUDY BY WEIGHT
The official ITIL 4 Foundation exam specification assigns the 40 questions across seven learning outcomes. This is the most useful way to decide what deserves your study time.
12.5%
15%
5%
2.5%
5%
17.5%
42.5% — biggest block on the exam
24 of 40 questions come from practices (the 15 purpose/key-term block plus the 7-practice detail block). If you are time-constrained, practice knowledge should get the largest share of your review.
The 7 Guiding Principles HIGH YIELD Recommendations that guide an organization in all circumstances, regardless of goals, strategy, or structure.
- Focus on valueEverything the organization does needs to map, directly or indirectly, to value for stakeholders. Always ask "who cares about this, and why?"
- Start where you areDon't build from scratch by default. Assess what already exists (people, tools, process) and reuse what's usable — measure before you redesign.
- Progress iteratively with feedbackDon't try to do everything at once. Break initiatives into small, manageable pieces, get feedback at each step, and adjust.
- Collaborate and promote visibilityWork across boundaries — teams, departments, vendors — and make work, data, and decisions visible so trust and buy-in improve.
- Think and work holisticallyNo practice, service, or process exists in isolation. Use the Four Dimensions to make sure you haven't optimized one part while breaking another.
- Keep it simple and practicalUse the minimum number of steps to accomplish an objective. If a process step doesn't produce value, cut it.
- Optimize and automateMaximize the value of human effort. Optimize before you automate — automating a broken process just breaks things faster.
The Four Dimensions of Service Management HIGH YIELD Perspectives that must all be considered to ensure a holistic approach — this is what "think holistically" refers to.
Organizations & People
Roles, responsibilities, org structure, culture, staffing, and competencies needed to support the service.
Information & Technology
The information and knowledge used to deliver services, plus the technologies that support them — includes CMDBs, monitoring tools, AI, etc.
Partners & Suppliers
Relationships with other organizations involved in design, deployment, delivery, support, or continual improvement of services.
Value Streams & Processes
How the parts of the organization work together in an integrated, coordinated way to enable value creation through products and services.
All four dimensions are surrounded by external factors the org doesn't control: Political, Economic, Social, Technological, Legal, Environmental. If a question describes GDPR, a new regulation, or a market shift, it's asking about PESTLE, not one of the four core dimensions.
Service Value System (SVS) Describes how all the components and activities of the organization work together to facilitate value creation.
Think of the SVS as the big picture container — everything in ITIL 4 lives inside it. It takes in opportunity/demand as input and produces value as output.
The 7 recommendations above.
The means by which the org is directed and controlled (evaluate, direct, monitor).
The 6-activity operating model — see next section.
34 sets of organizational resources for performing work (see full list below).
A recurring activity performed at all levels to ensure ongoing alignment with business needs.
Service Value Chain & Value Streams This trio — SVS, SVC, Value Stream — is the single most-confused topic on the exam.
The Service Value Chain (SVC) is a set of six activities an organization can combine in different ways, forming multiple value streams.
Plan
Ensure shared understanding of vision, status, and improvement direction across the org.
Improve
Ensure continual improvement of products, services, and practices across every value chain activity.
Engage
Provide understanding of stakeholder needs, transparency, and good relationships with all stakeholders.
Design & Transition
Ensure products/services meet stakeholder expectations for quality, cost, and time-to-market.
Obtain/Build
Ensure service components are available when and where needed, meeting agreed specifications.
Deliver & Support
Ensure services are delivered and supported per agreed specs and stakeholder expectations.
| Term | What it actually is |
|---|---|
| Service Value System | The whole ecosystem: principles + governance + value chain + practices + continual improvement. The "everything" container. |
| Service Value Chain | The generic 6-activity operating model inside the SVS. It's a template — always the same 6 activities, for every organization. |
| Value Stream | A specific combination of value chain activities and practices, sequenced to respond to a particular demand or scenario (e.g. "resolve a user-reported incident," "deliver a new feature"). Value streams are unique per organization/scenario — the value chain is not. |
Service, value, and value co-creation Foundational vocabulary — expect at least 2-3 direct-definition questions on these.
- Service
- A means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.
- Value
- The perceived benefits, usefulness, and importance of something. Value is subjective — defined by the customer, not the provider.
- Value co-creation
- ITIL 4 rejects the old idea that a provider "delivers" value to a passive customer. Value is co-created — both provider and consumer are active participants.
- Output
- A tangible or intangible deliverable of an activity (e.g. a report, a provisioned server).
- Outcome
- A result for a stakeholder enabled by one or more outputs (e.g. the server being available lets the business run payroll on time). Outcomes are what customers actually pay for — the output is just the mechanism.
- Cost
- The amount of money spent on a specific activity or resource. From the customer's view: costs removed by using the service (utility) and costs imposed by consuming it (e.g. subscription fees).
- Risk
- A possible event that could cause harm, loss, or make it more difficult to achieve objectives.
- Service Offering
- A formal description of one or more services, built from: goods (transferred to the consumer), access to resources (made available on terms), and service actions (performed to meet a need).
Utility vs. Warranty HIGH YIELD Both are required for value co-creation — a service with only one of the two doesn't create value.
| Utility | Warranty | |
|---|---|---|
| Answers | "Does it do what I need?" | "Can I rely on it when I need it?" |
| Definition | The functionality offered by a product/service to meet a particular need — fit for purpose. | Assurance that a product/service will meet agreed requirements — fit for use. |
| Governs | What the service does. | How well the service performs — availability, capacity, security, continuity. |
| Removes / provides | Removes constraints for the consumer. | Reduces the effects of variation (uncertainty). |
| Analogy | A car has brakes and a steering wheel — it can drive you places (utility). | The car starts every morning, is insured, and doesn't break down (warranty). |
Service Desk vs. Service Level Management HIGH YIELD Both are practices — the confusion is that they both touch "how good was this service," but from opposite ends.
| Service Desk | Service Level Management (SLM) | |
|---|---|---|
| Purpose | Capture demand for incident resolution and service requests; acts as the entry point and single point of contact for the IT organization. | Set clear, business-based targets for service performance, so delivery can be properly assessed, monitored, and managed against those targets. |
| Time horizon | Reactive, in-the-moment. "I have a problem right now." | Ongoing/strategic. "Are we consistently meeting our targets over time?" |
| Output | Tickets, resolved incidents, fulfilled requests, a good user experience. | SLAs, service reviews, reports, trend analysis, improvement opportunities. |
| Owns the relationship with | End users, in the moment of need. | Customers/business, over the life of the service agreement. |
Incident vs. Problem vs. Change vs. Known Error HIGH YIELD The classic four-way mix-up. Sequence matters: a problem can produce a known error; a known error can require a change.
An unplanned interruption to a service, or reduction in the quality of a service. Something is broken right now. Goal: restore service ASAP.
A cause, or potential cause, of one or more incidents. You investigate problems to stop incidents from recurring — this is proactive/root-cause work.
A problem that has been analyzed but not resolved. A workaround may exist while a permanent resolution is still pending.
The addition, modification, or removal of anything that could have a direct or indirect effect on services — this is how you actually fix the known error permanently.
Problem Management — the 3 phases, in order HIGH YIELD Just memorize the sequence — that's genuinely almost always all the exam asks.
Problem Identification
Activities that identify and log problems. Sources: incident trend analysis, developer/supplier feedback, proactive risk analysis.
Problem Control
Problem analysis, and documenting workarounds and known errors. This is where a Problem officially becomes a Known Error.
Error Control
Managing known errors — permanent fixes are identified, assessed, and (via change enablement) implemented until the known error is resolved.
Change Enablement — 3 change types
| Type | Description | Authorization |
|---|---|---|
| Standard | Low-risk, pre-authorized, well-understood, and well-documented. Done frequently (e.g. routine password reset, standard laptop provisioning). | Pre-authorized — no per-instance CAB approval needed. |
| Normal | Needs assessment and authorization according to its risk and the organization's change model. The appropriate change authority is defined for the type of change; a CAB is not automatically required for every normal change. | Assessed and authorized using the appropriate change authority. |
| Emergency | Must be implemented as soon as possible (e.g. to resolve a major incident or apply a critical security patch). Still assessed, but on an expedited path. | Expedited assessment and authorization by the appropriate change authority — not "skip approval entirely." |
Continual Improvement Model — 7 steps, know the order
- What is the vision?Business vision, mission, goals, and objectives.
- Where are we now?Perform baseline assessments.
- Where do we want to be?Define measurable targets.
- How do we get there?Define the improvement plan.
- Take actionExecute the improvement plan.
- Did we get there?Evaluate metrics and KPIs.
- How do we keep the momentum going?Reinforce the change and look for the next improvement opportunity.
The 15 practice purposes you actually need 7 QUESTIONS ITIL 4 has 34 practices, but the Foundation syllabus asks you to recall the purpose of these 15. Do not spend equal memorization time on all 34.
Foundation scope: memorize the purpose of the 15 practices below. The seven marked DETAIL are also tested at a deeper understanding level in the next section.
The 7 practices tested in detail 17 QUESTIONS
This block is about 42.5% of the exam. Know the purpose plus the operational ideas below. You do not need to memorize how each practice maps to every value-chain activity.
Continual Improvement
- Know the 7-step continual improvement model in order.
- Improvements can apply to services, products, practices, and any element of service management.
- Use a continual improvement register/backlog to capture and prioritize ideas.
- Improvement is everyone's responsibility, not one team's job.
Change Enablement
- Change = addition, modification, or removal of anything that could affect services.
- Standard = pre-authorized, low-risk, well understood.
- Normal = assessed and authorized according to risk.
- Emergency = expedited, but still assessed/authorized.
- Each change type/model should have an appropriate change authority.
Incident Management
- Goal is rapid restoration, not root-cause analysis.
- Prioritization is commonly based on impact and urgency.
- Major incidents use special handling because of business impact.
- Incidents may be resolved by support teams, suppliers, or collaborative swarming.
Problem Management
- Problem = cause or potential cause of incidents.
- Three phases: Problem Identification → Problem Control → Error Control.
- Known error = analyzed problem that remains unresolved.
- Workaround reduces/eliminates impact without fully resolving the issue.
Service Request Management
- Requests are predefined and user-initiated.
- They are a normal part of service delivery, not a service failure.
- Examples: information, access, standard service action, provision of a resource.
- Request models should be simple, standardized, and automated where practical.
Service Desk
- Single point of contact / entry point for users.
- Captures demand for incident resolution and service requests.
- Communication quality, empathy, and user experience matter.
- A service desk is a practice/function, not just a physical desk or ticket queue.
Service Level Management
- Sets business-based targets for service performance.
- SLAs should relate to defined services and meaningful outcomes, not only technical metrics.
- Service reviews and customer feedback help understand actual experience.
- Beware the "watermelon" effect: green technical metrics can hide a poor user experience.
Extra distinctions worth easy points
| Pair | Exam-safe distinction |
|---|---|
| Incident vs. service request | An incident is an unplanned interruption or reduction in service quality. A service request is a predefined, user-initiated request that is part of normal service delivery. |
| Event vs. incident | An event is a change of state significant for managing a service or CI. An event may require action, but it is not automatically an incident. |
| Release vs. deployment | Release management makes services/features available for use. Deployment management moves components into environments. A deployment can occur before a feature is released to users. |
| IT asset vs. configuration item | An IT asset is financially valuable and managed across its lifecycle. A configuration item is a component that needs to be managed to deliver a service; configuration management emphasizes accurate information and relationships. |
| Customer vs. user vs. sponsor | Customer defines requirements and is accountable for outcomes. User uses the service. Sponsor authorizes budget for service consumption. |
| Output vs. outcome | Output = deliverable produced by an activity. Outcome = result for a stakeholder enabled by outputs. |
| Service provision vs. consumption | Provision is what the provider does to supply/manage the service and resources; consumption is what the consumer does to use/manage the service and its resources. |
24-question rapid drill
Original study questions based on the Foundation syllabus — not real PeopleCert exam items. The deck reshuffles whenever you restart.
Exam tips & common traps
Pace yourself. ~1.5 minutes per question on average. Flag and move on if a question is a wall of scenario text — those are often worth the same 1 point as a one-liner.
Answer every question. No penalty for wrong answers, so never leave one blank.
Watch for absolute language. "Always," "never," and "only" in an answer option are frequently (not always) a sign of a distractor.
Distinguish "practice" from "process" from "activity." A practice (e.g. Incident Management) is a broader set of organizational resources; a process is a set of activities. ITIL 4 deliberately moved from "processes" (v3 language) to "practices" (v4 language) — if a question uses "practice," answer in v4 terms.
Service consumer roles — know the difference between customer (defines requirements, is accountable for outcomes), user (uses the service day-to-day), and sponsor (authorizes budget). These can be the same person or different people, and questions love scenarios where they're different.
The exam is written from a generic-organization view, not a sysadmin/engineer view. When two answers both sound operationally "correct" to you, pick the one that matches the textbook definition, not the one that matches how your team actually does it.
Your final review checklist
Tap an item to mark it reviewed. Progress is saved in this browser so a reload will not wipe it.
- Guiding Principles — all 7 names + scenario recognition
- Four Dimensions + external PESTLE factors
- Six Service Value Chain activities + purposes
- SVS vs. SVC vs. Value Stream
- Utility = fit for purpose; Warranty = fit for use
- Customer vs. User vs. Sponsor
- Service offering / provision / consumption / relationship management
- Purpose statements for the 15 syllabus practices
- Seven detailed practices: CI, Change, Incident, Problem, Request, Desk, SLM
- Incident vs. Problem vs. Change vs. Known Error
- Problem phases: Identification → Problem Control → Error Control
- Standard vs. Normal vs. Emergency change
- Release vs. Deployment
- Event vs. Incident; IT Asset vs. CI
- Continual Improvement Model — all 7 steps in order
- Score at least 80% on the rapid drill twice