Free ITIL-4-CREATE-DELIVER-SUPPORT Practice Test Questions and Answers (2026) Practice Questions

The fundamental goal of service management, as emphasized in ITIL 4, is the co-creation of value, which is realized through outcomes. An 'output' is merely a deliverable (e.g., a new report feature), whereas an 'outcome' is the actual result for the stakeholder (e.g., improved sales conversion rates).

For a series of incremental improvements, it is crucial to measure the success of each individual change by the specific outcome it enables. This provides a tight feedback loop to validate that each increment is adding value. Concurrently, the overall success of the entire initiative must be measured by the cumulative impact on the desired business outcome, ensuring the series of changes collectively achieves the strategic goal.

1. Measure individual changes by the output that they create: This is incorrect because it measures activity, not value. Delivering an output does not guarantee it achieves the desired result for the sales staff.

2. Measure the overall success of multiple changes by the output that is created: This is a poor measure of success. A large number of delivered outputs can mask a complete failure to improve the business outcome.

1. AXELOS, ITIL® 4: Create, Deliver and Support (2020), Section 2.1.1, "Value, outcomes, costs, and risks." This section reinforces the core ITIL concept that value is realized through outcomes, not outputs. It states, "An outcome is a result for a stakeholder enabled by one or more outputs." The scenario's goal is to "improve the data," which is an outcome for the sales staff.

2. AXELOS, ITIL® 4: Create, Deliver and Support (2020), Section 4.1.5, "Using value streams to create, deliver, and support services." This section discusses measuring the flow of value. It emphasizes that "the most important metrics are those that reflect the value of the services and products." Measuring outcomes directly reflects this value, whereas measuring outputs does not.

3. AXELOS, ITIL® 4 Foundation, ITIL 4 Edition (2019), Section 2.5.1, "Value, outcomes, costs, and risks." This foundational text clearly defines the distinction: "An output is a tangible or intangible deliverable of an activity," while "An outcome is a result for a stakeholder." The question asks for the best way to measure, which necessitates focusing on the results (outcomes) rather than just the deliverables (outputs).

The statement describes the process of assessing the current organizational landscape, including its culture, maturity, roles, and responsibilities, before planning improvements. This is the core tenet of the "Start where you are" guiding principle. This principle advises against discarding existing methods and structures without proper analysis. Instead, it emphasizes the importance of observing and measuring the current state to leverage existing strengths and gain a clear understanding of the baseline from which to improve. Using tools like value stream mapping and RACI matrices are methods for achieving this objective analysis of the current situation.

B. Focus on value: This principle ensures that all improvement activities are aimed at creating value for stakeholders, which is the ultimate goal, not the specific act of assessing the current state.

C. Keep it simple and practical: This principle guides the design of solutions to be straightforward and effective, which is a subsequent step after the initial assessment described in the statement.

D. Optimize and automate: This principle is about improving efficiency and effectiveness, which can only be properly applied after the current processes and structures are thoroughly understood.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 4.1.1, Organizational structures: This section explicitly states, "When planning to improve organizational structures, it is important to apply the ITIL guiding principles... For instance, the ‘start where you are’ principle reminds us to consider the cultural aspects of the organization... Value stream mapping and RACI matrices can be used to understand current roles and responsibilities." This directly corresponds to the text in the question.

2. AXELOS. (2019). ITIL® 4 Foundation, ITIL 4 Edition. TSO (The Stationery Office).

Section 4.3.1, Start where you are: This section explains the principle: "Do not start from scratch and build something new without considering what is already available to be leveraged... The current state should be investigated and observed directly to make sure it is fully understood." This foundational text supports the application of the principle to assessing existing structures.

The 'shift-left' approach is a core concept in modern service delivery focused on moving activities, particularly testing and quality assurance, earlier in the service value stream or development lifecycle. The primary goal is to find and fix defects as close to the source as possible, which is typically during the development phase. By integrating testing earlier, organizations can reduce the cost of remediation, shorten feedback loops, and improve the overall quality and speed of delivery. This approach contrasts with traditional models where testing is a distinct phase that occurs late in the lifecycle, just before release.

A. Service integration and management (SIAM) is a management methodology for coordinating services across multiple suppliers, not a technique for sequencing development activities.

B. Managing work as tickets is a method for tracking and organizing tasks. It does not inherently influence when those tasks, such as testing, are performed in the lifecycle.

D. Robotic process automation (RPA) is a technology used to automate repetitive, rule-based tasks. While it can be used for test automation, it does not define the timing of testing.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 4.3.1.2, Shift-left approach: "The main idea of the shift-left approach is that the resolution of work is moved closer to the source of the work... In software development, this means that testing is performed earlier in the lifecycle (moving from right to left in a typical waterfall diagram)." This section explicitly defines shift-left as the approach for moving testing earlier.

Glossary, page 218: Defines 'shift-left' as "An approach that moves work closer to its source."

A 'job' is a formal position within an organization's structure assigned to an individual. The ITIL framework distinguishes this from a 'role'. A single person holding one job title, such as 'IT Operations Analyst', may be required to perform several different roles as part of their duties. For example, they might act in the role of an incident resolver, a change implementer, and a problem analyst at different times. This distinction is crucial for building flexible and effective teams where responsibilities are clearly understood beyond just a job title.

A. This describes a historical trend in IT job design, focusing on technical silos, rather than defining what a job is in the modern, role-based context of ITIL 4.

B. This is the official ITIL 4 definition of a 'role', which is a set of responsibilities and authorizations, not a 'job'. A person in one job can have many roles.

D. This statement is conceptually confused. A value stream or service is contributed to by several departments; a job is a position typically held by one person within a department.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 4.1.2.1 'Jobs and roles': "A job is a position within an organization that is assigned to a specific person. As part of their job, a single person may fulfil many different roles." This directly supports option C.

Section 4.1.2.1 'Jobs and roles': "A role is a set of responsibilities, activities, and authorizations granted to a person or team, in a specific context." This directly refutes option B by defining it as a 'role'.

Section 4.1.2.2 'Competencies': Discusses the shift from purely technical competencies (I-shaped) to broader skills (T-shaped), showing that option A is an outdated model, not a core definition.

The 'build versus buy' decision is a fundamental strategic choice in service management and development. It directly involves an organization assessing its internal capabilities against external market offerings. This assessment requires a thorough analysis of internal resources, including the skills, competencies, and availability of staff, as well as financial and technological capacity. These internal factors are then compared with the cost, quality, skills, and availability of external suppliers to determine the most effective and efficient way to acquire a new service or component.

B. Swarming: This is a collaborative technique for managing incidents or problems, focusing on assembling the right internal experts to resolve an issue quickly, not on a strategic sourcing decision.

C. Triage prioritization: This is the process of sorting incoming work (e.g., incidents) based on predefined criteria like impact and urgency, to determine the order in which it will be addressed.

D. Shift-left approach: This is a practice for moving work, such as support or testing, closer to the source or user, typically within the organization, to improve efficiency and user capability.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 4.1.4, Sourcing and managing suppliers: This section explicitly discusses the 'build versus buy' decision. It states, "The decision to use a specific sourcing option depends on the organization’s strategy, the required skills and knowledge, and the available resources... The organization should decide whether it is better to develop the required functionality in-house (‘build’) or to use a service or product from another organization (‘buy’)." This directly links the build vs. buy decision to the consideration of internal skills and resources against external options.

2. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 5.1.3, The shift-left approach: This section defines shift-left as moving work to a more efficient and, where possible, less expensive place. It does not involve the consideration of external resources in the context of a sourcing decision.

Section 5.2.7, Incident management: This section describes swarming as a technique for handling complex incidents by involving multiple stakeholders to work on it from the beginning. It also mentions triage as part of the incident logging and categorization process, focusing on prioritization. Neither concept is centered on the internal vs. external resource evaluation for sourcing.

Understanding a role’s competency profile is a fundamental component of workforce and talent management. The official ITIL 4 guidance specifies that its benefits include identifying the best candidates for a role, defining job requirements, identifying skill gaps to plan professional development, and aligning the organization’s talent strategy with industry models.

The option concerning collaboration with leaders for risk management describes a risk management activity. While having competent personnel is crucial for managing risks, the collaborative process of identifying and managing risks is a separate practice and not a direct purpose or outcome of understanding a competency profile itself.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office). Section 2.2.2, "Professional IT and service management skills and competencies". This section explicitly lists the benefits of understanding a competency profile, which correspond to the other three options.

2. Campion, M. A., Fink, A. A., Ruggeberg, B. J., Carr, L., Phillips, G. M., & Odman, R. B. (2011). Doing competencies well: Best practices in competency modeling. Personnel Psychology, 64(1), 225–262. This academic review outlines the primary applications of competency modeling, such as selection, training, and performance management, which align with the correct uses listed in the question, but does not include collaborative risk management as a direct application. (https://doi.org/10.1111/j.1744-6570.2010.01207.x)

The ITIL 4 framework specifies that a successful continual improvement culture is built upon specific organizational behaviors and values. The official 'Create, Deliver and Support' publication explicitly identifies 'Management by example', 'Building trust', and 'Transparency' as the key elements. These foster an environment of psychological safety and collaboration, which is essential for identifying and implementing improvements. While 'Mitigating risks' is a crucial activity often addressed through improvement, it is considered an outcome or a related practice, not a foundational element of the culture itself.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office). Section 2.4.3, "Continual improvement culture", Page 31. This section states, "The key elements of a continual improvement culture are: Management by example; Building trust; Transparency."

Service Integration and Management (SIAM) is a management methodology for environments with multiple service providers. Its primary function is to integrate these providers to deliver a single, seamless, business-facing service. In the context of ITIL 4, a value stream represents the series of steps an organization undertakes to co-create value with consumers. When multiple suppliers are involved in these steps, SIAM provides the governance and coordination needed to manage their contributions within that single, end-to-end value stream. This ensures that all parties work cohesively towards a common goal, rather than operating in separate, uncoordinated streams.

A. SIAM is not independent; it is an integral part of managing the supplier contributions that constitute activities within a value stream.

B. This is incorrect. SIAM is a complementary methodology that enhances the effectiveness of value streams in a multi-supplier environment.

C. This approach would create silos and defeat the purpose of SIAM, which is to integrate, not segregate, supplier services.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 5.2.6, Page 168: "In a multi-vendor environment, the coordination of all parties involved in a value stream is critical... This is where Service Integration and Management (SIAM) can be useful. SIAM is a management methodology that can be applied in an environment that includes services sourced from a number of service providers." This passage explicitly links SIAM to the coordination of multiple parties within a value stream, directly supporting the correct answer.

Section 2.4, Page 29: This section describes value streams as a series of steps to create and deliver products and services. In a multi-supplier context, these steps are performed by different parties, requiring the integration that SIAM provides.

The provided definition accurately describes Continuous Delivery. In this practice, every change that passes through the automated testing pipeline is considered releasable. The software is always in a state where it can be deployed to production. However, the final step of deploying to the live production environment is a deliberate, manual decision made by the business or development team. This allows organizations to control the timing and frequency of releases based on business needs, even though the technical capability for frequent deployment exists.

A. Continuous deployment: This practice automatically deploys every validated change to production without manual intervention, which contradicts the "deployment decisions are taken case by case" part of the definition.

C. Continuous integration: This is the practice of frequently merging code changes into a central repository and running automated builds and tests, but it does not inherently mean the software is ready for production release.

D. DevOps: This is a broad cultural and professional movement that encompasses CI/CD as key practices, but it is not the specific practice described by the definition.

1. AXELOS. (2020). ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office).

Section 5.2.5, Page 169: The text in the question is a direct quote from this section defining Continuous Delivery: "Continuous delivery is an approach to software development in which software can be released to production at any time. Frequent deployments are possible, but deployment decisions are taken case by case, usually because organizations prefer a slower rate of deployment."

The same section distinguishes this from Continuous Deployment: "Continuous deployment is an approach to software development in which changes to software go through the pipeline and are automatically released into the production environment."

2. Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional.

Chapter 1, Section "What Is Continuous Delivery?", Page 29: The authors state, "The key to continuous delivery is that you can decide to ship your software at any time... The decision to release is a business one." This supports the idea that deployment is a case-by-case business decision, which is the core of the provided definition.

The Agile movement critiques large, infrequent project releases for several core reasons. These include the increased risk and complexity of "big bang" deployments (A), the delay in delivering value to customers (B), and the lack of regular feedback loops which can lead to building the wrong solution (C). These are fundamental arguments for adopting iterative and incremental delivery.

Option D is not a primary reason. It is a convoluted statement describing a consequence—opportunity cost and reduced ability to adapt—rather than a foundational cause for why the traditional model is ineffective. The other options describe the direct, inherent flaws of the large-project model that Agile aims to solve.

A. This is a primary reason. Large, infrequent deployments are high-risk events, making rollbacks difficult and increasing the likelihood of service-impacting failures.

B. This is a core Agile principle. Long cycles mean value is withheld from the customer for extended periods, delaying return on investment and feedback.

C. This is a key criticism of linear (e.g., Waterfall) models. Without regular consumer interaction, the final product may not meet evolving user needs or expectations.

1. AXELOS, ITIL® 4 Specialist: Create, Deliver and Support. TSO (The Stationery Office), 2020.

Section 2.4.2 (Working in an agile way): This section discusses the Agile Manifesto, which prioritizes "early and continuous delivery of valuable software" and "customer collaboration." This directly supports the validity of options B and C as reasons for rejecting traditional models.

Section 5.2.5 (Deployment): This section explains that "Large, infrequent deployments are high-risk events... It is better to deploy small changes frequently, as this reduces the risk of each deployment." This directly supports the validity of option A.

The publication does not frame the argument against large projects in the circular and consequential terms used in option D. The focus is on tangible issues of risk, value delivery, and customer alignment.