Scenario practice questions

Refer to the exhibit. The log shows an automated response to a failed deployment. Which ITIL 4 practice is primarily responsible for the execution of this 'roll back' action?

Exhibit

LOG_FILE_EXTRACT:
[2023-10-12 14:05:01] INFO: Deploying release 2.4.1
[2023-10-12 14:05:05] WARN: High memory usage detected on node-03
[2023-10-12 14:05:10] CRITICAL: Service latency threshold exceeded
[2023-10-12 14:05:12] ACTION: Rolling back to release 2.4.0

Trap 1: Change Enablement

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.

Trap 2: Incident Management

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.

Trap 3: Problem Management

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.

A
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.
B
Deployment Management
Deployment Management manages the movement of new or changed components to live environments. This includes the technical tasks involved in implementing releases, including automated rollbacks when defined success criteria are not met. It ensures that the deployment process remains controlled and that services remain operational throughout the update.
C
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.
D
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.

Question 2hardmultiple choice

A development team is implementing shift-left testing as part of their value stream improvement initiative. The primary objective is to catch defects earlier in the creation phase. However, developers are now complaining about excessive alert fatigue and increased cycle times due to unrefined automated static code analysis tools. How should the service value system address this issue?

Trap 1: Revert all shift-left testing practices immediately and return to…

Reverting to late-stage testing completely abandons the benefits of shift-left practices, such as cost reduction and faster defect resolution. The correct approach is to refine and optimize the existing automated tools rather than discarding the entire improvement initiative.

Trap 2: Disable all automated static code analysis tools and rely entirely…

Relying solely on manual peer reviews introduces significant human bottlenecks and inconsistency, reducing the overall throughput of the value stream. Automation remains essential for scaling development, provided the tools are configured correctly to minimize false positives.

Trap 3: Increase the frequency of automated security scans to run on every…

Running scans on every keystroke multiplies the unrefined static analysis output that caused the alert fatigue, further inflating cycle times rather than reducing noise. It is tempting because continuous integration pipelines benefit from frequent scanning, but that suits gated, incremental checks on commits, not per-keystroke execution.

A
Revert all shift-left testing practices immediately and return to traditional late-stage testing conducted exclusively by quality assurance specialists.
Why it fails: Reverting to late-stage testing completely abandons the benefits of shift-left practices, such as cost reduction and faster defect resolution. The correct approach is to refine and optimize the existing automated tools rather than discarding the entire improvement initiative.
B
Disable all automated static code analysis tools and rely entirely on manual peer reviews for every code commit.
Why it fails: Relying solely on manual peer reviews introduces significant human bottlenecks and inconsistency, reducing the overall throughput of the value stream. Automation remains essential for scaling development, provided the tools are configured correctly to minimize false positives.
C
Increase the frequency of automated security scans to run on every keystroke in the integrated development environment.
Why it fails: Running scans on every keystroke multiplies the unrefined static analysis output that caused the alert fatigue, further inflating cycle times rather than reducing noise. It is tempting because continuous integration pipelines benefit from frequent scanning, but that suits gated, incremental checks on commits, not per-keystroke execution.
D
Collaborate with developers and security teams to tune the static analysis rulesets, filtering out low-priority noise and actionable alerts.
Tuning static analysis rulesets with developers and security teams removes low-priority noise while preserving actionable findings, directly reducing alert fatigue and cycle times. This addresses the constraint that unrefined tooling, not shift-left itself, caused the value stream slowdown.

Question 3hardmultiple choice

Refer to the exhibit. Which scenario best fits the application of this policy within a DevOps-driven CDS environment?

Exhibit

JSON_POLICY: { "request_type": "emergency", "approval_path": "auto_bypass", "validation": "automated_test_only" }

Trap 1: A standard hardware upgrade planned for a weekend maintenance…

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.

Trap 2: A major new feature release for the customer-facing mobile…

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.

Trap 3: An internal audit of the code repository to identify security…

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.

A
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.
B
A critical fix for a production incident that is causing significant business impact.
This policy enables rapid deployment of fixes when business impact is high. By leveraging automated testing as a validation gate, the organization maintains service integrity while drastically reducing the time required for manual approvals, which is the desired outcome for emergency changes in high-velocity organizations.
C
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.
D
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.

Question 4mediummultiple choice

During a post-implementation review of a failed major release, a team identifies that poor communication between development and operations teams contributed significantly to the outage. According to ITIL 4 guiding principles, which principle should the organization focus on to prevent future silos?

Trap 1: Focus on value

Focus on value ensures that everything the organization does links back to value for stakeholders. While important, it does not directly address organizational silos or inter-team communication breakdowns that lead to operational deployment failures.

Trap 2: Keep it simple and practical

Keep it simple and practical advocates for eliminating waste and using the minimum number of steps necessary to achieve objectives. It helps streamline processes but does not directly target cultural silos between development and operations teams.

Trap 3: Optimize and automate

Optimize and automate focuses on maximizing the value of human and technical resources through streamlining and technology. Automation aids efficiency, but the root cause of this failure stems from poor human communication and siloed team behaviors.

A
Focus on value
Why it fails: Focus on value ensures that everything the organization does links back to value for stakeholders. While important, it does not directly address organizational silos or inter-team communication breakdowns that lead to operational deployment failures.
B
Keep it simple and practical
Why it fails: Keep it simple and practical advocates for eliminating waste and using the minimum number of steps necessary to achieve objectives. It helps streamline processes but does not directly target cultural silos between development and operations teams.
C
Collaborate and promote visibility
Collaborate and promote visibility directly addresses cultural silos by encouraging open communication, shared understanding, and cross-functional teamwork. This ensures that development and operations work transparently together to mitigate risks before releases go live.
D
Optimize and automate
Why it fails: Optimize and automate focuses on maximizing the value of human and technical resources through streamlining and technology. Automation aids efficiency, but the root cause of this failure stems from poor human communication and siloed team behaviors.

Question 5mediummultiple choice

A financial services company has a critical incident where the payment gateway is down. The incident manager has assembled a team including a database administrator, a network engineer, and a payment application developer to work collaboratively on the issue. Which ITIL 4 CDS concept does this approach exemplify?

Trap 1: Hierarchical escalation

Hierarchical escalation involves passing an incident up the management chain. In this scenario, the incident manager is not escalating; instead, they are bringing together technical experts to collaborate. Hierarchical escalation would involve notifying senior managers, which is not described here. The focus is on collaborative problem-solving, not management escalation.

Trap 2: Continual improvement

Continual improvement is an ongoing effort to improve products, services, and practices. While resolving the incident may lead to improvements, the immediate action of assembling a cross-functional team to fix the issue is not continual improvement itself. Continual improvement would come later, after the incident is resolved, to prevent recurrence. The scenario describes a real-time response, which is swarming.

Trap 3: Shift-left

Shift-left is about moving work to earlier stages in the value stream, such as testing earlier in development. This scenario is about resolving a live incident, not preventing defects by shifting work left. The team is assembled reactively to address an ongoing outage, so shift-left is not applicable here. The concept of swarming is more relevant.

A
Hierarchical escalation
Why it fails: Hierarchical escalation involves passing an incident up the management chain. In this scenario, the incident manager is not escalating; instead, they are bringing together technical experts to collaborate. Hierarchical escalation would involve notifying senior managers, which is not described here. The focus is on collaborative problem-solving, not management escalation.
B
Continual improvement
Why it fails: Continual improvement is an ongoing effort to improve products, services, and practices. While resolving the incident may lead to improvements, the immediate action of assembling a cross-functional team to fix the issue is not continual improvement itself. Continual improvement would come later, after the incident is resolved, to prevent recurrence. The scenario describes a real-time response, which is swarming.
C
Swarming
Swarming is a collaborative approach where a group of people with different skills work together on an incident to resolve it quickly. In this scenario, the incident manager assembles a team with diverse expertise (DBA, network engineer, developer) to work on the payment gateway outage. This matches the swarming concept, which is recommended in ITIL 4 CDS for complex incidents that require cross-functional collaboration.
D
Shift-left
Why it fails: Shift-left is about moving work to earlier stages in the value stream, such as testing earlier in development. This scenario is about resolving a live incident, not preventing defects by shifting work left. The team is assembled reactively to address an ongoing outage, so shift-left is not applicable here. The concept of swarming is more relevant.