Key Concepts of ITIL 4 practice questions

Organizations and people

Why it fails: Organizations and people is one of the four dimensions of service management, not a component of the Service Value System. It is tempting because the four dimensions are frequently examined alongside the SVS, but the SVS components are guiding principles, governance, service value chain, practices and continual improvement.

Service request management

Why it fails: Service request management is a practice within the Service Value Chain's activities, not a component of the Service Value System itself. It is tempting because practices are central to ITIL 4, but the SVS components are guiding principles, governance, service value chain, practices and continual improvement — not individual practices.

ITIL maturity model

Why it fails: The ITIL maturity model assesses an organisation’s capability level for adopting ITIL practices, but the Service Value System (SVS) is a fixed set of components—guiding principles, governance, service value chain, practices, and continual improvement—not a maturity scale. It is tempting because maturity models are often used to benchmark SVS implementation, yet the SVS itself defines the structural elements, not a progression metric.

Output

Why it fails: An output is a tangible or intangible deliverable produced by an activity, such as a new software release or a processed report. While outputs are necessary components of service provision, ITIL 4 distinguishes them from outcomes, which are the actual results or benefits achieved by stakeholders. Outputs themselves do not inherently define value; rather, it is the outcomes they enable that constitute value from the consumer's perspective.

Continue with temporary fixes during peak hours and document workarounds to speed up recovery.

Why it fails: Continuing with temporary fixes is a reactive Incident Management approach that fails to address the underlying problem, leading to recurring disruptions and increased operational overhead. This strategy does not deliver long-term value to the business or its customers, directly violating the 'Focus on value' guiding principle. It perpetuates a cycle of firefighting instead of achieving service stability and efficiency.

Implement additional monitoring and alerting to detect outages faster, then assign a dedicated team to manually restart services.

Why it fails: While improved monitoring enhances incident detection, assigning a dedicated team for manual restarts is an unsustainable and inefficient operational model. This approach merely improves reactivity without resolving the fundamental issue causing the outages, failing to 'Optimize and automate' or 'Focus on value' by not seeking a permanent, automated solution. It increases human error potential and operational costs without delivering lasting stability.

Immediately replace the payment processing system with a more robust cloud-based solution to prevent future outages.

Why it fails: Immediately replacing a critical system without a thorough root cause analysis is a premature, high-risk, and potentially wasteful decision. This action violates the 'Start where you are' guiding principle by disregarding existing infrastructure knowledge and the 'Progress iteratively with feedback' principle by attempting a large-scale, unvalidated change. Such a significant investment without understanding the true problem could lead to misdirected efforts and unnecessary expenditure.

The service desk is a service that handles incidents.

Why it fails: In ITIL 4, a service desk is defined as a function, which is a team or specialized group of people and other resources within an organization that performs specific activities. While the service desk *contributes* to the delivery of various services by handling incidents and service requests, it is not a service in its own right. A service is 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.

The technical team is a service that resolves technical issues.

Why it fails: A technical team represents a group of people with specialized skills and knowledge, making it a resource or a function within an organization. While such teams are crucial for resolving technical issues and supporting the delivery of IT services, they are not services themselves. A service, according to ITIL 4, is a co-created value proposition that enables customers to achieve desired outcomes, abstracting away the underlying complexities and risks.

The network device is a service because it provides connectivity.

Why it fails: A network device, such as a router or switch, is a component or resource that provides a specific utility, namely connectivity. However, in ITIL 4, a service is a much broader concept, defined as a means of enabling value co-creation by facilitating outcomes for customers. A single network device is merely an underlying component that contributes to the delivery of a service (e.g., an internet access service), rather than being a service itself.

Value: The perceived benefits, usefulness, and importance of something.

Why it fails: Value, in ITIL 4, is inherently subjective and determined by the perception of stakeholders. It encompasses the benefits, usefulness, and overall importance that something holds for an individual or organization. This perception can evolve over time and is not solely tied to monetary gain, but rather to how well a service or product helps achieve strategic or operational objectives.

Utility: The functionality offered by a product or service to meet a particular need.

Why it fails: Utility refers to the specific functionality or capabilities that a product or service offers to meet a customer's particular need. It answers the question 'what the service does' and directly supports the customer's performance or task, making it 'fit for purpose.' For example, a car's utility is its ability to transport people, while a cloud storage service's utility is its capacity to store data.

Warranty: Assurance that a product or service will meet agreed requirements.

Why it fails: Warranty provides assurance that a service or product will consistently meet its agreed-upon requirements and specifications. This includes aspects such as availability, capacity, security, and continuity, ensuring the service is 'fit for use.' By addressing 'how well' the service performs under specified conditions, warranty builds confidence and reduces uncertainty for the consumer.

Service: Assurance that a product or service will meet agreed requirements.

Why it fails: This statement incorrectly defines 'Service' by describing 'Warranty.' A service, according to ITIL 4, is a means of enabling value co-creation by facilitating desired customer outcomes without the customer managing specific costs and risks. The provided definition, focusing on meeting agreed requirements and providing assurance, specifically pertains to the performance and reliability aspects, which is the core concept of warranty.

Value: The functionality offered by a product or service to meet a particular need.

Why it fails: This statement incorrectly defines 'Value' by describing 'Utility.' Value is the perceived benefits, usefulness, and importance of something from a stakeholder's perspective, which is inherently subjective and can vary. The given definition, emphasizing the functionality offered to meet a particular need, precisely aligns with the ITIL 4 definition of utility, which describes what a service does functionally.

The customer

Why it fails: In ITIL 4, the customer is the recipient of a service, defining their requirements and expectations for value co-creation. While they are crucial in specifying what a new service should deliver and may approve the final service acceptance, their role does not typically extend to authorizing the financial budget for its development or implementation. Budgetary approval is a distinct responsibility, usually held by those with financial oversight.

The service desk manager

Why it fails: The service desk manager is primarily responsible for the operational delivery of support, managing incidents, service requests, and communication with users. Their focus is on maintaining service availability and user satisfaction within established parameters and budgets. Authorizing significant new project budgets for service development falls outside their operational scope, which is centered on day-to-day service delivery and support.

The user

Why it fails: Users are the individuals who consume or utilize the services provided, interacting with them to achieve their own tasks or objectives. Their primary role involves service consumption, providing feedback on service utility and warranty, and adhering to service usage guidelines. Users do not hold the authority or responsibility for allocating or authorizing the financial budgets required for service development or operational costs.

Supplier

Why it fails: Suppliers are part of the service provider's ecosystem, not consumers.

Project manager

Why it fails: A project manager may be part of the provider or consumer, but is not always a consumer.

Service desk analyst

Why it fails: The service desk analyst is part of the provider organisation.

A warranty improvement

Why it fails: Warranty relates to availability, capacity, etc., not directly to time savings.

A risk reduction

Why it fails: Risk reduction might be one aspect, but the overall concept is value co-creation.

An output of the service

Why it fails: Outputs are tangible deliverables like reports; the benefit described is an outcome.

The risk of losing internet connectivity

Why it fails: When a service provider offers an online banking platform, the consumer typically remains responsible for establishing and maintaining their own internet access. The service provider's scope of control usually begins once the connection reaches their infrastructure, not at the consumer's endpoint. Therefore, the risk of the consumer losing internet connectivity, preventing access to the service, is generally retained by the consumer and is not transferred to the service provider. This is a prerequisite for consuming the service, not an inherent part of the service delivery itself.

The risk of employee turnover

Why it fails: Employee turnover within the consumer's organization, such as a bank's internal staff managing their accounts on the platform, is an operational risk specific to the consumer's human resources and organizational stability. This internal risk is entirely outside the service provider's control and scope of service delivery for the online banking platform. Consequently, the service provider does not assume or manage the consumer's internal staffing risks, meaning this risk remains firmly with the consumer organization.

The risk of regulatory fines

Why it fails: While a service provider must adhere to relevant regulations in their operations, the ultimate legal and financial accountability for regulatory compliance, including the risk of incurring fines, often remains with the consumer organization utilizing the online banking platform. The consumer, as the regulated entity, is responsible for ensuring their overall business practices, including how they use the service, meet all applicable laws. Therefore, the direct financial risk of regulatory fines is typically retained by the consumer, even if the provider supports compliance through their service.

The vendor that supplies hardware

Why it fails: This vendor acts as a supplier, providing goods or services to the organization that is itself a service provider. While they contribute to the overall service value chain, they are external to the direct consumption of the *new service* being discussed. They are a partner in the service provider's ecosystem, not the end-user or customer of the service being delivered by the organization.

The IT architect who designs the service

Why it fails: An IT architect is an internal role within the service provider organization, responsible for designing and structuring services to meet business requirements. Their activities are part of the "design and transition" value chain activity, focusing on creating the service offering itself. They are a producer of the service, not a consumer or customer who authorizes its use or purchase.

The IT service desk team

Why it fails: The IT service desk team is a crucial component of the service provider's "deliver and support" value chain activity, acting as the single point of contact for users. They facilitate service consumption by providing support and incident resolution, but they are an operational function *within* the service provider. They do not represent the role of a customer or user who consumes or authorizes the purchase of a service.

A consumer paying a provider for a service

Why it fails: While payment is often a component of a commercial service agreement, it represents a transactional exchange rather than the ongoing service relationship itself. The act of paying for a service is a financial transaction that enables or supports the relationship, but it does not encompass the continuous interaction, co-creation of value, or the provision and consumption activities that define a service relationship in ITIL.

A provider marketing its services to potential consumers

Why it fails: Marketing activities, such as advertising or promoting services to potential consumers, occur *before* a service relationship is formally established. These efforts are designed to attract interest and initiate engagement, aiming to convert prospects into active consumers. However, marketing itself does not constitute the ongoing interaction and value co-creation that characterize a service relationship.

A provider auditing its own internal processes

Why it fails: A provider auditing its own internal processes is an internal governance and quality assurance activity, focused on improving operational efficiency and compliance. While crucial for a provider's effectiveness, this activity does not involve a direct interaction with a consumer for value co-creation, nor does it represent the provision or consumption of a service in the context of a service relationship. It is an internal control, not a relationship.

Manager

Why it fails: "Manager" is not a specific ITIL 4 term for a party in a service relationship, as it describes a general organizational role rather than a defined stakeholder within the service value system. While managers certainly exist within organizations and may fulfill customer, user, or sponsor roles, the term itself does not denote a distinct type of service relationship party according to ITIL 4 definitions. The framework focuses on specific roles related to service consumption and provision.

Supplier

Why it fails: A Supplier, in ITIL 4, is a type of service provider that provides goods or services to an organization. They are typically external entities, but can also be internal, and are fundamentally part of the service provider side of a service relationship, not a consumer party. The question specifically asks for terms related to the parties consuming services, making "Supplier" an incorrect choice as it represents a provider role.

Regulator

Why it fails: A regulator is an external entity that sets rules and compliance standards for organizations, influencing the environment in which services are delivered. While their mandates must be adhered to by both service providers and consumers, they do not directly participate in the value co-creation activities or define specific requirements within a particular service relationship. Their role is supervisory, not a direct stakeholder in the service consumption and provision.

Investor

Why it fails: An investor provides capital to an organization, expecting financial returns, and is primarily concerned with the overall financial health and strategic direction of the enterprise. While their interests indirectly influence an organization's capacity to invest in and deliver services, they are not direct participants in the operational aspects or value co-creation of a specific service relationship. ITIL 4 defines service relationship stakeholders as those directly interacting in the service value chain, which does not typically include investors.

Supplier

Why it fails: A supplier is an organization or individual that provides goods or services to the service provider, enabling the provider to deliver its own services to the consumer. While crucial for the service provider's operations and the overall service value chain, the supplier is generally external to the direct service relationship between the service provider and the service consumer (customer/user). They are not direct stakeholders in the consumer's experience or the value co-creation with the customer.

Products

Why it fails: Products are not stakeholders; they are deliverables.

IT infrastructure

Why it fails: Infrastructure is not a stakeholder.

Outputs

Why it fails: Outputs are not stakeholders.

Output

Why it fails: An output, in ITIL terms, is a tangible or intangible deliverable resulting from an activity, such as a stored file, a processed transaction, or a usage report. The removal of risk, however, is not a direct deliverable produced by the service but rather a beneficial outcome or consequence of consuming the cloud storage service. It represents a shift in responsibility and a contribution to value, rather than a produced item.

Warranty

Why it fails: Warranty, in ITIL, refers to the assurance that a product or service will meet agreed requirements and specifications, ensuring 'fitness for use' and providing confidence in its performance. While a cloud storage service's warranty might cover data durability, uptime, or recovery time objectives, it describes the quality and reliability of the service's performance, not the fundamental act of transferring the underlying operational risks of infrastructure management. The warranty provides confidence in the service's ability to perform, but it is distinct from the strategic shift of risk ownership.

Utility

Why it fails: Utility describes the functionality offered by a product or service to meet a particular need, often referred to as 'fitness for purpose' or 'what the service does.' For cloud storage, the utility is the core capability to store, retrieve, and manage data efficiently and reliably. While risk removal is a valuable outcome of using the service, it is a benefit derived from the service's utility and warranty, rather than the utility itself, which focuses purely on the functional capabilities that enable the consumer to perform their tasks.

Sponsor

Why it fails: A Sponsor champions an initiative and secures high-level resources and authorization for a service or project. While they enable the service to proceed, their primary responsibility is strategic oversight and funding provision, not the detailed articulation of functional and non-functional service requirements. Requirements definition is a more granular activity typically performed by those representing the demand side.

Service provider

Why it fails: The Service Provider is the entity responsible for delivering and managing services to meet agreed-upon requirements. Their role involves designing, building, and operating services based on specifications provided by the customer, rather than originating or defining the initial business requirements. They translate demand into service offerings, ensuring operational delivery aligns with defined needs.

User

Why it fails: A User is an individual who consumes a service to perform their work or achieve a personal objective. While users provide crucial input regarding their experiences and needs, which informs requirement gathering, they do not hold the formal accountability for defining the comprehensive service requirements or authorizing the associated budget. Their perspective is typically focused on service consumption and immediate utility.

Raise a change request to modify the CRM system

Why it fails: Change requests authorise modifications to the CRM system, but the analyst has not yet diagnosed the fault, so no change is justified. Logging and resolving the incident comes first. Change enablement is tempting because fixes often require changes, and would be correct once a known error demands an authorised alteration.

Start a problem investigation to find the root cause

Why it fails: Problem investigation addresses underlying causes of recurring incidents, not the immediate restoration of service. The analyst must first log and resolve the incident to restore CRM access. Problem management is tempting because root-cause analysis prevents recurrence, and would be correct once multiple related incidents point to an unknown cause.

Submit a service request to grant access to the system

Why it fails: A service request covers standard, pre-approved user asks such as access provisioning, yet the stem reports an outage affecting users who presumably already had access. The analyst should first log and resolve the incident. Service requests are tempting because access failures often stem from permissions, and would be correct for a new starter needing CRM rights.

Incident record

Why it fails: An incident is defined as an unplanned interruption to a service or a reduction in the quality of a service. A request for a new laptop, even if pre-approved, does not represent an interruption or degradation of an existing service that needs to be restored. Instead, it is a planned provision of a new or modified service component, making an incident record inappropriate for tracking this type of user request.

Change request

Why it fails: A change is the addition, modification, or removal of anything that could have a direct or indirect effect on services. While providing a new laptop is technically a change (specifically, a standard change), ITIL 4 emphasizes that standard changes, particularly those that are low-risk, pre-authorized, and frequently performed, should be fulfilled via the service request process for efficiency. Directly logging this as a change request would introduce unnecessary overhead for a routine user request.

Problem record

Why it fails: A problem is a cause, or potential cause, of one or more incidents. It represents an underlying issue that needs investigation and resolution to prevent future incidents or reduce their impact. A user requesting a new laptop is a proactive demand for a resource, not an underlying cause of service disruption or a recurring error, thus it does not warrant the creation of a problem record.

A configuration item

Why it fails: A configuration item (CI) is a component that needs to be managed to deliver an IT service, such as a server, application, or document. While CIs are fundamental building blocks and assets that underpin services, they are not the service itself. The service represents the integrated utility and warranty provided to the customer, which is enabled by a collection of managed CIs.

The process of managing incidents

Why it fails: The process of managing incidents refers to the ITIL practice of restoring normal service operation as quickly as possible and minimizing the adverse impact on business operations. This is a specific operational activity or practice within service management, designed to support the availability and performance of services. It is not the definition of a service itself, which is the overall offering that enables customer outcomes.

A set of IT hardware and software

Why it fails: A set of IT hardware and software primarily describes a product or the tangible components that form the basis of a service offering. While these physical and logical assets are essential for building and delivering services, the service itself transcends mere components. A service encompasses the utility and warranty provided to the customer, enabling them to achieve specific outcomes without needing to manage the underlying infrastructure directly.

Risk of poor internal processes at the consumer's organisation

Why it fails: This risk pertains to the consumer's own operational effectiveness and internal controls, which are outside the scope of a typical service provider's direct responsibility or influence. While a service provider delivers a service, they do not assume accountability for the consumer's ability to effectively integrate, utilize, or manage their own internal processes around that service. Therefore, this risk remains with the consumer, who must manage their internal process quality independently.

Cost of electricity for running the consumer's own servers

Why it fails: The cost of electricity for running the consumer's own servers represents a direct, predictable operational expenditure, not an uncertain event with potential negative impact. A risk, by definition, is an effect of uncertainty on objectives, whereas this is a known, recurring expense associated with maintaining on-premise infrastructure. This cost is borne directly by the consumer and is not a risk that can be transferred to a service provider.

Risk of employee absenteeism in the consumer's organisation

Why it fails: The risk of employee absenteeism is an internal human resources management concern specific to the consumer's workforce. Service providers are responsible for managing the availability and performance of their own staff involved in service delivery, but they do not assume responsibility for the consumer's internal staffing challenges. This operational risk remains firmly with the consumer, who must implement their own HR policies and contingency plans.