ITIL Management Practices practice questions

Service Level Management

Why it fails: Service Level Management (SLM) primarily focuses on setting clear, measurable service level targets and ensuring that the organization meets these agreed-upon levels with customers. While SLM uses monitoring data to report on service performance against these targets, it does not involve the operational activity of implementing the monitoring tools themselves or defining the granular technical thresholds that trigger alerts. Its role is strategic and tactical in defining expectations and reporting, not operational tool deployment.

Availability Management

Why it fails: Availability Management is specifically concerned with ensuring that services and components are available when needed, focusing on aspects like reliability, maintainability, serviceability, and resilience. While a new monitoring tool will certainly contribute to measuring and improving availability, its implementation for general performance and operational threshold setting encompasses a much broader scope than just availability. This practice defines availability requirements and designs for resilience, rather than deploying the general monitoring infrastructure.

Service Desk

Why it fails: The Service Desk serves as the single point of contact between the service provider and its users, primarily handling incidents, service requests, and providing information. Its core function is to restore normal service operation as quickly as possible and fulfill user requests, which are typically reactive or transactional activities. Implementing a new monitoring tool, which is a proactive operational capability for infrastructure and service health, is entirely outside the scope of the Service Desk's responsibilities.

Define and agree on service level targets with customers

Why it fails: This statement describes a primary objective of Service Level Management, not Supplier Management. Service Level Management is responsible for establishing, monitoring, and reporting on service level agreements (SLAs) with customers, ensuring that agreed-upon service quality and performance targets are met from the customer's perspective. While Supplier Management might contribute to underlying operational level agreements (OLAs) or contracts with suppliers that support these SLAs, it does not directly define customer-facing service level targets.

Manage the financial assets of the organization

Why it fails: Managing the financial assets of the organization, including investments, cash flow, and overall financial health, falls under the purview of Financial Management for IT services. Supplier Management focuses specifically on the contractual and performance aspects of external providers, ensuring value for money from supplier contracts and managing associated risks, but it does not encompass the broader financial asset management responsibilities of the organization.

Manage the service desk to handle supplier-related incidents

Why it fails: The management and operation of the service desk, including its processes for handling incidents, service requests, and communication with users, is a core function of the Service Desk practice. While the service desk may log and escalate incidents that involve suppliers, its overall management and operational responsibility do not fall under Supplier Management, which focuses on the strategic relationship and performance of external providers.

Escalate the problem to a higher priority

Why it fails: Escalating the problem to a higher priority is not the appropriate next action. Priority escalation is a mechanism to ensure resources are allocated based on impact and urgency, but it does not inherently solve the problem itself. Without first analyzing the incidents to understand the root cause, simply increasing priority is an administrative action that offers no technical solution and may misdirect resources if the problem's current priority is already appropriate for its known impact.

Close the problem record as the incidents are resolved

Why it fails: Closing the problem record merely because the associated incidents are resolved is a critical mistake in Problem Management. Incident resolution focuses on restoring service functionality, whereas problem resolution aims to eliminate the underlying cause. Prematurely closing the problem record without conducting a root cause analysis ensures that the problem remains unaddressed, making future recurrences of similar incidents highly probable and undermining the core purpose of Problem Management.

Implement a permanent solution immediately

Why it fails: Implementing a permanent solution immediately is an ill-advised action without proper analysis. A permanent solution requires a thorough understanding of the root cause, careful design, testing, and often a formal change process to ensure its effectiveness and prevent unintended side effects. Rushing to implement a fix without this due diligence risks deploying an incorrect or incomplete solution, potentially introducing new issues or failing to prevent the problem's recurrence.

Incident Management

Why it fails: Incident Management is primarily focused on restoring normal service operation as quickly as possible following an unplanned interruption or reduction in service quality. Its reactive nature means it addresses existing incidents rather than proactively preventing them through user education or training. While incident data can inform problem management for prevention, the practice itself is about resolution.

Change Enablement

Why it fails: Change Enablement is the practice of ensuring that changes are assessed, approved, and implemented in a controlled manner, maximizing successful outcomes while minimizing risk to services. Its scope is specifically limited to managing the lifecycle of changes to IT services, infrastructure, or applications. It does not encompass the broader function of user education aimed at preventing operational incidents.

Service Request Management

Why it fails: Service Request Management focuses on fulfilling predefined, routine requests from users for services, information, or standard changes. This practice is designed for efficiency in delivering known outcomes, such as providing access, software installations, or information requests, through a structured process. It is not designed to deliver general user education or training programs intended to proactively reduce incident volumes.

Manage the performance of suppliers to meet business outcomes

Why it fails: While Supplier Management oversees the contractual aspects and overall relationship, the direct management and measurement of supplier performance against specific service level targets and overall business outcomes is primarily the responsibility of the Service Level Management practice. Supplier Management ensures the contractual framework supports these performance expectations, but SLM drives the day-to-day monitoring and reporting against agreed service levels.

Define and agree on service level targets with suppliers

Why it fails: Defining and agreeing upon specific service level targets with suppliers, particularly those directly impacting customer experience, is a core activity of the Service Level Management practice. Supplier Management then ensures that the contractual agreements with external providers accurately reflect and support these defined service level requirements, rather than originating them.

Ensure that suppliers are audited regularly

Why it fails: Regular auditing is a specific activity or control mechanism, not a primary purpose of the Supplier Management practice itself. While Supplier Management may initiate or utilize audits to verify compliance, assess risk, or ensure adherence to contractual terms, its overarching purpose is broader, focusing on the holistic management of supplier relationships and value delivery.

Accept the current recovery plan as the risk is low and focus on improving the backup process

Why it fails: Accepting the current recovery plan is unacceptable because it explicitly fails to meet the established Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements. In a financial institution, non-compliance with these critical metrics indicates a high, not low, risk exposure to significant data loss and prolonged service disruption. Focusing solely on backup frequency does not resolve the fundamental inability to restore services within the required RTO.

Implement asynchronous replication with a 5-minute lag and test if the RPO can be met

Why it fails: Implementing asynchronous replication with a 5-minute lag introduces an inherent risk of data loss up to that 5-minute window, which may not satisfy a stringent Recovery Point Objective (RPO) if the target is less than or equal to 5 minutes. While it can reduce data loss compared to backups, it does not guarantee a near-zero RPO like synchronous replication. This option also fails to explicitly address the Recovery Time Objective (RTO), as the speed of recovery depends on the failover process, not just the replication method.

Increase the backup frequency to every 5 minutes and test the restore process to ensure it meets the RTO

Why it fails: While increasing backup frequency to every 5 minutes could potentially meet a 5-minute Recovery Point Objective (RPO) by reducing the maximum data loss window, it fundamentally fails to address the Recovery Time Objective (RTO). The existing restore process, which takes 3 hours, remains unchanged. Therefore, if the required RTO is significantly shorter than 3 hours, this solution will not enable the rapid restoration of services, rendering it insufficient for critical business continuity requirements.

All changes must be approved by a change advisory board (CAB).

Why it fails: The statement that all changes must be approved by a Change Advisory Board (CAB) is incorrect because ITIL 4 recognizes different types of changes with varying authorization requirements. For instance, standard changes are pre-authorized and do not require individual CAB approval, as their risks are well understood. Similarly, emergency changes often bypass a full CAB review due to their urgent nature, relying on a streamlined approval process.

The change schedule is used to authorize changes.

Why it fails: The change schedule serves as a critical planning and communication tool within the change enablement practice, detailing planned changes and their timings. Its primary function is to help manage conflicts, identify potential clashes, and inform stakeholders about upcoming modifications. However, the change schedule itself does not confer authorization; instead, it reflects changes that have already been authorized through the appropriate change authority.

Normal changes can be implemented without authorization if they are low risk.

Why it fails: Normal changes, by definition, follow a standard workflow that includes assessment, authorization, and implementation steps, regardless of their perceived risk level. Even if a normal change is deemed low risk, it still requires formal authorization to ensure proper governance, resource allocation, and adherence to organizational policies. Bypassing authorization for any normal change would undermine control and introduce unnecessary risk into the service ecosystem.

Service Owner: Authorizes changes to services and service components.

Why it fails: This statement is incorrect because authorizing changes to services and service components is primarily the responsibility of the Change Authority (or Change Enablement practice in ITIL 4), not the Service Owner. The Change Authority focuses on assessing risks, impacts, and benefits across the entire IT estate to ensure changes are authorized appropriately and do not negatively affect services. While a Service Owner may be consulted, the ultimate authorization power rests with the designated Change Authority.

Process Owner: Manages the service desk team and ensures incidents and service requests are handled.

Why it fails: This statement is incorrect as managing the service desk team and ensuring incidents and service requests are handled describes the responsibilities of a Service Desk Manager, not a Process Owner. A Process Owner focuses on the design and performance of a specific process (e.g., the Incident Management process), whereas a Service Desk Manager is an operational role responsible for the day-to-day supervision of the service desk staff, their performance, and the direct handling of customer interactions and issues.

To identify the root cause of incidents

Why it fails: Identifying the root cause of incidents falls under the scope of Problem Management, not Incident Management. While incidents are symptoms of underlying problems, the primary objective of Incident Management is immediate service restoration, focusing on workarounds or quick fixes to minimize business impact. Problem Management then systematically investigates to prevent recurrence, distinguishing its proactive and analytical nature from Incident Management's reactive stance.

To negotiate and agree on service level targets

Why it fails: Negotiating and agreeing on service level targets is a core activity of the Service Level Management practice, which defines the expected quality and availability of services. Incident Management, conversely, is a reactive practice that responds when these agreed service levels are breached or threatened by an unplanned disruption. Its role is to mitigate the impact of such breaches, not to establish the targets themselves, which are set through collaborative discussions with customers.

To assess and authorize changes to services

Why it fails: Assessing and authorizing changes to services is the explicit purpose of the Change Enablement practice, ensuring that all modifications are evaluated for risk and potential impact before implementation. Incident Management, by contrast, deals with unplanned interruptions to service, not planned alterations. While an incident might trigger an emergency change, the overarching process for managing all changes, including their assessment and authorization, resides within Change Enablement to maintain service stability.

Customer Satisfaction (CSAT) and Mean Time to Respond

Why it fails: 'Mean Time to Respond' is not a primary, standard ITIL metric for evaluating the effectiveness of service request fulfillment, such as a password reset. While response time is an operational indicator, ITIL 4 places greater emphasis on metrics that reflect actual resolution, value delivery, and customer experience. Focusing solely on response time without considering resolution efficiency can lead to misleading performance assessments.

Mean Time Between Failures (MTBF) and Customer Satisfaction (CSAT)

Why it fails: Mean Time Between Failures (MTBF) is a reliability metric used to measure the average operational time between successive failures of a system, component, or service. A password reset is a routine service request fulfillment activity, not an incident or failure of an IT component. Therefore, MTBF is entirely irrelevant to assessing the efficiency or effectiveness of handling such a request.

Mean Time to Resolve (MTTR) and First Call Resolution (FCR)

Why it fails: Mean Time to Resolve (MTTR) is primarily an incident management metric, measuring the average time taken to restore a service after an incident has occurred. A password reset is typically categorized as a service request, which is a standard request for service fulfillment, not an incident requiring service restoration. Applying MTTR to service requests misaligns the metric with the nature of the activity.

Incident

Why it fails: An incident represents an unplanned interruption to a service or a reduction in the quality of a service. While high CPU usage is a critical event, it only becomes an incident if it actively causes a service disruption or degradation, such as applications becoming unresponsive. At this stage, the high CPU usage is a symptom or a potential cause, not the incident itself.

Informational event

Why it fails: An informational event is a routine occurrence that confirms the normal operation of a service or component, requiring no immediate action or intervention. These events are typically logged for auditing, trend analysis, or to confirm successful processes, such as a system startup or a successful backup. High CPU usage, by its nature, indicates an abnormal condition that demands attention, thus it cannot be classified as merely informational.

Warning event

Why it fails: A warning event indicates that a predefined threshold is being approached, signaling a potential future problem if current conditions persist, but the critical limit has not yet been breached. For instance, a warning might be triggered when CPU usage reaches 80% if the critical threshold is 90%. The question implies the CPU usage has already exceeded a level requiring action, moving beyond a mere warning state.

To authorize and schedule changes

Why it fails: Authorizing and scheduling changes is a core activity within the Change Enablement practice, not the primary role of the service desk. Change Enablement focuses on maximizing the number of successful service and product changes by ensuring risks are properly assessed, changes are approved, and their implementation is coordinated. While the service desk might log a request for change, the formal authorization and scheduling process falls under a distinct practice designed for managing the lifecycle of changes.

To investigate the root cause of incidents

Why it fails: Investigating the root cause of incidents is a primary objective of the Problem Management practice, which aims to reduce the likelihood and impact of incidents by identifying and resolving their underlying causes. While the service desk is responsible for logging and resolving incidents quickly, their focus is on restoring normal service operation as soon as possible. Problem Management takes a more proactive and analytical approach to prevent recurrence, distinguishing it from the immediate incident resolution focus of the service desk.

To negotiate service level agreements

Why it fails: Negotiating service level agreements (SLAs) is a key responsibility of the Service Level Management practice, which ensures that all services meet agreed-upon performance targets. This practice involves defining, documenting, and agreeing on service levels with customers, and then monitoring and reporting on service performance against these agreements. The service desk, while interacting with users, does not typically engage in the strategic negotiation and formalization of service level commitments, which requires a broader understanding of service capabilities and customer expectations.

To restore normal service operation as quickly as possible

Why it fails: Restoring normal service operation as quickly as possible is the core purpose of Incident Management, not Problem Management. Incident Management focuses on the immediate resolution of service disruptions to minimize business impact, often using temporary workarounds to get services back online. In contrast, Problem Management delves deeper to understand *why* the incident occurred, aiming for long-term prevention rather than just rapid restoration of service.

To assess and authorize changes

Why it fails: The assessment and authorization of changes are fundamental activities within the Change Enablement practice, which ensures that all changes are properly evaluated for risk and benefit before implementation. While Problem Management might identify the need for a change to resolve a known error, it does not perform the actual assessment, planning, or authorization of that change. Its role is to identify the problem and propose a solution, which then feeds into the Change Enablement process.

To fulfil service requests

Why it fails: Fulfilling service requests is the distinct purpose of the Service Request Management practice, which handles pre-defined, routine requests from users for information, standard services, or access to IT resources. Problem Management, conversely, deals with unexpected service disruptions and their underlying causes, which are not routine requests. These two practices address entirely different types of user and service needs within the IT environment.

To manage the lifecycle of all changes

Why it fails: This statement describes the primary purpose of the Change Enablement practice, which focuses on maximizing the number of successful service and product changes by ensuring risks are properly assessed, authorizing changes, and managing the change schedule. Its objective is to enable beneficial changes while minimizing disruption, a distinct goal from reacting to and resolving service outages.

To identify the root cause of incidents

Why it fails: Identifying the root cause of incidents and preventing their recurrence is the core objective of the Problem Management practice. While incident management focuses on immediate service restoration, problem management takes a more analytical approach to understand underlying causes, develop permanent solutions, and reduce the likelihood and impact of future incidents.

To negotiate and agree on service level targets

Why it fails: Negotiating, agreeing, and managing service level targets with customers is the primary function of the Service Level Management practice. This practice ensures that the organization's services meet agreed-upon performance expectations and that relationships with customers are effectively managed, which is distinct from the operational task of resolving service disruptions.

Problem Identification

Why it fails: Problem Identification is the initial stage of Problem Management, focused on detecting and logging potential problems, often triggered by recurring incidents, monitoring alerts, or service desk observations. This phase aims to recognize that an underlying issue exists and to initiate an investigation. However, it does not involve the in-depth root cause analysis required to identify a 'known error'; that detailed analysis is performed in the subsequent Problem Control phase.

Error Control

Why it fails: Error Control is a subsequent phase within Problem Management, primarily focused on managing and tracking known errors and their associated workarounds after their root cause has been identified. It involves monitoring the progress of permanent solutions and ensuring that workarounds are effective and documented for use by Incident Management. The initial identification of a known error, through root cause analysis, occurs prior to this phase.

Incident Management

Why it fails: Incident Management is a distinct ITIL practice dedicated to restoring normal service operation as quickly as possible following an unplanned interruption or reduction in service quality. Its primary objective is to minimize the business impact of incidents through rapid resolution or effective workarounds. It does not involve the detailed, investigative root cause analysis required to identify a known error; that is the responsibility of Problem Management.

Conduct a risk assessment

Why it fails: While risk management is an important consideration throughout various ITIL practices and activities, "Conduct a risk assessment" is not identified as a distinct, standalone key activity or step within the ITIL Continual Improvement Model. Risks are typically considered as part of planning and executing improvements, but not as a separate, named phase of the model itself.

Create a problem record

Why it fails: Creating a problem record is a specific activity performed within the ITIL Problem Management practice, which focuses on reducing the likelihood and impact of incidents by identifying and resolving the root causes of problems. It is not a general key activity or a distinct step within the overarching ITIL Continual Improvement Model, which addresses broader organizational improvement initiatives.

To find the root cause of incidents

Why it fails: Incident Management's primary focus is on the immediate restoration of service, not on identifying the underlying cause of the disruption. Root cause analysis is a distinct objective of Problem Management, which aims to prevent recurrence of incidents by understanding and addressing their fundamental causes, often through a more detailed and less time-critical investigation. This proactive approach ensures long-term stability rather than just immediate fixes.

To monitor and manage events throughout their lifecycle

Why it fails: While incidents often trigger events, and events can indicate potential or actual incidents, the practice of Monitoring and Event Management is specifically designed to systematically observe services and service components, recording and reporting selected changes of state. Its purpose is to identify, categorize, and respond to events, which may or may not escalate to incidents, throughout their entire lifecycle, providing early warnings and insights into service health.

To manage the lifecycle of all changes

Why it fails: Incident Management is concerned with unplanned interruptions to service, whereas managing the lifecycle of all changes, whether standard, normal, or emergency, falls under the Change Enablement practice. Change Enablement ensures that changes are assessed, authorized, and implemented in a controlled manner, minimizing risk and maximizing value, which is a proactive, rather than reactive, service management activity focused on planned modifications.

Inform the customer that it is a known error

Why it fails: An incident is an unplanned interruption or reduction in service quality. A 'known error' in ITIL is a problem that has been successfully diagnosed, and for which a workaround or permanent solution has been identified. At the initial report of an incident, the service desk analyst's first action is to log it, not to immediately declare it a known error, as problem analysis to identify known errors typically occurs after incidents are logged and potentially resolved. This action is premature and incorrect as a first response.

Submit a change request

Why it fails: A change request, or 'request for change,' is a formal proposal for an alteration of a service, product, or system, initiated to implement improvements, resolve problems permanently, or adapt to new requirements. It follows a structured change control process, which is distinct from the immediate response needed for an incident. When users cannot access a service, the priority is to restore service as quickly as possible, which begins with logging the incident, not by initiating a formal change.

Escalate to Problem Management

Why it fails: Problem Management aims to reduce the likelihood and impact of incidents by identifying actual and potential causes, and by managing workarounds and known errors. Its focus is on root cause analysis and prevention, which typically occurs after an incident has been logged and potentially resolved, or when a trend of recurring incidents indicates an underlying problem. Immediately escalating a single reported service interruption to Problem Management as the first step is premature; the initial focus is on restoring service via incident management.

Deployment Management is part of Release Management

Why it fails: While closely related and often coordinated, Release Management and Deployment Management are distinct ITIL practices. Release Management focuses on making new or changed services and features available for use, encompassing planning, building, testing, and assembling release components into a deployable package. Deployment Management, conversely, specifically handles the actual movement of these validated components into live environments, ensuring their successful installation and integration.

There is no difference

Why it fails: Stating there is no difference between Release Management and Deployment Management is incorrect, as they are fundamentally distinct ITIL practices with unique objectives and activities. Release Management is concerned with the overall process of making new or changed services available for use, including planning, building, and comprehensive testing of a release. Deployment Management, however, specifically focuses on the technical activities required to move those validated components into the live operational environment.

Deployment Management is only for hardware

Why it fails: The assertion that Deployment Management is solely for hardware is inaccurate within the ITIL 4 framework. Deployment Management is a comprehensive practice that applies to all types of service components, including software applications, infrastructure configurations, documentation, and even updated processes. Its scope extends to ensuring the successful installation and integration of any new or changed element required for a service to function effectively in a live environment.

Informational

Why it fails: While "Informational" is indeed a recognized event type in ITIL monitoring, representing routine operations or status changes that do not require action, it is not one of the two types specifically requested in this question's context, which typically focuses on events requiring intervention. Informational events are logged for audit trails or trend analysis and signify normal system behavior, contrasting with events that signal deviations from expected performance.

Exception

Why it fails: Incorrect: This option is a duplicate of Exception (Option A), and while Exception is valid, selecting this duplicate would not change the set of types chosen. The correct answer should include only one instance of Exception along with Warning.

Emergency

Why it fails: "Emergency" is not classified as an event type within ITIL's monitoring and event management practice. Instead, "Emergency" refers to a specific type of change model, typically used for urgent changes that must be implemented as soon as possible, often to resolve a major incident or implement a critical security patch. It describes a change's urgency and process, not a system's operational status or a detected occurrence.

Standard

Why it fails: "Standard" is incorrectly identified as an event type. In ITIL, a Standard Change is a pre-authorized, low-risk, frequently occurring change that is well-understood and can be implemented without additional authorization, following a defined procedure. It is a category within change management, distinct from the types of events that monitoring tools detect and report regarding system behavior or performance.