Create, Deliver and Support practice questions

Teams should prioritize 'Work in Progress' to maximize individual productivity.

Why it fails: Prioritizing high work-in-progress levels often leads to bottlenecks and context switching, which decreases overall system throughput. ITIL 4 advocates for limiting work-in-progress to ensure that tasks move efficiently through the value stream to completion, thereby focusing on system-level performance rather than just individual output metrics.

Work management should be strictly centralized to ensure top-down control.

Why it fails: ITIL 4 emphasizes empowerment and decentralized decision-making to increase agility. While governance is necessary, strictly centralized control often creates delays and stifles the responsiveness required to address complex customer needs. Effective teams manage their own work within clear boundaries to ensure rapid and high-quality value delivery.

Documentation should always precede the execution of any work.

Why it fails: Rigid documentation requirements often create unnecessary waste and inhibit the speed of delivery. ITIL 4 promotes 'just enough' documentation that supports the value stream without becoming a barrier to progress. The focus should remain on value creation rather than strictly adhering to burdensome, pre-execution administrative documentation processes.

Deployment Management

Why it fails: While this policy governs deployments, the specific requirement for peer review and testing is a governance control defined by Change Enablement. Deployment Management is the mechanism that executes the task, but the policy logic itself is driven by the risk management framework established by Change Enablement.

Service Level Management

Why it fails: Service Level Management focuses on defining and monitoring service performance targets. While a deployment failure might affect performance, this JSON policy is about procedural control over changes, not about setting or measuring performance targets for the service itself, making this an incorrect classification of the policy's purpose.

Problem Management

Why it fails: Problem Management focuses on identifying root causes and managing known errors. While testing might be part of a permanent solution, the policy configuration provided is a preventative control for changes, not an investigative or root-cause analysis process for existing system failures.

The incident priority was incorrectly categorized by the system.

Why it fails: There is no evidence in the log to suggest a categorization error. The delay is specifically linked to the ticket remaining 'Unassigned.' Whether the priority was correct or not, the lack of assignment is the direct operational failure point leading to the SLA breach, not the priority logic itself.

The support team was not available due to the 24/7 support hours.

Why it fails: The policy explicitly states '24/7' support hours, so availability should not be an issue. The problem is not the lack of staff, but the lack of an assignment process. The team exists, but the ticket failed to reach them, pointing to a workflow issue, not a staffing issue.

The SLA target of 15 minutes is unrealistic for premium services.

Why it fails: The feasibility of the SLA is irrelevant to the immediate cause of the failure. Even if the SLA were aggressive, the primary failure was the lack of any assignment. The team cannot attempt to meet a target if the work remains stagnant in an unassigned state within the queue.

Swarming relies on a tiered support structure to escalate issues based on seniority.

Why it fails: Swarming explicitly rejects the tiered support structure in favor of a flat, collaborative model. Hierarchical escalation creates delays and transfers responsibility, whereas swarming brings the right people to the issue immediately, regardless of their rank, to focus on restoration rather than administrative ticket routing and queue management.

It focuses on maximizing individual specialist utilization rates.

Why it fails: Swarming prioritizes incident resolution speed over individual utilization metrics. While traditional models might track how busy a specific technician is, swarming prioritizes the 'customer value' outcome. Focusing on utilization rates often leads to suboptimal resolution times and prevents the fluid cooperation required to solve complex, high-impact service interruptions.

It is best suited for simple, high-volume service requests that require automation.

Why it fails: Swarming is designed for complex, non-standard, or high-impact incidents that require human judgment. Simple, high-volume requests are better handled through self-service portals, automation, or standard operating procedures. Applying swarming to simple tickets would be an inefficient use of valuable, high-level technical expertise that is needed elsewhere.

Problem Management, by initiating a formal Root Cause Analysis for every minor error.

Why it fails: While Problem Management is essential, performing a formal Root Cause Analysis for every minor incident is inefficient and resource-heavy. ITIL 4 encourages a risk-based approach; formal RCA should be reserved for high-impact or systemic issues, while minor recurring errors should be managed through knowledge base updates and automated fixes.

Change Enablement, by restricting access to the middleware service.

Why it fails: Restricting access to a service that is clearly required for operations is counterproductive. Change Enablement should focus on facilitating safe, reliable changes, not imposing arbitrary restrictions that degrade service functionality. The issue here is a technical failure in the middleware layer, not a governance or access control problem.

Service Level Management, by renegotiating SLAs with the service provider.

Why it fails: Renegotiating SLAs does not address the underlying technical issue demonstrated in the log. Service Level Management is about managing expectations and agreements; it is not a tool for fixing technical performance or infrastructure stability. Improvement should focus on the technical service delivery capability first, then adjust SLAs if needed.

The total cost of the external vendor's marketing budget.

Why it fails: An external vendor's marketing budget is irrelevant to the internal service delivery decision. The focus should be on the vendor's actual capability, service quality, risk management, and the alignment of their services with the organization's business goals, not their corporate spending or branding efforts.

The personal preference of the IT department's legacy software vendors.

Why it fails: Sourcing decisions should be driven by business strategy, value, and objective criteria, not by the preferences of existing vendors. Basing decisions on legacy relationships can lead to suboptimal outcomes, vendor lock-in, and the continuation of services that no longer provide real value to the business.

All changes, including production, are now fully automated with no oversight.

Why it fails: The exhibit explicitly limits the scope to 'non_prod_only'. Therefore, this policy does not apply to production changes, which presumably require different, more rigorous levels of oversight. Generalizing this policy to production would be a major security and compliance risk, contradicting the organization's documented governance framework.

The organization has abandoned the Change Enablement practice entirely.

Why it fails: Automating change enablement is a sophisticated application of the practice, not the abandonment of it. The practice of Change Enablement is still present; it has simply evolved from a manual, bureaucratic process to an automated, policy-driven one, which is an expected maturity progression in ITIL 4.

Only senior managers are permitted to update the policy_id SEC-99.

Why it fails: The exhibit does not define who has the authority to update the policy. It only describes the current state of the policy itself. While policy management is a critical governance activity, the exhibit provides no information regarding the internal roles or security procedures for modifying the policy itself.

Moving acceptance testing to the final stage before production deployment.

Why it fails: Moving testing to the final stage is the definition of a legacy, waterfall approach. Shift-left requires testing to be integrated throughout the development process, not delayed until the end, which increases the cost of fixing defects and prevents early feedback loops that ensure high-quality service delivery.

Assigning sole responsibility for quality assurance to the dedicated QA department.

Why it fails: Shift-left requires a cultural shift where quality is everyone's responsibility, not just the QA department's. Relying on a separate silo for testing negates the benefits of early feedback and shared ownership, which are critical for achieving high-velocity, high-quality outcomes in a modern digital service environment.

Limiting developer access to production monitoring tools and logs.

Why it fails: Restricting access to production telemetry prevents developers from understanding how their code behaves in the real world. Shift-left relies on developers having observability into their services to make data-driven improvements, which is vital for maintaining performance and reliability within an agile, service-oriented delivery model.

The specific organizational silos that must maintain control.

Why it fails: Value stream design focuses on breaking down silos, not preserving them. Emphasizing departmental control creates artificial barriers that impede the flow of work, which is contrary to the CDS philosophy of creating unified, efficient pathways for value delivery that span across organizational boundaries and functional areas.

The legacy tools that are currently used for reporting.

Why it fails: Legacy tools should not dictate value stream design. The design should be driven by the value desired by the customer and the efficiency of the workflow. If legacy tools impede the flow, they should be replaced or integrated rather than allowing them to constrain the process architecture.

Creating the initial service strategy and business case.

Why it fails: Strategy and business case development belong to the 'Plan' or 'Engage' value chain activities. While these are critical for service success, they occur before the delivery phase, where the focus shifts to ensuring that the service is deployed and operational according to the established business requirements and design specifications.

Defining the long-term vision and mission for the service provider.

Why it fails: Defining the long-term vision and mission is an 'Engage' or 'Plan' activity. It focuses on the high-level direction of the organization rather than the practical execution of service delivery. Confusing strategic direction with tactical delivery tasks hinders the focus on operational excellence required during the delivery phase.

To define the long-term strategic direction of the IT organization.

Why it fails: Strategic direction is the role of the 'Plan' or 'Engage' activities. Service Transition is focused on the tactical execution of moving changes into production, ensuring that they are ready to be supported and operated. Confusing transition with long-term strategy prevents the focus required for smooth, low-risk service deployments.

To resolve all incidents that occur in the live environment.

Why it fails: Incident resolution is the responsibility of 'Support' or 'Incident Management' activities. While Service Transition ensures the service is supportable, it does not directly manage incident resolution once the service is live. Focusing on resolution rather than transition would distract from the goal of preventing issues before they occur.

To manage the hardware procurement lifecycle for all IT equipment.

Why it fails: Hardware procurement is an asset management activity, not a service transition task. While it may be a prerequisite for a service, it is not the focus of the transition process, which is concerned with ensuring that the service as a whole is ready for delivery to the customer.

Engage

Why it fails: Engage focuses on understanding stakeholder needs, fostering relationships and capturing demand, not on managing supplier contracts against agreed performance metrics. It is tempting because supplier relationship management sounds like engagement, and Engage would be correct if the question concerned gathering requirements or maintaining ongoing stakeholder dialogue.

Design and transition

Why it fails: Design and transition covers creating and changing services, including design, build, test and release, not the ongoing management of supplier performance or component availability. It is tempting because supplier contracts are often established during transition, and this activity would be correct if the question asked who onboards or integrates a new supplier.

Deliver and support

Why it fails: Deliver and support concerns ensuring services are delivered and supported operationally, including incident resolution and service restoration, not managing supplier contracts or their performance metrics. It is tempting because availability of service components feels operational, and this activity would be correct if the question asked who handles day-to-day delivery and user support.

The incident is logged in the queue for manual L1 triage.

Why it fails: The policy explicitly states to 'Bypass_L1_Queue', meaning manual triage is intentionally skipped. Logically, the system is configured to prioritize rapid escalation for critical issues, so sending this to L1 would violate the automated logic defined for high-priority incidents and increase restoration time.

The incident requires approval from the service manager before escalation.

Why it fails: There is no requirement for manual approval in the provided JSON policy. The policy defines an automated workflow, and introducing manual steps would defeat the purpose of the 'Bypass' instruction, which is designed to ensure the fastest possible response to critical service disruptions.

The incident is downgraded to low priority by the automation engine.

Why it fails: The policy clearly identifies the incident as 'Critical'. Downgrading such an item would contradict the purpose of the policy, which is to ensure that urgent issues receive the appropriate level of attention and resources immediately, rather than being delayed by incorrect classification or processing.

Ensuring the service meets all initial technical specifications perfectly.

Why it fails: Technical specifications can become irrelevant if they do not meet the changing needs of the user. Value is defined by the user, not by the original specification. If the service is built to a spec but fails to solve the user's problem, it provides no real value.

Minimizing the frequency of changes to the service design.

Why it fails: Infrequent changes often indicate a failure to adapt to user needs. In a modern environment, the ability to change is a competitive advantage. Static services quickly become obsolete as the user's expectations and the competitive landscape change, making them less valuable over time rather than more.

Prioritizing infrastructure stability over user requirements.

Why it fails: Infrastructure stability is necessary, but it is not the same as value. A service can be 100% available and still be useless if it does not meet the user's requirements. Value must be the primary driver, with infrastructure serving as the foundation to support that value.

It serves as the main input for generating the annual IT budget request for the next fiscal year.

Why it fails: While feedback might influence budgeting, its primary purpose in CDS is operational improvement and value validation. Using feedback strictly for annual budget requests ignores its real-time value in driving daily improvements to the service and the overall user experience during the active service lifecycle.

It is required to satisfy the documentation needs of the Change Management practice.

Why it fails: Although feedback may be documented for auditing purposes, its core purpose in CDS is not to fulfill administrative change control requirements. The primary goal is to inform the service design and delivery process so that the service evolves effectively to meet user needs.

It allows the team to identify which employees are not using the system correctly.

Why it fails: Focusing on policing user behavior is not the intent of gathering feedback in CDS. The goal is to understand how the system supports or hinders the user, not to blame the user. Feedback should be used to improve the system, not to criticize the workforce.

Defining the long-term strategic vision of the organization.

Why it fails: Strategic vision is a high-level governance activity that sits above the operational 'Create, Deliver and Support' lifecycle. While the lifecycle should align with strategy, the activity of defining that strategy is not an operational task belonging to the delivery phase itself.

Writing the initial requirements for a new software feature.

Why it fails: Writing requirements is part of the 'Create' phase, where the service is conceptualized and defined. While these requirements drive delivery, the act of writing them is a planning or design activity, not an operational delivery activity where the service is transitioned to a live environment.

Conducting a performance appraisal for IT support staff.

Why it fails: Performance appraisals are a human resources and management function. They are not part of the 'Deliver' lifecycle, which is focused on the technical and operational activities required to move services into production and ensure they remain accessible to the users as intended.

IT Asset Management.

Why it fails: IT Asset Management focuses on the inventory and lifecycle of IT assets, such as hardware and software licenses. While it contributes to availability, its primary goal is financial and operational control over assets rather than the direct management of service performance and business level targets.

Incident Management.

Why it fails: Incident Management is a reactive practice focused on restoring service operation as quickly as possible after a disruption. It does not proactively manage capacity or availability to meet long-term business performance targets; instead, it deals with the immediate aftermath of service failures or degradation.

Relationship Management.

Why it fails: Relationship Management focuses on nurturing links between the organization and its stakeholders at strategic and tactical levels. While it helps understand requirements, it is not responsible for the technical management of capacity or the monitoring of availability targets for specific IT services.

Manually logging every single incident as a separate problem record in the database.

Why it fails: Logging every incident as a problem is an inefficient practice that leads to excessive administration. Problems should only be raised when a root cause is suspected or when recurring incidents warrant investigation. This avoids cluttering the system and allows for a more focused approach to analysis.

Ensuring that permanent solutions are implemented for every single known error.

Why it fails: Not all problems require permanent solutions. Some may be too costly to fix relative to the impact. The goal is to manage the risk. Documenting workarounds is a valid, acceptable outcome in many cases where a permanent fix is not economically viable or technically feasible.

The physical color scheme and branding of the service interface.

Why it fails: While UI design is relevant to user experience, it does not define whether a service is 'fit for purpose.' Utility is about the functionality provided to address business needs. Aesthetic branding is secondary and does not impact the core ability of the service to fulfill its intended task.

The specific hardware vendor selected for the underlying server infrastructure.

Why it fails: Hardware vendor selection is a technical implementation detail, not a determinant of fit for purpose. The functionality of the service is what determines its suitability. Whether it runs on one vendor or another is an operational decision that generally does not change the core utility of the service.

Service resilience

Why it fails: Service resilience refers to the ability to withstand and recover from disruptions. While resilience is important for service continuity, it does not explicitly refer to the ease of modification or structural adaptability. Resilience focuses on maintaining availability during adverse conditions rather than the ease of changing functional requirements.

Service utility

Why it fails: Service utility refers to the fitness for purpose, or the functional aspects of the service that help achieve business outcomes. While utility is a prerequisite for a valuable service, it does not describe the architectural flexibility required to modify the service in response to future business changes.

Technical debt management

Why it fails: Technical debt refers to the implied cost of additional rework caused by choosing an easy solution now instead of a better approach. While managing debt is important, it is an activity, not a design concept describing the inherent ability of a service to be easily modified or adapted.