ITIL Management Practices practice questions

Service Configuration Management

Why wrong: Service Configuration Management focuses on maintaining accurate and verified information about all configuration items (CIs) that are required to deliver IT services, including their relationships and dependencies. While a service itself might be represented as a CI, this practice primarily deals with the underlying technical components and their interdependencies, not the high-level, user-facing descriptions of services or how they are presented in a catalog. Its scope is the technical infrastructure and its configuration, not service definition for consumers.

Service Level Management

Why wrong: Service Level Management sets clear business-based targets for service performance and ensures that the organization meets these targets through ongoing monitoring and reporting against agreed-upon metrics. This practice defines the agreed-upon quality and performance parameters for services, often documented in Service Level Agreements (SLAs), but it does not create or manage the comprehensive descriptions of the services themselves for a catalog. Its primary focus is on performance, agreement, and the ongoing management of service quality, not the initial definition or publication of service offerings.

IT Asset Management

Why wrong: IT Asset Management is the practice of planning and managing the full lifecycle of all IT assets, from acquisition through disposal, to maximize value, control costs, and support service delivery. This includes physical hardware, software licenses, and network components. While these assets are crucial for delivering services, IT Asset Management is concerned with their financial, contractual, and inventory aspects, not with defining or publishing the descriptions of the services that utilize these assets for consumer consumption.

Problem Management

Why wrong: Problem Management focuses on identifying and resolving the root causes of incidents to prevent recurrence, thereby improving overall service stability. While it contributes to long-term resilience, its primary scope is reactive analysis and systemic improvement, not the real-time detection, immediate containment, or rapid response required for active security events or breaches.

Availability Management

Why wrong: Availability Management ensures that services and components are available to meet agreed-upon service level targets, focusing on uptime, resilience, and recovery capabilities. Its activities involve planning, monitoring, and maintaining the operational state of services. This practice is concerned with the operational presence and operability of IT services, not the specialized detection, analysis, or mitigation of malicious security threats.

Incident Management

Why wrong: Incident Management aims to restore normal service operation as quickly as possible and minimize adverse business impact, handling all types of service disruptions. While it processes security-related incidents, it typically focuses on immediate service restoration rather than the specialized aspects of security event detection, forensic analysis, threat intelligence, or strategic containment and eradication specific to cyberattacks.

Service Level Management

Why wrong: 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 wrong: 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 wrong: 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.

Deployment Management

Why wrong: Deployment Management is the ITIL practice focused on moving new or changed hardware, software, documentation, processes, or any other component to live environments. While crucial for implementing changes, it operates after a change has been assessed, authorized, and designed. This practice does not encompass the initial evaluation, risk assessment, or formal approval required for organizational changes themselves.

Release Management

Why wrong: Release Management focuses on making new and changed services and features available for use, typically by grouping multiple authorized changes into a single release. Its scope is the planning, scheduling, and control of the entire release lifecycle, ensuring that a set of changes can be deployed together. However, it does not perform the initial assessment, justification, or authorization of the individual changes themselves, which must occur prior to release packaging.

Transition Planning and Support

Why wrong: The Transition Planning and Support practice is primarily concerned with planning and coordinating the resources and activities required to transition new or changed services into production. It ensures that all aspects of a service transition are managed effectively, including stakeholder communication and readiness. While it oversees the broader transition, it does not provide the specific mechanism for the formal assessment, authorization, or scheduling of individual changes that constitute the transition.

Define and agree on service level targets with customers

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Close the incident as it is resolved and focus on other issues

Why wrong: While an incident might be temporarily resolved, closing it without proper analysis, especially when slow transactions indicate a recurring performance issue, is contrary to ITIL's Problem Management practice. This approach neglects the opportunity to identify and address the root cause, leading to potential service degradation recurrence and increased future incident volumes. Effective incident management often feeds into problem management to prevent future disruptions.

Increase the response time target to 99%

Why wrong: Increasing the response time target to 99% would not inherently improve the actual performance of the service. Instead, it would merely set a more ambitious goal without addressing the operational deficiencies causing slow transactions. Such an action could lead to increased target misses and frustration, rather than driving tangible improvements in service delivery or customer experience.

Adjust the availability target to 99.95%

Why wrong: Adjusting the availability target to 99.95% is an inappropriate response because the problem described (slow transactions) relates to service performance and response time, not necessarily service availability. The exhibit likely indicates availability is already meeting or exceeding its current target. Modifying an unrelated and already satisfactory metric target would not address the core issue of poor transaction speed or user experience.

Incident Management

Why wrong: 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 wrong: 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 wrong: 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.

Service Continuity Management

Why wrong: 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.

Capacity and Performance Management

Why wrong: 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.

Service Catalog Management

Why wrong: 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.

Deployment Management

Why wrong: Deployment Management is the practice responsible for moving new or changed hardware, software, documentation, processes, or any other component to live environments. Its primary focus is on the technical steps of deployment, such as scheduling, packaging, and installation, ensuring minimal disruption during the transition. This practice does not encompass the governance or authorization process that determines if a change should proceed, which is crucial for preventing unauthorized or risky modifications.

Release Management

Why wrong: Release Management focuses on making new and changed services and features available for use, often by grouping multiple changes into a single release package. This practice ensures that a coherent set of service components is delivered together, tested, and deployed to users. While it manages the deployment of these packages, its primary role is not the individual authorization and review of each underlying change request, nor does it directly govern the decision to implement a specific change.

Service Validation and Testing

Why wrong: Service Validation and Testing is the practice of ensuring that new or changed services, products, or components meet defined requirements and expectations, and that they will function as expected in the target environment. This involves rigorous testing across various stages, including functional, performance, and user acceptance testing, to verify the quality and fitness for purpose. While critical for quality assurance, this practice focuses on verifying the outcome of a change, not on the initial decision-making and authorization process that governs whether a change should be implemented at all.

Problem Management

Why wrong: 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.

Service Desk

Why wrong: 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.

Event Management

Why wrong: 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.

Manage the performance of suppliers to meet business outcomes

Why wrong: 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 wrong: 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 wrong: 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.

Expedite the change request by requesting an emergency change approval from the CAB chair

Why wrong: Expediting an emergency change request, while seemingly fast, still involves formal assessment, authorization by an Emergency Change Advisory Board (ECAB), and implementation steps. This structured process, even when expedited, may not be immediate enough to prevent significant revenue loss during critical peak hours, as the chair or necessary technical resources might not be instantly available to approve and execute the change. The overhead of the change process itself can introduce delays.

Conduct a root cause analysis and document the problem in the known error database

Why wrong: Conducting a root cause analysis (RCA) and documenting the problem are essential activities within Problem Management, aimed at understanding the underlying cause of incidents and preventing future occurrences. However, these investigative steps do not provide an immediate solution to an active service degradation causing revenue loss. Prioritizing RCA over a workaround would prolong the service outage and financial impact, as it's a long-term prevention strategy, not an immediate restoration tactic.

Increase the priority of all related incidents to ensure faster response from the service desk

Why wrong: Increasing the priority of related incidents primarily signals urgency to the service desk and support teams, potentially leading to faster attention. However, simply elevating priority does not inherently provide a technical solution or a workaround to the underlying performance issue. Without a clear path to resolution or an effective workaround, the service degradation and associated revenue loss would persist, regardless of how quickly the service desk acknowledges the incident.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Escalate to the change advisory board (CAB) for a new approval.

Why wrong: Escalating this change to the Change Advisory Board (CAB) for a new approval is an unnecessary procedural step and introduces undue delay. The CAB is typically involved in assessing higher-risk or complex normal changes requiring broader stakeholder input, but the IT manager is clearly identified as the specific change authority for this particular change. Given the risk is still considered low, involving the CAB would add bureaucratic overhead without providing additional value beyond what the designated authority can provide.

Proceed with the change as planned, since the change is already approved.

Why wrong: Proceeding with the change as originally planned, despite discovering a new significant impact like a mandatory reboot, is highly irresponsible and could lead to unexpected service disruption. The initial approval was based on incomplete information, as it did not account for the potential outage. Implementing the change without re-evaluation violates the core principle of effective change control, which requires understanding and managing all known risks and impacts before deployment to prevent negative business consequences.

Cancel the change and request a new one with updated information.

Why wrong: Canceling the existing change and requesting an entirely new one with updated information is an overly drastic and inefficient response to new information. While the impact profile has changed, the fundamental need for the security patch remains valid and critical. This approach introduces unnecessary administrative overhead, delays the crucial security update, and wastes the effort already invested in the initial planning and approval stages. A more agile and appropriate action is to reassess the existing change with the designated authority.

Service Owner: Authorizes changes to services and service components.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Problem

Why wrong: A Problem, in ITIL 4, is defined as a cause, or potential cause, of one or more Incidents. Its management focuses on identifying the root cause of recurring or significant incidents to prevent future occurrences. Requesting a new laptop for a new employee is a standard, planned operational activity, not an investigation into an underlying cause of service disruption or degradation.

Emergency change

Why wrong: An Emergency Change is a type of Change that must be implemented as soon as possible, typically to resolve an Incident or implement a security fix. These changes bypass some normal change assessment and authorization steps due to their critical nature. Requesting a new laptop for a new employee is a planned activity with no inherent urgency or immediate impact on service restoration, thus not qualifying as an emergency change.

Incident

Why wrong: An Incident is defined as an unplanned interruption to a service or a reduction in the quality of a service. Its primary objective is to restore normal service operation as quickly as possible. Requesting a new laptop for a new employee is a proactive, planned activity to enable service for a new user, not a reaction to an unexpected service disruption or failure.

What is the vision? → Where do we want to be? → Where are we now? → How do we get there? → Take action → Did we get there? → How do we keep the momentum going?

Why wrong: This sequence is incorrect because it places 'Where do we want to be?' before 'Where are we now?'. In the ITIL Continual Improvement Model, it is crucial to first understand the current baseline and assess the existing state before defining the specific, measurable targets for the desired future state. Without a clear understanding of the starting point, setting realistic and achievable objectives for the destination becomes challenging.

Where are we now? → What is the vision? → Where do we want to be? → How do we get there? → Take action → Did we get there? → How do we keep the momentum going?

Why wrong: This sequence is incorrect because it begins with 'Where are we now?' instead of 'What is the vision?'. The ITIL Continual Improvement Model explicitly starts by establishing a clear vision, which provides the overarching strategic direction and purpose for all subsequent improvement activities. Defining the desired future state is a fundamental prerequisite before assessing the current situation or planning any initiatives.

What is the vision? → Where are we now? → How do we get there? → Where do we want to be? → Take action → Did we get there? → How do we keep the momentum going?

Why wrong: This sequence is incorrect because it places 'How do we get there?' before 'Where do we want to be?'. According to the ITIL Continual Improvement Model, one must clearly define the specific, measurable desired future state (the destination) before developing a plan for how to achieve it. Attempting to formulate a plan without a well-defined target can lead to misdirected efforts and inefficient resource allocation.