30 Questions — ITIL 5 – Master : Certified ITIL Master - Domain 5 - DevOps, SRE, and Platform Engineering

Expand any question to reveal the correct answer and explanation.

1. 1 An organization operating in a high-velocity environment has exhausted its quarterly error budget for a critical digital product. According to SRE principles integrated into ITIL 5, which action should the product team prioritize?

   Consider the primary purpose of an error budget as a balancing tool between innovation and stability.

   Temporarily halt all non-emergency functional changes to focus on reliability improvements.

   Error budgets serve as a governance mechanism where exhaustion mandates a shift in focus from velocity to system stability and reliability.

   • ✗ Initiate a Change Enablement review to increase the risk tolerance threshold for the remainder of the quarter.

     Adjusting thresholds to accommodate failures undermines the purpose of the error budget as a meaningful reliability guardrail.

   • ✗ Immediately roll back the most recent successful deployment to reclaim budget points.

     Rolling back a stable deployment does not address the underlying reliability issues and does not 'refund' a spent error budget.

   • ✗ Escalate to the Strategic Leader to authorize a temporary Service Level Agreement (SLA) waiver.

     Internal error budgets (SLOs) are designed to be stricter than external SLAs to allow for proactive management before a breach occurs.

2. 2 In the context of ITIL 5 Platform Engineering, what is the primary objective of creating an 'Internal Developer Platform' (IDP)?

   Think about how a 'paved road' affects the day-to-day workflow of a software developer.

   To reduce cognitive load on feature teams by providing self-service infrastructure and standardized toolchains.

   Platform engineering treats the platform as a product designed to abstract complexity and enable developer autonomy through paved paths.

   • ✗ To centralize all configuration management activities into a single siloed operations function.

     Centralizing manual tasks into a silo contradicts the high-velocity goal of enabling decentralized, fast-moving product teams.

   • ✗ To replace the need for Site Reliability Engineers by automating all incident response workflows.

     While platforms increase automation, they complement SRE roles rather than replacing the need for engineering-led reliability practices.

   • ✗ To ensure that all digital products utilize the exact same application code regardless of business requirements.

     Standardizing infrastructure and delivery pipelines is the goal, not forcing identical application logic across diverse products.

3. 3 When designing a monitoring strategy for a complex AI-enabled service, why does ITIL 5 emphasize 'Observability' over traditional monitoring?

   Reflect on the difference between checking if a system is 'up' and understanding 'why' it is behaving a certain way.

   Monitoring focuses on known failure modes, whereas observability allows for the investigation of 'unknown unknowns' through system telemetry.

   Observability provides the internal state visibility needed to debug complex, non-deterministic issues common in distributed and AI-driven systems.

   • ✗ Observability is a cost-reduction technique that replaces the need for high-frequency log aggregation.

     Observability actually increases the volume of telemetry data required, as it relies heavily on logs, metrics, and traces.

   • ✗ Traditional monitoring is only applicable to hardware, while observability is used exclusively for software-defined networking.

     Monitoring applies to all layers of the stack; the distinction lies in the depth of insight and the ability to ask new questions of the system.

   • ✗ Observability provides a guaranteed resolution path for all incidents through automated AIOps scripts.

     Observability provides the data for understanding the system, but it does not inherently guarantee automated resolutions.

4. 4 A team is implementing Chaos Engineering in their 'Transition' phase. What is the primary risk of skipping 'Steady State' definition before running experiments?

   Consider the scientific method and what is required to identify a deviation from normal behavior.

   Without a steady state, the team cannot accurately measure the impact of the injected failure or verify if the system recovered.

   Steady state serves as the baseline; without it, there is no objective way to determine if the experiment's hypothesis was proven or if the system is compromised.

   • ✗ The experiment will fail to execute because Chaos Engineering tools require a steady state to initiate the blast radius.

     Most tools will run regardless of baseline data, but the resulting information will be contextless and unusable.

   • ✗ Skipping steady state definition is a mandatory requirement for 'Game Days' to ensure realistic chaos.

     Game Days still require understood baselines to ensure that the 'chaos' is controlled and measurable.

   • ✗ It prevents the AIOps engine from being able to automatically roll back the experiment.

     While baselines help AIOps, the primary issue is the loss of experimental integrity and the ability to learn from the failure.

5. 5 In ITIL 5 High Velocity IT, how does 'Toil' differ from 'Technical Debt'?

   One is about 'doing' the same task over and over; the other is about 'living' with a shortcut taken in the past.

   Toil is repetitive, manual work related to running a service, while technical debt is the cost of sub-optimal architectural decisions.

   Toil is operational overhead that scales with service growth; technical debt is a structural issue in the codebase or design that hinders future change.

   • ✗ Toil is a strategic investment in reliability, whereas technical debt is always a negative outcome of poor management.

     Toil is generally viewed as something to be minimized, while technical debt can sometimes be a conscious, temporary trade-off for speed.

   • ✗ Toil only applies to Service Desk activities, while technical debt is exclusive to the 'Build' phase.

     Both concepts can exist throughout the entire product and service lifecycle, from design to support.

   • ✗ Reducing toil requires manual intervention, while technical debt can only be resolved through AIOps.

     Toil is reduced through automation and engineering; technical debt is resolved through refactoring and architectural improvement.

6. 6 Which DevOps topology is most likely to cause 'Handoff Gaps' and friction in an ITIL 5 value stream?

   Identify the team structure that prioritizes functional isolation over shared value delivery.

   A siloed structure where the 'Dev' team and 'Ops' team only communicate through formal ticket exchanges.

   Separating responsibilities with a hard barrier leads to misaligned goals, delayed feedback, and loss of end-to-end lifecycle context.

   • ✗ A cross-functional product team that includes developers, testers, and embedded SREs.

     This model is designed to minimize handoffs by keeping all necessary competencies within a single, autonomous unit.

   • ✗ A 'Platform' team that provides standardized infrastructure-as-code templates for developer use.

     This enables 'self-service' which reduces the need for manual handoffs between teams for routine infrastructure requests.

   • ✗ An SRE team that consults with multiple product teams to define SLOs and error budgets.

     Consultative SRE models facilitate collaboration and shared reliability goals rather than creating operational barriers.

7. 7 How should a 'Blameless Postmortem' be conducted within an ITIL 5 organization following a major high-velocity incident?

   Think about whether the goal is to find a 'who' or to understand the 'how'.

   Focus on identifying the systemic causes and latent conditions that allowed the human error to occur.

   Blameless culture assumes people act with the best intentions and looks for flaws in the process, tools, or environment instead of assigning fault.

   • ✗ Identify the specific individual responsible for the configuration error to ensure they receive mandatory retraining.

     Focusing on individual blame creates a culture of fear, leading to hidden errors and reduced transparency.

   • ✗ Prioritize speed of the meeting over depth of analysis to ensure the team can return to the 'Build' phase quickly.

     The value of a postmortem lies in the depth of learning; rushing the process risks missing critical systemic improvements.

   • ✗ Wait until the end of the fiscal quarter to review all incidents at once to save management time.

     Postmortems should be conducted shortly after the incident while details are fresh to maximize the accuracy of the findings.

8. 8 In an environment utilizing Continuous Delivery (CD), how does ITIL 5 reconcile the need for 'Change Enablement' with high-velocity deployment?

   Consider how governance can be 'shifted left' into the automation itself.

   By automating the risk assessment and approval process for standard changes within the deployment pipeline.

   Moving governance 'into the code' allows for rapid changes while maintaining the auditability and control required by ITIL.

   • ✗ By requiring a manual Change Advisory Board (CAB) meeting for every code commit to ensure total oversight.

     Manual approvals for every commit would create a bottleneck that defeats the purpose of a high-velocity delivery pipeline.

   • ✗ By eliminating the Change Enablement practice entirely for teams that use SRE principles.

     Change Enablement is still necessary; it simply evolves from manual gates to automated guardrails in high-velocity contexts.

   • ✗ By only allowing deployments to occur during pre-defined monthly maintenance windows.

     Strict maintenance windows contradict the 'continuous' nature of modern delivery models.

9. 9 Which of the following is a key characteristic of 'AIOps' in the ITIL 5 Operate phase?

   Look for the answer that describes a move from human-led reactive analysis to data-driven proactive insight.

   Using machine learning to correlate massive volumes of telemetry data to identify patterns and predict outages.

   AIOps leverages advanced analytics to handle the complexity and scale of modern digital environments that exceed human processing capacity.

   • ✗ Replacing the Service Desk with a static list of 'Frequently Asked Questions' powered by a basic search engine.

     AIOps is about intelligent automation and data processing, not just simplifying user interfaces or providing static content.

   • ✗ Manually scripting every possible response to an incident to ensure the AI follows strict procedural rules.

     Static scripting is traditional automation; AIOps involves probabilistic models and learning from data.

   • ✗ Ensuring that the 'Build' phase is entirely manual so that the AI has clean code to operate.

     AIOps works best when the entire lifecycle is automated, providing a rich flow of data from build through to operation.

10. 10 When defining Service Level Objectives (SLOs) in ITIL 5, what is the role of a 'Service Level Indicator' (SLI)?

    Distinguish between the measurement itself and the goal you set for that measurement.

    It is the specific metric (e.g., latency, error rate) used to measure the performance of a service against an objective.

    SLIs are the raw measurements that provide the data for the SLO, which is the target value for that measurement over time.

    • ✗ It is a legally binding document that defines the penalties for missing a reliability target.

      The indicator is a technical measurement; legal or contractual agreements are handled by Service Level Agreements (SLAs).

    • ✗ It is a marketing term used to describe the 'Digital Experience' to external customers.

      While SLIs can influence experience, they are precise technical measurements used for internal service management.

    • ✗ It is a tool used to automatically shut down services that exceed their cost budget.

      An indicator is for measurement; the action taken based on that measurement is part of a management policy or automated trigger.

11. 11 In the ITIL 5 'Acquire' activity, how does Platform Engineering help manage 'Build vs. Buy' decisions?

    Focus on the 'integration' and 'standardization' benefits of a platform.

    By providing a standardized environment that makes it easier to integrate third-party SaaS while maintaining internal standards.

    A robust platform enables hybrid models where external components can be seamlessly incorporated into internal value streams.

    • ✗ By forcing the organization to build everything internally to ensure the platform is never dependent on external vendors.

      Platform engineering supports efficiency; building everything from scratch is often inefficient compared to buying established solutions.

    • ✗ By delegating all procurement decisions to the SRE team to ensure maximum reliability of purchased tools.

      Procurement is a collaborative effort involving strategy and finance; SREs provide technical input but rarely own the entire 'Acquire' process.

    • ✗ By ensuring that 'Build' decisions are always prioritized over 'Buy' decisions to increase technical debt.

      Building unnecessarily increases complexity and maintenance; the goal is to build only what provides unique competitive advantage.

12. 12 What is the primary function of an 'Incident Commander' (IC) during a high-velocity service outage?

    Think about the role of a conductor in an orchestra or a leader in a crisis response unit.

    To act as a single point of authority for decision-making and to coordinate the various technical response streams.

    The IC manages the incident response process (not necessarily the technical fix) to ensure clear communication and prevent duplicate efforts.

    • ✗ To manually review the code changes that caused the incident while the developers are busy fixing it.

      The IC focuses on orchestration and communication; technical deep dives are handled by Subject Matter Experts (SMEs).

    • ✗ To communicate directly with the media and legal teams to prevent a loss of reputation.

      Public relations are handled by specific communications roles; the IC focus is internal to the incident response team.

    • ✗ To determine which employee should be disciplined for the error before the service is restored.

      Blameless culture dictates that discipline is not the focus, especially during an active incident where restoration is the priority.

13. 13 How does ITIL 5 apply 'Value Stream Mapping' (VSM) to SRE and DevOps practices?

    Focus on the 'flow' of work and the identification of non-value-added activities.

    To identify and eliminate bottlenecks and waste in the end-to-end flow from initial discovery to ongoing support.

    VSM provides a visual representation of how value flows, highlighting where delays (e.g., manual approvals or siloed handoffs) occur.

    • ✗ To provide a detailed architectural diagram of the server infrastructure and cloud networking components.

      Infrastructure diagrams focus on technology; VSM focuses on the activities, timing, and information flow that create value.

    • ✗ To replace the need for SLOs by providing a purely qualitative view of service performance.

      VSM is complementary to SLOs; it helps improve the process that *produces* the service levels being measured.

    • ✗ To ensure that every step in the 'Build' phase takes exactly the same amount of time.

      The goal is to optimize the whole system, not necessarily to make every individual step identical in duration.

14. 14 In the ITIL 5 Product and Service Lifecycle, why is Site Reliability Engineering (SRE) increasingly involved in the 'Design' phase?

    Think about the benefits of 'shifting left' in the context of service reliability.

    To ensure that reliability requirements and observability 'hooks' are built into the product from the beginning.

    Designing for reliability (Shift Left) is far more effective and less costly than trying to add stability after a product has already been built.

    • ✗ To prevent developers from using any new technologies that have not been in production for at least five years.

      SREs facilitate innovation by making new technologies safe and reliable, not by being an 'anti-innovation' gatekeeper.

    • ✗ To take over the role of the Product Owner and prioritize the backlog based on server uptime.

      SREs collaborate with Product Owners; they do not replace the role which focuses on business value and user needs.

    • ✗ To ensure that the 'Design' phase takes twice as long as the 'Build' phase to maximize stability.

      The goal is to design *smarter* for reliability, not necessarily to slow down the delivery lifecycle.

15. 15 An organization is moving toward 'Shift Left' testing. What does this mean for the ITIL 5 'Transition' activity?

    Consider the timing of quality assurance activities in a traditional vs. modern lifecycle.

    Testing and validation occur continuously during the 'Build' phase rather than as a single, massive phase before release.

    By testing early and often, defects are found when they are easiest to fix, leading to a smoother and faster transition to live environments.

    • ✗ The entire 'Transition' phase is moved to occur before the 'Design' phase to ensure requirements are met.

      Transitioning a product that hasn't been designed or built is logically impossible; shift left refers to moving *activities* earlier.

    • ✗ Testing is delegated entirely to the end-users to reduce the internal cost of the 'Build' phase.

      While user feedback is important, shifting left focuses on automated engineering tests during development.

    • ✗ All 'Transition' activities are handled by the legal team to ensure compliance with digital ethics.

      Transition is a multi-disciplinary activity involving technical, operational, and organizational change, not just legal review.

16. 16 What is a 'Stop the Line' mentality in the context of ITIL 5 error budgets?

    Relate the concept to a factory floor where an assembly line is stopped to fix a systemic quality problem.

    A policy where exceeding an error budget triggers an immediate pivot from new feature work to reliability engineering.

    Borrowing from Lean manufacturing, this ensures that reliability issues are treated as critical defects that must be resolved before proceeding.

    • ✗ A technical failure that causes the entire Internet to become inaccessible for an organization's users.

      This is a catastrophic outage, not a management mentality or a governance policy.

    • ✗ A decision by the Strategic Leader to shut down a business unit that is not meeting its revenue targets.

      This is a strategic divestment, not an operational reliability mechanism linked to error budgets.

    • ✗ The process of manually stopping a CI/CD pipeline every time a minor spelling error is found in documentation.

      'Stop the line' is for critical quality or reliability issues, not for trivial errors that don't impact service performance.

17. 17 How does ITIL 5 define 'Platform Engineering' as a 'Product'?

    Think about the relationship between the people who build the platform and the people who use it.

    The platform team treats internal developers as customers, gathering feedback to improve the usability and value of the platform's services.

    This approach ensures the platform actually solves developer problems and is adopted voluntarily rather than forced upon teams.

    • ✗ The platform is packaged and sold to external competitors to generate additional revenue for the organization.

      While possible, 'Platform as a Product' in this context refers to the internal service provided to an organization's own developers.

    • ✗ The platform is treated as a static one-time project that requires no ongoing improvement after the 'Build' phase.

      Products require ongoing lifecycle management, support, and evolution, whereas projects are temporary endeavors.

    • ✗ The platform must have its own separate branding and marketing team to ensure it is visible to the CEO.

      Internal product management focuses on user needs and value delivery, not external marketing or executive optics.

18. 18 Why is 'Psychological Safety' considered a critical component of Domain 5 (High Velocity IT)?

    Consider how the fear of being fired or blamed affects how someone responds to a system failure.

    It enables team members to report errors and suggest risky improvements without fear of punishment, facilitating faster learning.

    Innovation and reliability both depend on transparency; if people fear blame, they hide mistakes, making the system more fragile.

    • ✗ It ensures that the organization is legally protected from lawsuits related to workplace stress.

      While important for HR, psychological safety in HVIT is specifically about its impact on transparency, learning, and technical performance.

    • ✗ It is a requirement for AIOps systems to ensure that the AI does not develop 'biases' against certain employees.

      AIOps bias is a technical and ethical issue; psychological safety is a human and cultural factor within the team.

    • ✗ It prevents developers from ever having to work on 'Support' activities to keep their stress levels low.

      SRE and DevOps actually encourage shared responsibility, which often means developers *do* participate in support.

19. 19 In the ITIL 5 Product and Service Lifecycle, where does 'Continuous Delivery' (CD) have the most significant impact?

    Identify the part of the lifecycle where software moves from 'code' to 'working service'.

    Between 'Build' and 'Transition', ensuring that code is always in a deployable state and ready for live environment movement.

    CD bridges development and operations by automating the release process, ensuring that the 'Transition' to live is frequent and low-risk.

    • ✗ Exclusively in the 'Discover' phase to ensure that stakeholder needs are met instantaneously.

      Discovery is about research and understanding; CD is about the mechanical process of delivering software artifacts.

    • ✗ In the 'Acquire' phase to ensure that all third-party software is updated every hour.

      CD is primarily used for internal software development value streams, though it can interact with third-party components.

    • ✗ In the 'Strategic Leader' stream to ensure that organizational goals never change.

      Strategic goals *should* change to meet market needs; CD provides the speed to implement those changes, it doesn't freeze them.

20. 20 What is the role of 'Error Budgets' in managing 'Technical Debt' in ITIL 5?

    Think about how a team decides when it's time to stop building new things and start fixing old ones.

    Error budgets provide the 'permission' to pay down technical debt by allocating engineering time to stability when reliability targets are threatened.

    They provide a data-driven justification for prioritizing refactoring and architectural fixes over new feature development.

    • ✗ Error budgets are used to pay the interest on financial loans taken out to buy new servers.

      This is a literal interpretation of 'budget' that ignores the SRE concept of managing reliability via failure tolerance.

    • ✗ Technical debt is ignored until the error budget is 100% consumed, at which point the product is decommissioned.

      The goal is to proactively manage debt; waiting until the budget is gone to decommission is a failure of management.

    • ✗ Error budgets ensure that technical debt can only be created by the 'Strategy' team.

      Technical debt is usually a byproduct of build and design decisions made at the team level, not just strategy.

21. 21 How does ITIL 5 define the 'SRE 50% Rule' for managing toil?

    Consider the balance between 'doing work' and 'building things that do the work for you'.

    SREs should spend at least 50% of their time on long-term engineering projects that improve system reliability and reduce future manual work.

    Capping manual 'toil' (like ticket handling) at 50% prevents SREs from becoming traditional operations staff and ensures the system evolves.

    • ✗ Exactly 50% of all incidents must be resolved by the AI before a human is allowed to intervene.

      While AIOps helps, there is no fixed percentage requirement for AI resolution in the core SRE discipline.

    • ✗ At least 50% of the organization must be certified as ITIL Masters before SRE can be implemented.

      SRE and ITIL can be implemented at any scale of certification; it is about practice and mindset, not a specific credential quota.

    • ✗ The 'Build' phase must be 50% shorter than the 'Operate' phase to ensure a balanced lifecycle.

      Lifecycle phase durations vary wildly by product and context; there is no universal 50% time-based ratio.

22. 22 What is the primary benefit of using 'Canary Deployments' within the ITIL 5 'Transition' and 'Deliver' activities?

    Think about how miners used canaries to detect dangerous gases before they harmed the whole group.

    It allows for testing a new version on a small subset of real users to detect issues before a full-scale rollout.

    Canary releases minimize the 'blast radius' of potential failures by incrementally exposing users to the new version.

    • ✗ It ensures that the 'Support' team is only notified of an incident after at least 50% of users are impacted.

      The goal is to detect issues *before* they impact many users; delaying notification would be counterproductive.

    • ✗ It is a specific type of AIOps algorithm used to detect wildlife patterns in environmental digital products.

      This is a literal interpretation of 'Canary' that ignores its well-established meaning in software deployment.

    • ✗ It replaces the need for 'Design' by allowing the team to just build and see what happens in live.

      Canary deployments are a tool for *validation*; they do not replace the need for thoughtful design and architecture.

23. 23 Which of the following metrics would be considered an 'Experience Level Agreement' (XLA) rather than a traditional Service Level Agreement (SLA)?

    Look for the option that focuses on the human element rather than the machine element.

    The perceived ease of use and satisfaction rating of a customer after completing a service journey.

    XLAs focus on outcomes and sentiments (how the user felt), whereas SLAs focus on outputs and technical constraints (uptime, response time).

    • ✗ The average time it takes for a server to respond to a database query in milliseconds.

      This is a technical performance metric, typical of an SLA or a supporting OLA (Operating Level Agreement).

    • ✗ The total percentage of time the network was available during a 30-day period.

      Uptime percentage is the classic example of a technical SLA measurement.

    • ✗ The number of lines of code written by a developer during a two-week sprint.

      This is a productivity or output metric; it does not measure the quality of the service or the user's experience.

24. 24 In ITIL 5, what is the 'Blast Radius' and why does SRE attempt to minimize it?

    Think about how an explosion can be contained to a single room instead of destroying a whole building.

    It is the potential impact of a failure; minimizing it ensures that an incident only affects a small portion of the system or user base.

    Techniques like microservices, canary releases, and circuit breakers are used to contain failures and prevent them from cascading.

    • ✗ It is the physical distance between the primary and secondary data centers in case of a natural disaster.

      This refers to geographic redundancy; 'blast radius' in SRE is usually about logical system components and user groups.

    • ✗ It is the amount of money an organization loses per minute during a total outage.

      This is the 'cost of downtime,' which is a financial consequence of the blast radius, not the radius itself.

    • ✗ It is a mandatory SRE training program for all employees working in the 'Support' phase.

      Blast radius is a system design and risk management concept, not an education or training initiative.

25. 25 Which ITIL 5 management practice is most closely aligned with the 'SRE' focus on automated incident response?

    Identify the practice that deals with the observation of system state and the triggers for action.

    Monitoring and Event Management

    SREs use this practice to build self-healing systems that detect and resolve common incidents without human intervention.

    • ✗ Service Financial Management

      Financial management focuses on costs and budgets; while SREs care about cost-efficiency, their core is reliability and operation.

    • ✗ Relationship Management

      This focuses on the human stakeholders and business alignment, whereas incident response is a technical management discipline.

    • ✗ Service Catalogue Management

      The catalogue defines *what* is offered; SRE incident response focuses on *how* those offerings are kept stable.

26. 26 How does ITIL 5's 'Digital Ethics' apply to Domain 5 (DevOps and SRE)?

    Think about the ethical risks of removing human oversight from rapid, automated processes.

    By ensuring that automated deployment pipelines and AIOps algorithms do not introduce or amplify harmful biases.

    In a high-velocity environment, ethical considerations must be baked into the automation to prevent large-scale unintended consequences.

    • ✗ By requiring all developers to work exactly 40 hours a week to ensure a 'fair' distribution of labor.

      Workforce scheduling is a management task; digital ethics specifically addresses the moral implications of technology use and data.

    • ✗ By preventing the use of any open-source software that was written by more than ten people.

      Open source is a common component of modern delivery; the number of contributors has no ethical standing in ITIL.

    • ✗ By ensuring that all digital products are sold at the lowest possible price to every customer.

      Pricing strategy is a business and marketing decision; digital ethics focuses on issues like privacy, fairness, and transparency.

27. 27 In a high-velocity ITIL 5 environment, what is the role of a 'Circuit Breaker' pattern?

    Think about why a house has an electrical circuit breaker and apply that logic to a web of software services.

    A design pattern that automatically stops requests to a failing service to prevent the failure from cascading through the system.

    Circuit breakers allow a failing component to recover by temporarily offloading its traffic, protecting the rest of the architecture.

    • ✗ A physical switch in the data center that must be flipped by an SRE whenever an incident occurs.

      In modern digital services, these patterns are implemented in software and occur automatically without physical intervention.

    • ✗ A governance rule that prevents the Strategic Leader from making more than one decision per day.

      The concept refers to technical resilience in distributed systems, not organizational leadership constraints.

    • ✗ A way to automatically shut down the entire 'Build' phase if the company's electricity bill is too high.

      This is a cost-control measure (or a physical electrical issue); it does not describe the SRE/DevOps resiliency pattern.

28. 28 How does 'Continuous Improvement' (CI) manifest in the ITIL 5 'Support' activity for high-velocity services?

    Think about how a team learns from a failure so that the same failure never happens again.

    By using feedback from incident resolutions and blameless postmortems to update the automated test suites and platform guardrails.

    Support is not just about fixing; it's a critical data source for improving the 'Build' and 'Design' phases to prevent future issues.

    • ✗ By ensuring that the Service Desk team never has to talk to the same customer twice about the same problem.

      While desirable, 'improvement' in this context is about systemic technical changes, not just individual customer interactions.

    • ✗ By deleting all documentation every six months to ensure that the team is always 'improving' their memory.

      Losing knowledge is the opposite of improvement; CI relies on building and refining a repository of organizational knowledge.

    • ✗ By making the 'Build' phase slower each month to ensure that fewer incidents ever reach the 'Support' phase.

      The goal is to maintain or increase velocity while *simultaneously* improving reliability through better engineering.

29. 29 In the ITIL 5 qualification scheme, which module specifically focuses on integrating SRE, error budgets, and platform engineering?

    Identify the advanced module that is core to the Managing Professional stream and deals with technical delivery.

    ITIL Product

    ITIL Product covers the end-to-end value stream, including the high-velocity engineering practices needed for reliable digital offerings.

    • ✗ ITIL Strategy

      Strategy focuses on board-level governance and portfolio direction, providing the 'why' rather than the 'how' of SRE.

    • ✗ ITIL Foundation

      Foundation introduces the high-level concepts but does not go into the managerial depth of SRE and platform engineering.

    • ✗ ITIL AI Governance

      This is an extension module focused on ethical and responsible AI use, not the broader DevOps/SRE operating model.

30. 30 What is 'Chaos Engineering Awareness' as described in the ITIL 5 Managing Professional syllabus?

    Focus on the proactive and experimental nature of this reliability practice.

    Understanding that injecting controlled failures into a system is a valid way to uncover and fix latent reliability risks.

    Chaos engineering builds 'resilience by design' by proactively testing how a system handles stress before an actual outage occurs.

    • ✗ The belief that IT systems are naturally chaotic and that no amount of engineering can ever create stability.

      This is a fatalistic view that contradicts the proactive, engineering-led approach of SRE and ITIL.

    • ✗ A training program to teach users how to remain calm when the organization's digital services are failing.

      Chaos engineering is a technical discipline; 'awareness' refers to the management understanding of this practice.

    • ✗ The mandatory use of AI to create random code changes that developers must then fix as a 'fire drill'.

      Chaos engineering tests the *environment* and *system* resilience (e.g., pulling a server), not testing developers with broken code.