Refer to the Exhibit Practice Questions

Change Enablement

Why it fails: Change Enablement focuses on managing the risk associated with changes, including assessing impact and authorizing the implementation. While it provides the framework for when changes occur, it is not responsible for the technical execution of a rollback during a deployment failure; that is the role of Deployment Management.

Incident Management

Why it fails: Incident Management aims to restore normal service operation as quickly as possible. While a deployment failure is an incident, the rollback action is a deployment activity. Incident Management would handle the broader communication and service restoration process if the rollback failed or if further issues were discovered.

Problem Management

Why it fails: Problem Management focuses on identifying the root causes of incidents and managing workarounds or permanent solutions. It is a proactive and reactive practice that looks at the underlying reasons for failure but does not handle the immediate, automated technical execution of a deployment rollback during active service delivery.

Restart the 'srv-001' instance to clear the degraded status.

Why it fails: Restarting the instance is a temporary fix that fails to address the underlying cause, which is the critical health of the database. Since the service depends on the database, the degradation will immediately return. Effective resolution requires tackling the root issue in the dependency chain first.

Trigger the 'auto_patch' process for 'srv-001' to resolve the health status.

Why it fails: Patching the service will not resolve the latency issues caused by the critical status of the database. The root cause is external to the service itself, so patching is an irrelevant distraction that wastes resources and does not move the organization closer to restoring normal service operations.

Notify the users that 'srv-001' will be taken offline for unscheduled maintenance.

Why it fails: Taking the service offline is an escalation that should be avoided if restoration is possible. Communication is necessary, but it should be paired with proactive remediation of the identified root cause. Simply announcing an outage without attempting to fix the core database issue is a failure of service delivery.

Improve incident response communication to stakeholders.

Why it fails: While communication is important, the log entry identifies a technical failure due to environmental mismatch, not a communication gap. Improving communication would not address the root cause of the deployment failure, which is the lack of proper validation of the target infrastructure against the required service dependencies.

Increase the frequency of deployment to ensure faster feedback.

Why it fails: Increasing frequency without fixing the underlying validation issue would simply lead to more frequent failed deployments. The team must first address the environmental validation gap to ensure that subsequent releases are stable, rather than blindly increasing speed which would exacerbate the technical debt and service quality issues.

Enhance the rollback procedure to be faster.

Why it fails: Optimizing rollbacks is important for resilience, but it does not prevent the failure from happening in the first place. CDS focuses on managing value streams effectively, which includes ensuring successful deployments rather than merely minimizing the duration of failures once they have already occurred in production.

A standard hardware upgrade planned for a weekend maintenance window.

Why it fails: Standard changes are low-risk, repeatable tasks that follow established procedures. An 'emergency' policy bypass would be excessive and inappropriate for routine work, as these tasks should be managed via standardized procedures that do not require emergency-level authorization or automated testing bypasses.

A major new feature release for the customer-facing mobile application.

Why it fails: Major feature releases carry significant business risk and require thorough peer review and stakeholder approval. Bypassing these standard governance gates via an emergency policy is reckless and would likely violate organizational risk policies, as automated tests alone cannot assess the business impact of a new release.

An internal audit of the code repository to identify security vulnerabilities.

Why it fails: An audit is a passive activity that does not result in a change to the production environment. An emergency deployment policy is irrelevant to audits, as there is no production change being executed that requires an expedited or bypassed approval process for risk mitigation.

Immediately increase the WIP_LIMIT from 5 to 10 to clear the queue.

Why it fails: Increasing the limit without addressing the underlying constraint will simply shift the bottleneck further down the stream. This action fails to identify why the module is struggling, leading to potential system instability or further degradation of performance under the higher, unmanaged load.

Restart the 'Auth_Proc' module to clear the memory and reset the request queue.

Why it fails: Restarting is a temporary, reactive fix that does not address the systematic issue causing the bottleneck. If the underlying logic or capacity is insufficient, the error will recur immediately. ITIL 4 emphasizes sustainable improvements over temporary interventions that do not provide long-term service stability.

Instruct users to retry their requests in ten minutes to decrease load.

Why it fails: Offloading the problem to the user is poor service design and degrades the customer experience. The team is responsible for managing the capacity of their services. Instead of asking users to wait, the team should be investigating how to handle the demand more efficiently.

Increase the number of retry attempts to five in the configuration.

Why it fails: Increasing retry attempts merely masks the symptom without addressing the underlying database connectivity issue. It may lead to longer wait times for users before they receive an error, potentially straining system resources further rather than solving the actual infrastructure bottleneck causing the timeout.

Ignore the logs and wait for the database service to recover automatically.

Why it fails: Ignoring persistent service failures violates the principles of proactive support and service continuity. Relying on self-recovery without understanding the cause leaves the service vulnerable to future outages, negatively impacting user experience and the organization's reputation for providing reliable and available IT services.

Close all active incidents and ask users to restart their sessions.

Why it fails: Closing incidents without resolving the core issue is poor practice that creates customer frustration and increases ticket volume. Users cannot fix a systemic backend service failure by restarting their sessions, and this approach fails to address the root cause identified in the service logs.

Roll back the deployment immediately to investigate why the production weight is currently set to zero percent.

Why it fails: Setting the initial production weight to zero in a blue-green deployment is standard practice for verifying the staging environment prior to traffic cutover. Rolling back at this stage without testing would unnecessarily abort a healthy deployment.

Decommission the old production environment permanently before routing any live user traffic to the new deployment.

Why it fails: Decommissioning production before any live traffic reaches the validated staging environment removes the rollback target, so a failed cutover leaves no service. Retiring the old environment is correct only after the new deployment has served production traffic successfully and the rollback window has closed.

Submit a standard change request to a traditional change advisory board for a 7-day review period before changing traffic weights.

Why it fails: A seven-day CAB review inserts delay after health checks have already passed, contradicting the immediate traffic switch the blue-green value stream expects. Standard change pre-approval suits routine low-risk changes, not a validated deployment awaiting cutover.

The provisioning step; increase server resources to speed up delivery.

Why it fails: The log shows that provisioning only takes 5 minutes, which is an efficient part of the process. Increasing resources for a step that is already fast will have a negligible impact on the total lead time, making it an ineffective use of effort and investment compared to addressing the actual bottleneck.

The validation step; optimize the automated scripts to run faster.

Why it fails: The validation step takes only 5 minutes, making it highly efficient. Optimizing a task that represents less than 2% of the total time is not the best way to improve value stream throughput. Efforts should be directed toward the phase causing the most significant delay, which is the manual approval step.

The user request step; provide training to users to submit requests faster.

Why it fails: The user request step takes only 5 minutes, which is negligible in the context of the overall process. Providing training is not a solution for a bottleneck in the internal processing of the service request. The focus must be on the internal approval delay, which is the actual cause of the latency.

Manual incident escalation.

Why it fails: Manual escalation implies that a human operator was involved to resolve the issue. The exhibit clearly shows that the system handled the timeout and restoration autonomously. This distinction is vital because manual processes are slower and prone to human error, which are exactly the types of processes CDS seeks to automate.

Root cause analysis via manual intervention.

Why it fails: Root cause analysis usually follows an incident to prevent recurrence. While the logs provide data for RCA, the log itself describes an automated recovery action, not the diagnostic process. Confusing the automated mitigation step with the analytical process of root cause analysis leads to incorrect conclusions about service management capabilities.

Database configuration management.

Why it fails: Configuration management involves tracking and managing the state of IT assets. While the database is an asset, the exhibit shows a runtime operational response to a connectivity event. This is an incident handling mechanism, not the administrative task of updating configurations, which is a different aspect of service management.

Increase the timeout threshold in the production environment settings.

Why it fails: Modifying production thresholds is a reactive, surface-level fix that does not address the underlying architectural or code issue. This approach ignores the root cause and potentially masks recurring stability issues, failing to leverage the learning opportunities provided by the deployment failure for long-term improvement.

Disable the automated rollback feature to prevent service disruption.

Why it fails: Disabling automated rollback mechanisms is dangerous and contrary to CDS goals of resilience. Rollbacks are essential for maintaining service availability during failure. Removing them increases the risk of extended outages and prevents the system from automatically recovering when it detects an operational anomaly.

Assign the incident to the infrastructure team for manual intervention.

Why it fails: Relying on manual intervention contradicts the objective of automated, scalable service delivery. It creates a bottleneck and fails to utilize the insights gained from the failure to automate future processes or improve the reliability of the deployment pipeline through better design and earlier testing.

Close the monitoring alert because the server is currently 'Up'.

Why it fails: Closing an alert just because the service is 'Up' ignores the reality that it is unusable due to latency. This is a classic example of failing to manage 'fit for use'. Proactive support requires looking beyond binary status flags to understand the actual performance metrics that affect the user experience.

Wait for users to report performance degradation through the portal.

Why it fails: Waiting for user reports is a reactive, legacy approach. Modern service management aims to identify and fix performance issues before they affect the user. Relying on reports means that users have already suffered a poor experience, damaging trust and increasing the stress on the support team during the incident.

Apply a software patch immediately to see if it fixes the load issue.

Why it fails: Applying a patch without understanding the root cause is high-risk. It could exacerbate the problem or introduce new, unforeseen issues. The correct CDS approach is to analyze the data, determine the cause of the load, and then execute a controlled, tested change to resolve the issue safely and effectively.

It reduces the storage cost of maintaining two separate environments.

Why it fails: Blue-Green deployments actually increase storage and infrastructure costs because two identical environments must be maintained simultaneously. The benefit is not cost-saving but rather risk reduction and service continuity, which justifies the additional investment in infrastructure to ensure that deployments are safe, reliable, and easily reversible if problems occur.

It forces developers to write code for two different platforms.

Why it fails: Blue-Green deployment involves two instances of the same service, not two different platforms. The code remains the same across both environments. This strategy is about operational safety, not changing the development requirements or forcing the team to work with multiple, heterogeneous technical architectures that could add unnecessary complexity.

It eliminates the need for any pre-deployment testing.

Why it fails: Blue-Green deployment does not replace testing; it complements it. In fact, it provides a final testing ground in the production-like environment before switching live traffic. Relying on the deployment strategy to catch issues instead of testing is a dangerous practice that risks service stability and user trust.

Emergency change.

Why it fails: Emergency changes require rapid assessment and approval, often by a special CAB, due to the critical nature of the issue being addressed. The policy in the exhibit specifies 'standard' and 'automated approval,' which does not match the high-touch, urgent requirements associated with managing emergency changes in an ITIL framework.

Normal change.

Why it fails: Normal changes require a formal assessment and approval process, usually by a change authority or board, due to their potential impact and risk level. The exhibit explicitly defines the change as 'standard,' indicating that it has already been pre-authorized and does not require the manual evaluation typical of a normal change.

Standard operating procedure change.

Why it fails: This is not a recognized ITIL change category. Changes are classified as standard, normal, or emergency. Using incorrect terminology suggests a misunderstanding of the ITIL framework. The exhibit explicitly labels the change type as 'standard,' which aligns with the documented ITIL change management classification and supports automated workflows for low-risk tasks.

Automated approval without any human intervention.

Why it fails: The JSON policy clearly sets 'auto_approve' to false. Therefore, automated approval is prohibited for this policy level. Relying on automation alone for medium-risk changes contradicts the explicit requirement for peer review defined in the policy, which is intended to maintain oversight and manage operational risk effectively.

Immediate production deployment to all users.

Why it fails: The policy specifies a 'canary' deployment strategy, which explicitly prevents immediate deployment to all users. Instead, it requires a phased rollout where the change is tested on a small subset of users first. This strategy is essential for minimizing the blast radius of any potential issues discovered.

Only high-risk changes require a formal review process.

Why it fails: The policy defines requirements based on the risk level. For a medium-risk change, the policy explicitly requires a peer review. Claiming that only high-risk changes need review ignores the specific configuration of the JSON policy, which sets governance standards for this specific category of change, regardless of other risk levels.

Continuous Integration

Why it fails: Continuous Integration refers to the practice of merging development branches into a shared repository frequently to detect integration issues early. It focuses on the velocity and quality of code merges rather than the operational resilience or runtime protection of services in production.

Shift-Left Testing

Why it fails: Shift-left testing involves moving testing activities earlier in the development lifecycle to find defects sooner. While this improves overall software quality, it is a development-phase strategy and does not describe the runtime operational mechanism for mitigating failures in a live environment.

Capacity Management

Why it fails: Capacity Management ensures that the organization has the right amount of resources to meet agreed-upon service requirements. While it involves planning for usage spikes, it does not involve the dynamic, real-time automated circuit-breaking mechanisms used to manage component-level failures during operation.