Scenario practice questions

A major incident occurs, and the IT team restores service by implementing a workaround. They then create a problem record to investigate the root cause. Which practice are they following?

Trap 1: Service desk and incident management

The Service Desk functions as the single point of contact for users, logging incidents and facilitating their initial assessment and escalation, but it is not a practice that directly restores service functionality. While Incident Management is indeed crucial for restoring service, the Service Desk's role is primarily communication and coordination, not the technical restoration itself. Therefore, this option incorrectly identifies the Service Desk as a practice responsible for actively restoring service during a major incident.

Trap 2: Problem management and change management

Problem Management is focused on identifying the root causes of incidents to prevent their recurrence, which is a long-term, post-restoration activity, not the immediate action to restore service operation. Change Management, conversely, is the practice of ensuring that changes to services and infrastructure are implemented in a controlled manner, typically for improvements or permanent fixes. Neither practice is primarily responsible for the initial, urgent restoration of service after a major incident has occurred.

Trap 3: Change management and release management

Change Management is the practice of controlling the lifecycle of all changes, enabling beneficial changes to be made with minimal disruption, and is typically a controlled, planned process, not an immediate incident response. Release Management focuses on making new and changed services and features available for use, coordinating their deployment into live environments. Neither practice is directly responsible for the urgent, reactive restoration of an existing service that has failed due to an incident, as their roles are more about planned service evolution.

A
Service desk and incident management
Why it fails: The Service Desk functions as the single point of contact for users, logging incidents and facilitating their initial assessment and escalation, but it is not a practice that directly restores service functionality. While Incident Management is indeed crucial for restoring service, the Service Desk's role is primarily communication and coordination, not the technical restoration itself. Therefore, this option incorrectly identifies the Service Desk as a practice responsible for actively restoring service during a major incident.
B
Problem management and change management
Why it fails: Problem Management is focused on identifying the root causes of incidents to prevent their recurrence, which is a long-term, post-restoration activity, not the immediate action to restore service operation. Change Management, conversely, is the practice of ensuring that changes to services and infrastructure are implemented in a controlled manner, typically for improvements or permanent fixes. Neither practice is primarily responsible for the initial, urgent restoration of service after a major incident has occurred.
C
Incident management and problem management
Incident Management is the primary practice focused on restoring normal service operation as quickly as possible, often through temporary workarounds, to minimize business impact during a major incident. Concurrently or subsequently, Problem Management investigates the underlying causes of the incident to prevent its recurrence, ensuring long-term stability and service improvement. Together, these practices provide both immediate resolution and lasting prevention, which is critical for effectively managing major incidents.
D
Change management and release management
Why it fails: Change Management is the practice of controlling the lifecycle of all changes, enabling beneficial changes to be made with minimal disruption, and is typically a controlled, planned process, not an immediate incident response. Release Management focuses on making new and changed services and features available for use, coordinating their deployment into live environments. Neither practice is directly responsible for the urgent, reactive restoration of an existing service that has failed due to an incident, as their roles are more about planned service evolution.

Question 2hardmultiple choice

An organization is designing a new service. The service owner wants to ensure that the service can be operated within agreed service levels. Which ITIL management practice should be applied to define the acceptable performance levels?

Trap 1: Service Continuity Management

Service Continuity Management primarily focuses on ensuring that services can continue to operate at agreed levels during and after a disaster or major disruption. While it defines recovery objectives (RTO/RPO), these are specific to resilience and disaster recovery, not the initial definition of general performance targets (e.g., response times, throughput) for a new service under normal operating conditions. Its scope is risk management for service availability, not setting baseline performance metrics.

Trap 2: Capacity and Performance Management

Capacity and Performance Management is responsible for ensuring that services and service components can meet current and future performance requirements in a cost-effective manner. This practice actively monitors, analyzes, and optimizes performance against established benchmarks, but it does not define or negotiate the initial service level targets with customers. Its role is to deliver and maintain performance according to targets set by other practices.

Trap 3: Service Catalog Management

Service Catalog Management focuses on providing a single, consistent source of information on all services offered by the organization, detailing what services are available and how to request them. While a service catalog might list agreed service levels as part of a service description, the practice itself is concerned with the presentation and management of service offerings, not the negotiation, definition, or ongoing management of the underlying performance targets. It is a communication and enablement tool, not a target-setting mechanism.

A
Service Continuity Management
Why it fails: Service Continuity Management primarily focuses on ensuring that services can continue to operate at agreed levels during and after a disaster or major disruption. While it defines recovery objectives (RTO/RPO), these are specific to resilience and disaster recovery, not the initial definition of general performance targets (e.g., response times, throughput) for a new service under normal operating conditions. Its scope is risk management for service availability, not setting baseline performance metrics.
B
Capacity and Performance Management
Why it fails: Capacity and Performance Management is responsible for ensuring that services and service components can meet current and future performance requirements in a cost-effective manner. This practice actively monitors, analyzes, and optimizes performance against established benchmarks, but it does not define or negotiate the initial service level targets with customers. Its role is to deliver and maintain performance according to targets set by other practices.
C
Service Level Management
Service Level Management is the practice responsible for setting clear, business-focused service level targets and ensuring that the organization meets them. It involves defining, documenting, agreeing, monitoring, and reviewing service levels with customers, making it central to establishing the performance expectations for a new service during its design phase. This practice acts as the crucial interface for translating customer needs into measurable service commitments.
D
Service Catalog Management
Why it fails: Service Catalog Management focuses on providing a single, consistent source of information on all services offered by the organization, detailing what services are available and how to request them. While a service catalog might list agreed service levels as part of a service description, the practice itself is concerned with the presentation and management of service offerings, not the negotiation, definition, or ongoing management of the underlying performance targets. It is a communication and enablement tool, not a target-setting mechanism.

Question 3mediummultiple choice

An organization is considering adopting a new CRM system. The vendor's system requires the organization to provide clean customer data. This is an example of:

Trap 1: Utility

Utility refers to the functionality offered by a service, defining what the service does and whether it is fit for purpose. The act of a consumer providing clean data, while crucial for the system's effective operation, is an input to the service, not an inherent functional capability or feature of the CRM system itself. Therefore, the consumer's contribution of data does not directly represent the utility of the service.

Trap 2: Service relationship

A service relationship describes the collaboration between a service provider and a service consumer, encompassing all interactions and engagements involved in service provision and consumption. While the consumer providing data is indeed an interaction within this relationship, the specific emphasis on both parties contributing to the outcome through their respective inputs points more precisely to the concept of value co-creation. The service relationship is the broader context, whereas co-creation highlights the active, mutual contribution to value.

Trap 3: Risk removal

Risk removal involves actions taken to eliminate or significantly reduce the probability or impact of an undesirable outcome, thereby reducing uncertainty. While providing clean data helps mitigate future risks associated with poor data quality within the CRM system, the primary act of contributing this data is a direct input for service consumption and value realization, not fundamentally a risk management technique itself. It is a contribution to the service's success, rather than a direct strategy for eliminating a specific risk.

A
Utility
Why it fails: Utility refers to the functionality offered by a service, defining what the service does and whether it is fit for purpose. The act of a consumer providing clean data, while crucial for the system's effective operation, is an input to the service, not an inherent functional capability or feature of the CRM system itself. Therefore, the consumer's contribution of data does not directly represent the utility of the service.
B
Service relationship
Why it fails: A service relationship describes the collaboration between a service provider and a service consumer, encompassing all interactions and engagements involved in service provision and consumption. While the consumer providing data is indeed an interaction within this relationship, the specific emphasis on both parties contributing to the outcome through their respective inputs points more precisely to the concept of value co-creation. The service relationship is the broader context, whereas co-creation highlights the active, mutual contribution to value.
C
Risk removal
Why it fails: Risk removal involves actions taken to eliminate or significantly reduce the probability or impact of an undesirable outcome, thereby reducing uncertainty. While providing clean data helps mitigate future risks associated with poor data quality within the CRM system, the primary act of contributing this data is a direct input for service consumption and value realization, not fundamentally a risk management technique itself. It is a contribution to the service's success, rather than a direct strategy for eliminating a specific risk.
D
Value co-creation
Value co-creation is a core ITIL 4 concept where both the service provider and the service consumer actively collaborate and contribute to the creation of value. In this scenario, the provider offers the CRM system (the service offering), and the consumer actively provides essential clean data (a key input) to ensure the system's effectiveness and the realization of desired business outcomes. This mutual contribution, where each party's input is necessary for the overall success and benefit, perfectly exemplifies value co-creation.

Question 4mediummultiple choice

An IT team wants to prioritize incidents based on business impact and urgency. Which ITIL practice provides the framework for classifying and handling incidents?

Trap 1: Problem Management

Problem Management is an ITIL practice focused on reducing the likelihood and impact of incidents by identifying, diagnosing, and resolving the root causes of actual and potential incidents. While it aims to prevent future incidents, it does not involve the real-time prioritization of active incidents based on business impact. Its scope is proactive and reactive analysis of recurring issues, not immediate incident response.

Trap 2: Service Desk

The Service Desk is a key function that provides a single point of contact between the service provider and users, handling many service requests and incidents. While Service Desk personnel often execute the prioritization of incidents, it is the Incident Management practice that defines the methods, criteria, and procedures for how incidents are prioritized. The Service Desk acts as an interface, not the overarching practice governing prioritization.

Trap 3: Event Management

Event Management is the practice of monitoring all events occurring through IT infrastructure and services, filtering out noise, and identifying those that might indicate an exception or a normal operation. Its primary purpose is to detect changes of state that are significant for the management of IT services, which may trigger an incident. However, Event Management itself does not include the process or criteria for prioritizing an active incident once it has been identified.

A
Problem Management
Why it fails: Problem Management is an ITIL practice focused on reducing the likelihood and impact of incidents by identifying, diagnosing, and resolving the root causes of actual and potential incidents. While it aims to prevent future incidents, it does not involve the real-time prioritization of active incidents based on business impact. Its scope is proactive and reactive analysis of recurring issues, not immediate incident response.
B
Service Desk
Why it fails: The Service Desk is a key function that provides a single point of contact between the service provider and users, handling many service requests and incidents. While Service Desk personnel often execute the prioritization of incidents, it is the Incident Management practice that defines the methods, criteria, and procedures for how incidents are prioritized. The Service Desk acts as an interface, not the overarching practice governing prioritization.
C
Event Management
Why it fails: Event Management is the practice of monitoring all events occurring through IT infrastructure and services, filtering out noise, and identifying those that might indicate an exception or a normal operation. Its primary purpose is to detect changes of state that are significant for the management of IT services, which may trigger an incident. However, Event Management itself does not include the process or criteria for prioritizing an active incident once it has been identified.
D
Incident Management
Incident Management is the ITIL practice responsible for minimizing the negative impact of incidents by restoring normal service operation as quickly as possible. A core component of this practice involves the classification and prioritization of incidents, typically based on their urgency and impact on business operations. This ensures that critical incidents affecting business value are addressed with appropriate speed and resources.

Question 5hardmultiple choice

An IT team implements a new monitoring tool that reduces incident detection time but requires staff to learn a new interface, causing temporary productivity loss. Which ITIL 4 dimension is MOST overlooked in this scenario?

Trap 1: Partners and Suppliers

This dimension focuses on the relationships an organization has with other organizations that are involved in the design, development, delivery, support, and continual improvement of services. Since the question describes an internal IT team implementing a tool and experiencing internal challenges, there is no mention or implication of issues arising from external partners or suppliers, making this dimension irrelevant to the described problem.

Trap 2: Information and Technology

While the implementation of a new monitoring tool clearly falls within the scope of the Information and Technology dimension, the problem described is not a deficiency in the technology itself or a failure in information management practices. The tool is functioning as intended; the issue lies with the human element's adaptation to and interaction with this new technological solution, rather than the technology's inherent capabilities or limitations.

Trap 3: Value Streams and Processes

This dimension describes how the organization's activities are structured and coordinated to create value for stakeholders. Although a new tool often necessitates adjustments to existing processes or the creation of new ones, the core problem identified—a skill gap and temporary productivity loss—pertains to the human capacity to execute those processes effectively, not a fundamental flaw in the design or flow of the value stream or process steps themselves.

A
Partners and Suppliers
Why it fails: This dimension focuses on the relationships an organization has with other organizations that are involved in the design, development, delivery, support, and continual improvement of services. Since the question describes an internal IT team implementing a tool and experiencing internal challenges, there is no mention or implication of issues arising from external partners or suppliers, making this dimension irrelevant to the described problem.
B
Information and Technology
Why it fails: While the implementation of a new monitoring tool clearly falls within the scope of the Information and Technology dimension, the problem described is not a deficiency in the technology itself or a failure in information management practices. The tool is functioning as intended; the issue lies with the human element's adaptation to and interaction with this new technological solution, rather than the technology's inherent capabilities or limitations.
C
Value Streams and Processes
Why it fails: This dimension describes how the organization's activities are structured and coordinated to create value for stakeholders. Although a new tool often necessitates adjustments to existing processes or the creation of new ones, the core problem identified—a skill gap and temporary productivity loss—pertains to the human capacity to execute those processes effectively, not a fundamental flaw in the design or flow of the value stream or process steps themselves.
D
Organisations and People
This dimension encompasses the organizational structure, culture, roles, responsibilities, and the required skills and competencies of all personnel involved in service management. The described issue, where the IT team experiences a skill gap and temporary productivity loss after implementing a new tool, directly highlights a failure to adequately prepare and enable the people within the organization for the change, making this the primary dimension affected.

Question 6mediummultiple choice

A software development team delivers a new feature to the marketing department. The feature is working but the marketing team reports no increase in campaign effectiveness. Which ITIL 4 distinction does this illustrate?

Trap 1: Incident vs Problem

An incident is an unplanned interruption to a service or a reduction in its quality, requiring immediate resolution to restore normal operation. A problem, on the other hand, is the underlying cause of one or more incidents, which requires investigation and root cause analysis to prevent recurrence. The scenario describes the delivery of a new feature by a development team, which is an act of creation, not a disruption to an existing service or the investigation of its underlying cause.

Trap 2: Service Request vs Change

A service request is a formal request from a user for something standard, such as information, advice, or access to a standard service component, typically handled through pre-defined procedures. A change is the addition, modification, or removal of anything that could have a direct or indirect effect on services, requiring formal assessment and authorization. The question describes a development team delivering a new feature, which is neither a routine user request nor solely a change to an existing service configuration, but rather a product of development.

Trap 3: Utility vs Warranty

Utility refers to the functionality offered by a service to meet a particular need, addressing what the service does and whether it is fit for purpose. Warranty, in contrast, provides assurance that a service will meet agreed requirements regarding availability, capacity, continuity, and security, addressing how the service performs and whether it is fit for use. The question focuses on the distinction between a tangible deliverable (the feature) and the actual benefit it provides, not the inherent quality or performance characteristics of a service itself.

A
Output vs Outcome
An output is a tangible deliverable produced by an activity, such as the new software feature itself. An outcome, conversely, is the result or effect achieved for a stakeholder, often enabled by the output, representing the actual value realized. The question describes the delivery of a feature and implies its subsequent impact, directly aligning with this distinction, making it the correct choice for differentiating the deliverable from its benefit.
B
Incident vs Problem
Why it fails: An incident is an unplanned interruption to a service or a reduction in its quality, requiring immediate resolution to restore normal operation. A problem, on the other hand, is the underlying cause of one or more incidents, which requires investigation and root cause analysis to prevent recurrence. The scenario describes the delivery of a new feature by a development team, which is an act of creation, not a disruption to an existing service or the investigation of its underlying cause.
C
Service Request vs Change
Why it fails: A service request is a formal request from a user for something standard, such as information, advice, or access to a standard service component, typically handled through pre-defined procedures. A change is the addition, modification, or removal of anything that could have a direct or indirect effect on services, requiring formal assessment and authorization. The question describes a development team delivering a new feature, which is neither a routine user request nor solely a change to an existing service configuration, but rather a product of development.
D
Utility vs Warranty
Why it fails: Utility refers to the functionality offered by a service to meet a particular need, addressing what the service does and whether it is fit for purpose. Warranty, in contrast, provides assurance that a service will meet agreed requirements regarding availability, capacity, continuity, and security, addressing how the service performs and whether it is fit for use. The question focuses on the distinction between a tangible deliverable (the feature) and the actual benefit it provides, not the inherent quality or performance characteristics of a service itself.

Question 7hardmultiple choice

A major incident occurs when the database server fails. The team applies a fix to restore service. Later, they investigate the root cause and implement a permanent solution. Which ITIL 4 practices are involved?

Trap 1: Service Request Management and Problem Management

Service Request Management focuses on fulfilling pre-defined user requests, such as password resets or software installations, which are planned and routine activities. A database server failure represents an unplanned disruption requiring immediate restoration, not a routine request. While Problem Management is correctly associated with investigating the root cause, its pairing with Service Request Management makes this option incorrect for a major incident scenario.

Trap 2: Incident Management and Change Management

Incident Management is indeed critical for restoring service after a database failure. However, Change Management primarily governs the planned addition, modification, or removal of IT services or components to minimize risk. While a change might have triggered the incident or a change might be needed to implement a permanent fix, Change Management itself is not the practice directly responsible for the immediate response to an unplanned outage or the subsequent root cause analysis.

Trap 3: Problem Management and Service Desk

Problem Management is correctly identified as the practice for investigating the underlying causes of incidents to prevent their recurrence. However, the Service Desk is a function, not a management practice, primarily acting as the single point of contact for users to log incidents and service requests. While the Service Desk would log the major incident, it does not directly perform the technical restoration or the in-depth root cause analysis that constitutes the core activities of Incident and Problem Management practices.

A
Service Request Management and Problem Management
Why it fails: Service Request Management focuses on fulfilling pre-defined user requests, such as password resets or software installations, which are planned and routine activities. A database server failure represents an unplanned disruption requiring immediate restoration, not a routine request. While Problem Management is correctly associated with investigating the root cause, its pairing with Service Request Management makes this option incorrect for a major incident scenario.
B
Incident Management and Change Management
Why it fails: Incident Management is indeed critical for restoring service after a database failure. However, Change Management primarily governs the planned addition, modification, or removal of IT services or components to minimize risk. While a change might have triggered the incident or a change might be needed to implement a permanent fix, Change Management itself is not the practice directly responsible for the immediate response to an unplanned outage or the subsequent root cause analysis.
C
Incident Management and Problem Management
Incident Management is the practice specifically designed to minimize the negative impact of incidents by restoring normal service operation as quickly as possible following an unplanned disruption, such as a database server failure. Concurrently, Problem Management is crucial for identifying the root causes of incidents, managing workarounds, and preventing recurrence. A major incident invariably triggers both practices: immediate restoration via Incident Management and subsequent investigation via Problem Management.
D
Problem Management and Service Desk
Why it fails: Problem Management is correctly identified as the practice for investigating the underlying causes of incidents to prevent their recurrence. However, the Service Desk is a function, not a management practice, primarily acting as the single point of contact for users to log incidents and service requests. While the Service Desk would log the major incident, it does not directly perform the technical restoration or the in-depth root cause analysis that constitutes the core activities of Incident and Problem Management practices.

Question 8hardmultiple choice

An organization is planning to outsource its IT support. Which ITIL concept describes the relationship between the organization and the external service provider?

Trap 1: Supplier management

Supplier management is an ITIL practice focused on ensuring that an organization's suppliers and their performance are managed appropriately to support the seamless provision of quality products and services. While crucial for outsourcing, it describes the *activities* and *controls* applied to suppliers, rather than defining the fundamental, cooperative *relationship* between the service provider (the outsourced company) and the service consumer (the organization). It is a means to manage, not the overarching relationship itself.

Trap 2: Service portfolio

The service portfolio is a comprehensive collection of all services an organization manages across their entire lifecycle, encompassing current, retired, and pipeline services. While it lists the specific IT support services that might be outsourced, it fundamentally represents the *offerings* and their status, not the dynamic, interactive engagement or the cooperative connection that forms between the organization and its external IT support provider. It defines the scope of services, not the nature of the interaction.

Trap 3: Service level agreement (SLA)

A Service Level Agreement (SLA) is a documented agreement between a service provider and a service consumer that specifies the services to be provided, the expected service levels, and the responsibilities of both parties. While an SLA is a critical component *within* a service relationship for defining performance expectations and obligations, it is a specific contractual instrument rather than the overarching conceptual framework that describes the cooperative interaction and value co-creation between the parties.

A
Supplier management
Why it fails: Supplier management is an ITIL practice focused on ensuring that an organization's suppliers and their performance are managed appropriately to support the seamless provision of quality products and services. While crucial for outsourcing, it describes the *activities* and *controls* applied to suppliers, rather than defining the fundamental, cooperative *relationship* between the service provider (the outsourced company) and the service consumer (the organization). It is a means to manage, not the overarching relationship itself.
B
Service relationship
A service relationship describes the cooperation between a service provider and a service consumer, facilitating value co-creation through the consumption of services. When an organization outsources its IT support, it enters into a service relationship with the external provider, where both parties collaborate to achieve desired outcomes and realize value from the IT services delivered. This concept encapsulates the mutual engagement and interaction essential for successful outsourcing.
C
Service portfolio
Why it fails: The service portfolio is a comprehensive collection of all services an organization manages across their entire lifecycle, encompassing current, retired, and pipeline services. While it lists the specific IT support services that might be outsourced, it fundamentally represents the *offerings* and their status, not the dynamic, interactive engagement or the cooperative connection that forms between the organization and its external IT support provider. It defines the scope of services, not the nature of the interaction.
D
Service level agreement (SLA)
Why it fails: A Service Level Agreement (SLA) is a documented agreement between a service provider and a service consumer that specifies the services to be provided, the expected service levels, and the responsibilities of both parties. While an SLA is a critical component *within* a service relationship for defining performance expectations and obligations, it is a specific contractual instrument rather than the overarching conceptual framework that describes the cooperative interaction and value co-creation between the parties.

Question 9mediummultiple choice

A company is implementing a new CRM system. The project team is focusing on the technology and processes, but is neglecting to define clear roles and responsibilities for the service desk and system administrators. Which dimension of service management is being overlooked?

Trap 1: Value Streams and Processes

The "Value Streams and Processes" dimension describes how an organization's various activities, workflows, controls, and procedures are integrated and managed to create, deliver, and support services. While it defines *what* activities are performed and *how* they flow from demand to value, it does not primarily define the *who* – the roles, responsibilities, or organizational structures involved in executing those activities. Therefore, it is incorrect for defining the roles within a project team.

Trap 2: Information and Technology

The "Information and Technology" dimension focuses on the information and knowledge necessary for service management, along with the technologies required to manage services. This includes data, information systems, applications, infrastructure, and knowledge management tools. While a CRM system itself falls squarely within this dimension, the dimension does not define the human roles, responsibilities, or organizational structure of the project team implementing or managing that technology.

Trap 3: Partners and Suppliers

The "Partners and Suppliers" dimension describes an organization's relationships with other organizations that are involved in the design, development, delivery, support, or continual improvement of services. This includes contracts, agreements, and the management of external vendors or partners. It specifically addresses external entities and their contributions to the value chain, not the internal roles and responsibilities of an organization's own project team members.

A
Value Streams and Processes
Why it fails: The "Value Streams and Processes" dimension describes how an organization's various activities, workflows, controls, and procedures are integrated and managed to create, deliver, and support services. While it defines *what* activities are performed and *how* they flow from demand to value, it does not primarily define the *who* – the roles, responsibilities, or organizational structures involved in executing those activities. Therefore, it is incorrect for defining the roles within a project team.
B
Organization and People
The "Organization and People" dimension specifically addresses the human element of service management, encompassing the structure of the organization, its culture, and the required competencies. This includes defining roles, responsibilities, authorities, and skill sets for individuals and teams, such as a project team implementing a new CRM system. It ensures that the right people with the right skills are in the right places to deliver value effectively.
C
Information and Technology
Why it fails: The "Information and Technology" dimension focuses on the information and knowledge necessary for service management, along with the technologies required to manage services. This includes data, information systems, applications, infrastructure, and knowledge management tools. While a CRM system itself falls squarely within this dimension, the dimension does not define the human roles, responsibilities, or organizational structure of the project team implementing or managing that technology.
D
Partners and Suppliers
Why it fails: The "Partners and Suppliers" dimension describes an organization's relationships with other organizations that are involved in the design, development, delivery, support, or continual improvement of services. This includes contracts, agreements, and the management of external vendors or partners. It specifically addresses external entities and their contributions to the value chain, not the internal roles and responsibilities of an organization's own project team members.

Question 10mediummulti select

Which TWO of the following are potential consequences of neglecting the Partners and Suppliers dimension?

Trap 1: Better service quality

Neglect in IT service management practices, such as incident management, problem management, or service level management, inherently degrades service quality rather than improving it. Without proactive monitoring, continuous improvement efforts, and diligent resolution of issues, services become less reliable, less available, and fail to meet user expectations. Quality is a direct outcome of deliberate effort and attention, which are absent in a state of neglect.

Trap 2: Improved agility

Organizational agility, the ability to respond quickly and effectively to change, is fundamentally undermined by neglect across IT service management. Neglecting practices like change enablement, deployment management, or even strategic planning prevents an organization from adapting rapidly to new demands or market shifts. Instead of fostering flexibility, neglect creates technical debt, rigid processes, and a reactive posture, severely hindering any potential for improved agility.

Trap 3: Increased innovation

Innovation thrives on dedicated resources, a culture of experimentation, and continuous investment in new ideas and technologies, all of which are absent when an organization is in a state of neglect. Neglecting IT capabilities means a lack of focus on research, development, and the adoption of emerging technologies, stifling any potential for creative solutions or process improvements. Instead of fostering new approaches, neglect leads to stagnation, technical obsolescence, and a diminished capacity for future innovation.

A
Supply chain disruptions
Neglecting supplier management, a critical ITIL practice, inevitably leads to a lack of oversight regarding external providers. This absence of monitoring can result in unaddressed performance issues, failure to meet agreed-upon service levels, and ultimately, significant disruptions to the supply chain of IT services and products. Such disruptions directly impact an organization's ability to deliver value to its customers.
B
Better service quality
Why it fails: Neglect in IT service management practices, such as incident management, problem management, or service level management, inherently degrades service quality rather than improving it. Without proactive monitoring, continuous improvement efforts, and diligent resolution of issues, services become less reliable, less available, and fail to meet user expectations. Quality is a direct outcome of deliberate effort and attention, which are absent in a state of neglect.
C
Improved agility
Why it fails: Organizational agility, the ability to respond quickly and effectively to change, is fundamentally undermined by neglect across IT service management. Neglecting practices like change enablement, deployment management, or even strategic planning prevents an organization from adapting rapidly to new demands or market shifts. Instead of fostering flexibility, neglect creates technical debt, rigid processes, and a reactive posture, severely hindering any potential for improved agility.
D
Poor contract management
Neglecting the supplier management practice often manifests as poor contract management, where the terms and conditions with external providers are not adequately monitored or enforced. This lack of attention can lead to missed renewal dates, failure to hold suppliers accountable to Service Level Agreements (SLAs), and an inability to renegotiate favorable terms. Consequently, the organization may incur unnecessary costs, suffer from underperforming services, and face increased risks due to unmanaged contractual obligations.
E
Increased innovation
Why it fails: Innovation thrives on dedicated resources, a culture of experimentation, and continuous investment in new ideas and technologies, all of which are absent when an organization is in a state of neglect. Neglecting IT capabilities means a lack of focus on research, development, and the adoption of emerging technologies, stifling any potential for creative solutions or process improvements. Instead of fostering new approaches, neglect leads to stagnation, technical obsolescence, and a diminished capacity for future innovation.

Question 11mediummultiple choice

A user reports they cannot print to a network printer. The service desk analyst suspects a driver issue. Which ITIL 4 concept BEST describes this scenario?

Trap 1: Problem

A Problem, in ITIL 4, is the cause, or potential cause, of one or more incidents. While the printing issue might eventually lead to the discovery of an underlying problem (e.g., a faulty print server driver or network configuration error), the immediate report from the user describes the *effect* of that underlying issue, which is an incident. Problem management focuses on identifying and resolving the root cause to prevent future incidents, not on the initial service disruption itself.

Trap 2: Change

A Change, according to ITIL 4, refers to the addition, modification, or removal of anything that could have a direct or indirect effect on services. The user's inability to print is an unplanned disruption, not a planned activity to alter the IT infrastructure or services. Changes are typically pre-authorized and managed through a structured process to minimize risk, whereas this printing issue is an unexpected failure of an existing service.

Trap 3: Service request

A Service Request is a formal request from a user for something standard and pre-defined, such as requesting access to an application, a new laptop, or information. Unlike an incident, a service request is a planned, expected interaction where the user is asking for a specific, usually minor, service or information. The user reporting they *cannot* print indicates a failure of an existing service, not a request for a new or standard item.

A
Incident
An Incident is defined in ITIL 4 as an unplanned interruption to a service or a reduction in the quality of a service. The user's inability to print to a network printer directly represents such an interruption, preventing them from performing their work as expected. The primary goal of incident management is to restore normal service operation as quickly as possible to minimize business impact. This scenario perfectly fits the definition of an incident requiring immediate attention.
B
Problem
Why it fails: A Problem, in ITIL 4, is the cause, or potential cause, of one or more incidents. While the printing issue might eventually lead to the discovery of an underlying problem (e.g., a faulty print server driver or network configuration error), the immediate report from the user describes the *effect* of that underlying issue, which is an incident. Problem management focuses on identifying and resolving the root cause to prevent future incidents, not on the initial service disruption itself.
C
Change
Why it fails: A Change, according to ITIL 4, refers to the addition, modification, or removal of anything that could have a direct or indirect effect on services. The user's inability to print is an unplanned disruption, not a planned activity to alter the IT infrastructure or services. Changes are typically pre-authorized and managed through a structured process to minimize risk, whereas this printing issue is an unexpected failure of an existing service.
D
Service request
Why it fails: A Service Request is a formal request from a user for something standard and pre-defined, such as requesting access to an application, a new laptop, or information. Unlike an incident, a service request is a planned, expected interaction where the user is asking for a specific, usually minor, service or information. The user reporting they *cannot* print indicates a failure of an existing service, not a request for a new or standard item.

Question 12mediummultiple choice

A company provides an email service to its employees. The service is accessible 99.99% of the time and meets all performance targets. Which ITIL 4 concept does this represent?

Trap 1: Output

An output is a tangible or intangible deliverable produced by an activity or service. For an email service, outputs include the actual sent messages, stored emails, or the availability of the mailbox interface. However, an output itself does not provide the assurance that the service will consistently meet agreed performance levels, such as availability or security, which is what the question implies seeking.

Trap 2: Utility

Utility refers to the functionality offered by a product or service to meet a particular need, making it 'fit for purpose.' For an email service, utility includes core features such as sending and receiving messages, managing contacts, and attaching files. It describes what the service does and its inherent usefulness, rather than providing assurance about its performance characteristics like uptime or speed.

Trap 3: Outcome

An outcome represents a result for a stakeholder, enabled by one or more outputs. These are the ultimate benefits or changes experienced by users or organizations due to consuming a service. For an email service, an outcome might be enhanced employee collaboration or improved decision-making efficiency, which are effects of using the service, not the assurance of the service's operational quality itself.

A
Output
Why it fails: An output is a tangible or intangible deliverable produced by an activity or service. For an email service, outputs include the actual sent messages, stored emails, or the availability of the mailbox interface. However, an output itself does not provide the assurance that the service will consistently meet agreed performance levels, such as availability or security, which is what the question implies seeking.
B
Warranty
Warranty provides the assurance that a service or product will meet agreed requirements and is 'fit for use.' This encompasses aspects like availability, capacity, security, and continuity, ensuring the service performs reliably. For an email service, warranty confirms that it will be accessible when needed, handle the expected volume of messages, and protect user data according to specified standards.
C
Utility
Why it fails: Utility refers to the functionality offered by a product or service to meet a particular need, making it 'fit for purpose.' For an email service, utility includes core features such as sending and receiving messages, managing contacts, and attaching files. It describes what the service does and its inherent usefulness, rather than providing assurance about its performance characteristics like uptime or speed.
D
Outcome
Why it fails: An outcome represents a result for a stakeholder, enabled by one or more outputs. These are the ultimate benefits or changes experienced by users or organizations due to consuming a service. For an email service, an outcome might be enhanced employee collaboration or improved decision-making efficiency, which are effects of using the service, not the assurance of the service's operational quality itself.

Question 13hardmultiple choice

An organisation implements a new human resources (HR) system. The project team delivers the system on time and within budget. However, HR staff find the system difficult to use and employee satisfaction with HR services does not improve. According to ITIL 4, which statement describes this situation?

Trap 1: The output and outcome are the same in this context

This statement is incorrect because ITIL 4 clearly distinguishes between outputs and outcomes. An output is a tangible or intangible deliverable produced by an activity, such as the successfully deployed HR system itself. An outcome, conversely, represents the actual benefit or change experienced by stakeholders, like improved employee satisfaction, which is the result enabled by the output.

Trap 2: The outcome (employee satisfaction) was achieved, but the output…

This statement is incorrect on both counts. The scenario explicitly states the HR system was delivered on time and budget, indicating the output (system delivery) was successful, not a failure. Furthermore, the desired outcome of improved employee satisfaction was not achieved, directly contradicting the claim that it was realized.

Trap 3: The output and outcome were both achieved

While the output, meaning the successful delivery of the new HR system, was indeed achieved as per the scenario, the statement incorrectly asserts that the outcome was also achieved. The desired outcome of improved employee satisfaction did not materialize. Therefore, claiming both were achieved is false, as the critical stakeholder benefit was not realized.

A
The output and outcome are the same in this context
Why it fails: This statement is incorrect because ITIL 4 clearly distinguishes between outputs and outcomes. An output is a tangible or intangible deliverable produced by an activity, such as the successfully deployed HR system itself. An outcome, conversely, represents the actual benefit or change experienced by stakeholders, like improved employee satisfaction, which is the result enabled by the output.
B
The outcome (employee satisfaction) was achieved, but the output (delivery) failed
Why it fails: This statement is incorrect on both counts. The scenario explicitly states the HR system was delivered on time and budget, indicating the output (system delivery) was successful, not a failure. Furthermore, the desired outcome of improved employee satisfaction was not achieved, directly contradicting the claim that it was realized.
C
The output (system delivery) was successful, but the outcome (improved satisfaction) was not achieved
This option accurately reflects the scenario by distinguishing between output and outcome, a core ITIL 4 concept. The output, which is the successful delivery and implementation of the new HR system within specified project constraints (on time, on budget), was achieved. However, the desired outcome, specifically the improvement in employee satisfaction that the system was intended to facilitate, was not realized, highlighting a common challenge in value co-creation.
D
The output and outcome were both achieved
Why it fails: While the output, meaning the successful delivery of the new HR system, was indeed achieved as per the scenario, the statement incorrectly asserts that the outcome was also achieved. The desired outcome of improved employee satisfaction did not materialize. Therefore, claiming both were achieved is false, as the critical stakeholder benefit was not realized.

Question 14hardmultiple choice

An IT service manager notices that a new cloud-based monitoring tool provides real-time data but the security configuration is complex. Users are bypassing the tool because they find it difficult to use. Which ITIL 4 dimension is being neglected?

Trap 1: Partners and Suppliers

The Partners and Suppliers dimension focuses on the relationships an organization has with external entities that are involved in the design, development, delivery, support, or continual improvement of services. The scenario describes an internal challenge with user adoption of a new tool, not an issue stemming from the performance, contractual obligations, or relationship management with any third-party cloud provider or other external partner. Therefore, the problem lies within the organization's internal capabilities and people, rather than its external sourcing arrangements.

Trap 2: Information and Technology

The Information and Technology dimension focuses on the information and knowledge required to manage services, and the technologies that support and enable service provision. While the new cloud-based monitoring tool itself is a technology component, the problem statement explicitly indicates user rejection, implying the tool's technical functionality, reliability, or underlying information architecture is not the root cause. The issue is not with the technology's inherent capability but with its human adoption and integration into existing work practices.

Trap 3: Value Streams and Processes

The Value Streams and Processes dimension describes how the organization creates, delivers, and consumes value through defined activities, workflows, and procedures. While a new tool might necessitate changes to existing value streams or processes, the core problem here is user unwillingness to engage with the tool itself, rather than a fundamental flaw in the redesigned workflow or the process steps. The issue precedes the execution of the value stream, residing in the human element's acceptance of the new technology rather than the process design itself.

A
Partners and Suppliers
Why it fails: The Partners and Suppliers dimension focuses on the relationships an organization has with external entities that are involved in the design, development, delivery, support, or continual improvement of services. The scenario describes an internal challenge with user adoption of a new tool, not an issue stemming from the performance, contractual obligations, or relationship management with any third-party cloud provider or other external partner. Therefore, the problem lies within the organization's internal capabilities and people, rather than its external sourcing arrangements.
B
Organizations and People
This dimension directly addresses the human element within service management, encompassing the organizational structure, culture, leadership, and the capabilities and competencies of all personnel. User rejection of a new cloud-based monitoring tool is a clear indicator of issues within this dimension, specifically concerning inadequate user training, poor communication regarding the change, or a failure to manage the transition effectively. Successful adoption hinges on ensuring users are prepared, willing, and able to utilize new technologies, which requires strong change management and user enablement strategies.
C
Information and Technology
Why it fails: The Information and Technology dimension focuses on the information and knowledge required to manage services, and the technologies that support and enable service provision. While the new cloud-based monitoring tool itself is a technology component, the problem statement explicitly indicates user rejection, implying the tool's technical functionality, reliability, or underlying information architecture is not the root cause. The issue is not with the technology's inherent capability but with its human adoption and integration into existing work practices.
D
Value Streams and Processes
Why it fails: The Value Streams and Processes dimension describes how the organization creates, delivers, and consumes value through defined activities, workflows, and procedures. While a new tool might necessitate changes to existing value streams or processes, the core problem here is user unwillingness to engage with the tool itself, rather than a fundamental flaw in the redesigned workflow or the process steps. The issue precedes the execution of the value stream, residing in the human element's acceptance of the new technology rather than the process design itself.

Question 15hardmultiple choice

An organization has implemented a new customer relationship management (CRM) system. Users are now able to access customer data 50% faster, leading to increased sales. Which of the following describes the output vs. outcome in this scenario?

Trap 1: Output: faster data access; Outcome: the CRM system

This option incorrectly reverses the definitions of output and outcome. An output is a tangible or intangible deliverable produced by an activity, such as the implemented CRM system itself. Conversely, an outcome represents the benefit or result achieved for stakeholders through the use of that output, like the "faster data access" that improves operational efficiency and customer experience. Therefore, stating "faster data access" as an output and "the CRM system" as an outcome fundamentally misrepresents their ITIL 4 definitions.

Trap 2: Output: the CRM system; Outcome: revenue from the project

While "revenue from the project" is a financial result, it is not the most direct or comprehensive outcome in the context of ITIL 4's focus on value. An outcome typically describes the change in stakeholder behavior or experience, or the business benefit derived from the *use* of the output, such as improved efficiency or customer satisfaction. Project revenue is a financial metric of the project's success, but the primary outcomes of a CRM implementation are the operational and customer-facing improvements it enables, which then *contribute* to revenue.

Trap 3: Output: increased sales; Outcome: the CRM system

This option incorrectly assigns "increased sales" as an output and "the CRM system" as an outcome, which is a fundamental misapplication of ITIL 4 terminology. "Increased sales" is a beneficial result achieved through the effective utilization of the CRM system, making it a clear outcome. The "CRM system" itself is the tangible deliverable or product that facilitates these improved sales, thus classifying it as the output. This reversal demonstrates a misunderstanding of the cause-and-effect relationship between deliverables and their realized benefits.

A
Output: faster data access; Outcome: the CRM system
Why it fails: This option incorrectly reverses the definitions of output and outcome. An output is a tangible or intangible deliverable produced by an activity, such as the implemented CRM system itself. Conversely, an outcome represents the benefit or result achieved for stakeholders through the use of that output, like the "faster data access" that improves operational efficiency and customer experience. Therefore, stating "faster data access" as an output and "the CRM system" as an outcome fundamentally misrepresents their ITIL 4 definitions.
B
Output: the CRM system; Outcome: faster data access and increased sales
This option correctly identifies the output and outcome. The "CRM system" is the tangible output, representing the specific product or service component delivered by the organization's activities. "Faster data access and increased sales" are the desired outcomes, which are the benefits realized by the organization and its customers as a result of utilizing the CRM system. This alignment demonstrates a clear understanding of how delivered outputs enable the achievement of valuable business outcomes, central to the ITIL 4 value co-creation model.
C
Output: the CRM system; Outcome: revenue from the project
Why it fails: While "revenue from the project" is a financial result, it is not the most direct or comprehensive outcome in the context of ITIL 4's focus on value. An outcome typically describes the change in stakeholder behavior or experience, or the business benefit derived from the *use* of the output, such as improved efficiency or customer satisfaction. Project revenue is a financial metric of the project's success, but the primary outcomes of a CRM implementation are the operational and customer-facing improvements it enables, which then *contribute* to revenue.
D
Output: increased sales; Outcome: the CRM system
Why it fails: This option incorrectly assigns "increased sales" as an output and "the CRM system" as an outcome, which is a fundamental misapplication of ITIL 4 terminology. "Increased sales" is a beneficial result achieved through the effective utilization of the CRM system, making it a clear outcome. The "CRM system" itself is the tangible deliverable or product that facilitates these improved sales, thus classifying it as the output. This reversal demonstrates a misunderstanding of the cause-and-effect relationship between deliverables and their realized benefits.

Question 16hardmultiple choice

A service provider offers a cloud-based application with 99.9% uptime guarantee. Which aspect of service value does the uptime guarantee represent?

Trap 1: Output

An output is a tangible or intangible deliverable produced by an activity. While an output contributes to the overall service, it represents a specific result of a task or process, such as a generated report or a processed transaction. It does not inherently provide a guarantee or assurance about the service's performance characteristics or its fitness for use over time, which is what the question implies with "99% availability."

Trap 2: Utility

Utility describes what the service does, specifically its functionality and whether it is "fit for purpose." It addresses whether the service can perform the required tasks and support the customer's desired outcomes. For instance, a cloud application's utility might be its ability to process data or manage customer relationships. However, utility does not encompass the non-functional requirements like availability or performance levels, which are covered by warranty.

Trap 3: Outcome

An outcome is the result achieved by a stakeholder, enabled by the use of a service. It represents what the customer *wants to achieve* or the value they derive from consuming the service, rather than a characteristic of the service itself. While a service's availability (warranty) contributes to achieving positive outcomes, the outcome itself is the end result or benefit, not a contractual guarantee about the service's operational performance.

A
Warranty
Warranty, in ITIL 4, refers to the assurance that a service will meet agreed-upon requirements regarding its performance and fitness for use. This specifically includes aspects like availability (e.g., 99% uptime), capacity (ability to handle expected load), continuity (resilience to disruptions), and security (protection against unauthorized access). It answers the question "how well does the service perform?" and is typically defined in Service Level Agreements (SLAs) or other contractual terms.
B
Output
Why it fails: An output is a tangible or intangible deliverable produced by an activity. While an output contributes to the overall service, it represents a specific result of a task or process, such as a generated report or a processed transaction. It does not inherently provide a guarantee or assurance about the service's performance characteristics or its fitness for use over time, which is what the question implies with "99% availability."
C
Utility
Why it fails: Utility describes what the service does, specifically its functionality and whether it is "fit for purpose." It addresses whether the service can perform the required tasks and support the customer's desired outcomes. For instance, a cloud application's utility might be its ability to process data or manage customer relationships. However, utility does not encompass the non-functional requirements like availability or performance levels, which are covered by warranty.
D
Outcome
Why it fails: An outcome is the result achieved by a stakeholder, enabled by the use of a service. It represents what the customer *wants to achieve* or the value they derive from consuming the service, rather than a characteristic of the service itself. While a service's availability (warranty) contributes to achieving positive outcomes, the outcome itself is the end result or benefit, not a contractual guarantee about the service's operational performance.

Question 17mediummultiple choice

A change request to upgrade the email server is assessed and authorized by the Change Advisory Board (CAB). After testing, it is scheduled for the next weekend. What type of change is this?

Trap 1: Emergency change

An emergency change is specifically designed to address critical incidents or urgent issues that are causing significant service degradation or outage, requiring immediate action to restore normal operation. While an email server upgrade is important, it is a planned enhancement, not a reactive measure to an unforeseen failure. Therefore, it does not fit the criteria for an emergency change, which prioritizes speed over full assessment due to the immediate threat to service availability.

Trap 2: Service request

A service request is a formal user request for something routine, such as information, advice, access to a service, or a pre-defined standard change. It is typically fulfilled through a standardized, often automated, process without requiring extensive assessment or formal change authorization. An email server upgrade, however, represents a substantial modification to an existing IT service, necessitating a comprehensive change management process rather than simple request fulfillment.

Trap 3: Standard change

A standard change is a pre-approved, low-risk modification that follows a documented procedure, such as applying a routine security patch. This scenario fails because the email server upgrade requires assessment and authorisation by the CAB, which is not part of a standard change’s pre-approved workflow. It is tempting because standard changes are often used for scheduled, low-risk updates, and the weekend scheduling might suggest a routine activity; however, the CAB’s involvement explicitly places this as a normal change.

A
Emergency change
Why it fails: An emergency change is specifically designed to address critical incidents or urgent issues that are causing significant service degradation or outage, requiring immediate action to restore normal operation. While an email server upgrade is important, it is a planned enhancement, not a reactive measure to an unforeseen failure. Therefore, it does not fit the criteria for an emergency change, which prioritizes speed over full assessment due to the immediate threat to service availability.
B
Normal change
A normal change is the standard process for implementing significant modifications to services or service components that are not pre-approved as standard changes or necessitated by an emergency. This type of change requires thorough assessment of risks and benefits, detailed planning, and formal authorization by a designated Change Authority or Change Advisory Board (CAB). An email server upgrade, involving potential service disruption and requiring careful coordination, perfectly aligns with the structured governance provided by a normal change process.
C
Service request
Why it fails: A service request is a formal user request for something routine, such as information, advice, access to a service, or a pre-defined standard change. It is typically fulfilled through a standardized, often automated, process without requiring extensive assessment or formal change authorization. An email server upgrade, however, represents a substantial modification to an existing IT service, necessitating a comprehensive change management process rather than simple request fulfillment.
D
Standard change
Why it fails: A standard change is a pre-approved, low-risk modification that follows a documented procedure, such as applying a routine security patch. This scenario fails because the email server upgrade requires assessment and authorisation by the CAB, which is not part of a standard change’s pre-approved workflow. It is tempting because standard changes are often used for scheduled, low-risk updates, and the weekend scheduling might suggest a routine activity; however, the CAB’s involvement explicitly places this as a normal change.

Question 18hardmultiple choice

During a major incident, the IT team implements a temporary workaround to restore service. Later, a permanent fix is applied. Which ITIL 4 practice is primarily responsible for ensuring the permanent fix is identified and applied?

Trap 1: Change Management

Change Management (now often referred to as Change Enablement in ITIL 4) is primarily concerned with controlling the lifecycle of all changes, ensuring they are assessed, authorized, and implemented with minimal risk to IT services. While a permanent fix identified by Problem Management would eventually be implemented as a change, Change Management's role is not to identify the root cause of incidents or develop the solution itself. Its focus is on the successful deployment and control of pre-defined changes.

Trap 2: Service Desk

The Service Desk serves as the single point of contact for users, responsible for logging incidents, fulfilling service requests, and providing initial support. Its primary objective is to restore normal service operation quickly, often by applying known workarounds or escalating to other support teams. However, the Service Desk does not perform in-depth root cause analysis or manage the process of developing and implementing permanent solutions for recurring issues.

Trap 3: Incident Management

Incident Management coordinates the immediate restoration of service through workarounds, but its scope ends once service is restored; it does not own the process of identifying, developing, and deploying a permanent fix. That responsibility belongs to Problem Management, which conducts root cause analysis and manages the known error database to ensure a structural resolution is implemented. Incident Management is tempting because it handles the initial response and coordinates the workaround, so candidates may assume it also oversees the permanent fix. It would be the correct choice if the question asked which practice restores service during an outage.

A
Change Management
Why it fails: Change Management (now often referred to as Change Enablement in ITIL 4) is primarily concerned with controlling the lifecycle of all changes, ensuring they are assessed, authorized, and implemented with minimal risk to IT services. While a permanent fix identified by Problem Management would eventually be implemented as a change, Change Management's role is not to identify the root cause of incidents or develop the solution itself. Its focus is on the successful deployment and control of pre-defined changes.
B
Service Desk
Why it fails: The Service Desk serves as the single point of contact for users, responsible for logging incidents, fulfilling service requests, and providing initial support. Its primary objective is to restore normal service operation quickly, often by applying known workarounds or escalating to other support teams. However, the Service Desk does not perform in-depth root cause analysis or manage the process of developing and implementing permanent solutions for recurring issues.
C
Problem Management
Problem Management is the practice responsible for reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors. It conducts thorough root cause analysis to understand the underlying issues, coordinates the development of permanent solutions, and ensures their implementation to prevent recurrence, making it the correct practice for identifying root causes and coordinating permanent fixes.
D
Incident Management
Why it fails: Incident Management coordinates the immediate restoration of service through workarounds, but its scope ends once service is restored; it does not own the process of identifying, developing, and deploying a permanent fix. That responsibility belongs to Problem Management, which conducts root cause analysis and manages the known error database to ensure a structural resolution is implemented. Incident Management is tempting because it handles the initial response and coordinates the workaround, so candidates may assume it also oversees the permanent fix. It would be the correct choice if the question asked which practice restores service during an outage.

Question 19mediummultiple choice

A company is redesigning its service desk processes. The team decides to first review existing procedures, metrics, and feedback before making changes. Which ITIL guiding principle is being applied?

Trap 1: Focus on value

This ITIL guiding principle directs organizations to ensure all activities contribute to value for stakeholders, focusing on the desired outcomes. While defining the target value is crucial for setting the objectives of any redesign, it does not specify the initial action of assessing the current operational state of the service desk. The question specifically asks about the starting point for the redesign, which is distinct from defining the value objective.

Trap 2: Progress iteratively with feedback

This principle advocates for organizing work into smaller, manageable iterations, continuously seeking and applying feedback to improve. While vital for the execution and refinement of the service desk process redesign, it does not address the initial step of understanding the current state of the processes before any iterative changes can even begin. It describes the method of progression, not the preliminary assessment.

Trap 3: Keep it simple and practical

This ITIL guiding principle advises designing solutions that are straightforward, easy to understand, and deliver practical outcomes without unnecessary complexity. While crucial for ensuring the effectiveness and usability of the redesigned service desk processes, it does not specify the initial action of reviewing the current operational environment. It guides the nature and quality of the solution, not the preliminary assessment phase.

A
Focus on value
Why it fails: This ITIL guiding principle directs organizations to ensure all activities contribute to value for stakeholders, focusing on the desired outcomes. While defining the target value is crucial for setting the objectives of any redesign, it does not specify the initial action of assessing the current operational state of the service desk. The question specifically asks about the starting point for the redesign, which is distinct from defining the value objective.
B
Progress iteratively with feedback
Why it fails: This principle advocates for organizing work into smaller, manageable iterations, continuously seeking and applying feedback to improve. While vital for the execution and refinement of the service desk process redesign, it does not address the initial step of understanding the current state of the processes before any iterative changes can even begin. It describes the method of progression, not the preliminary assessment.
C
Keep it simple and practical
Why it fails: This ITIL guiding principle advises designing solutions that are straightforward, easy to understand, and deliver practical outcomes without unnecessary complexity. While crucial for ensuring the effectiveness and usability of the redesigned service desk processes, it does not specify the initial action of reviewing the current operational environment. It guides the nature and quality of the solution, not the preliminary assessment phase.
D
Start where you are
This ITIL guiding principle mandates that organizations should not start from a blank slate but rather assess what is already in place. Before redesigning service desk processes, it is essential to understand the current state of existing processes, tools, skills, and services to determine what can be reused or improved upon. This principle directly addresses the necessary initial step of reviewing the current environment and capabilities.

Question 20mediummultiple choice

A company has deployed a new software application that meets all specified requirements (output), but user productivity has decreased because the application is difficult to use. According to ITIL 4, what is this an example of?

Trap 1: A service request

A service request is a routine, pre-defined request from a user for a service offering, such as requesting access to an application or a standard report. The scenario describes a deployed application that isn't achieving its intended business benefit, which is a problem related to value realization or effectiveness, not a routine request for a standard service or information. This situation would typically trigger problem management or service improvement activities, not a service request.

Trap 2: A utility failure

Utility, in ITIL 4, refers to the functionality offered by a service to meet a particular need; it describes what the service 'does' and whether it is 'fit for purpose.' Since the new software application 'meets requirements,' its utility is present and functioning as intended. The issue is not that the application lacks necessary functionality, but rather that the existing functionality, despite meeting requirements, is not translating into the desired positive business outcome.

Trap 3: A warranty failure

Warranty, in ITIL 4, refers to the assurance that a service will meet agreed requirements regarding availability, capacity, security, and continuity; it describes how the service 'performs' and whether it is 'fit for use.' The scenario states the application 'meets requirements' and implies it is working, with no mention of issues like downtime, slow performance, security breaches, or recovery failures. Therefore, the service's warranty aspects appear to be met, making this an incorrect classification for the described problem.

A
A poor outcome despite good output
This option correctly identifies the situation. In ITIL 4, an 'output' is a tangible or intangible deliverable of an activity, such as the new software application itself. An 'outcome' is the result achieved for a stakeholder, often enabled by outputs. The application functions as designed (good output), but if it fails to improve user productivity, it has not delivered the desired positive business result (poor outcome), indicating a failure in value co-creation.
B
A service request
Why it fails: A service request is a routine, pre-defined request from a user for a service offering, such as requesting access to an application or a standard report. The scenario describes a deployed application that isn't achieving its intended business benefit, which is a problem related to value realization or effectiveness, not a routine request for a standard service or information. This situation would typically trigger problem management or service improvement activities, not a service request.
C
A utility failure
Why it fails: Utility, in ITIL 4, refers to the functionality offered by a service to meet a particular need; it describes what the service 'does' and whether it is 'fit for purpose.' Since the new software application 'meets requirements,' its utility is present and functioning as intended. The issue is not that the application lacks necessary functionality, but rather that the existing functionality, despite meeting requirements, is not translating into the desired positive business outcome.
D
A warranty failure
Why it fails: Warranty, in ITIL 4, refers to the assurance that a service will meet agreed requirements regarding availability, capacity, security, and continuity; it describes how the service 'performs' and whether it is 'fit for use.' The scenario states the application 'meets requirements' and implies it is working, with no mention of issues like downtime, slow performance, security breaches, or recovery failures. Therefore, the service's warranty aspects appear to be met, making this an incorrect classification for the described problem.