ITIL 4 Cloud Services common mistakes
ITIL 4 Cloud Services · Understand the traps and how to avoid them.
Treating the cloud service provider as the sole owner of every risk once a workload is migrated, so questions about shared responsibility are answered with 'the provider handles it' rather than assigning each risk to the party that actually controls it.
Candidates carry over the traditional outsourcing intuition that a managed service transfers accountability. In cloud, the provider controls the physical and virtualisation layers while the consumer still owns identity, configuration, data classification and access design, and exam items probe exactly that boundary.
What to do instead
For every scenario, split the stack into provider-controlled layers (facilities, hardware, hypervisor, managed platform internals) and consumer-controlled layers (identities, data, configuration, integrations). Write the risk owner next to each layer before choosing an answer, and remember accountability for the consumer's own use of the service never transfers.
Selecting the cheapest or most feature-rich service tier in a scenario question without first extracting the stated availability, latency, data-residency or recovery requirements, then defending the choice with generic 'cost optimisation' language.
Candidates recognise cost as a familiar ITIL theme and anchor on it, while the scenario deliberately embeds a non-negotiable constraint (for example a regulated data location or a recovery time objective) that eliminates the low-cost option.
What to do instead
Read the scenario twice: first to list every hard constraint as a checklist, second to evaluate options. Eliminate any option that violates a constraint before comparing cost, and justify the final answer by naming which requirement drove the choice.
Confusing the service value chain's 'obtain/build' and 'design and transition' activities with lifecycle stages, and mapping cloud provisioning steps to the wrong activity in value-stream questions.
The ITIL 4 value chain replaced the earlier lifecycle stages, but candidates often still reason in lifecycle terms and mislabel activities such as acquiring a SaaS subscription or onboarding a tenant.
What to do instead
Memorise the six activities as verbs describing what the organisation does (plan, improve, engage, design and transition, obtain/build, deliver and support) and practise mapping a cloud onboarding value stream step by step, naming the activity for each step and the practice involved.
Answering continual improvement questions by proposing a tool or automation purchase instead of describing the improvement model's iterative steps and how the improvement is measured and validated.
Cloud contexts prime candidates to think in terms of platform features, so they skip the disciplined sequence of understanding the current state, defining the target, and iterating with measurement.
What to do instead
Structure every improvement answer around the iterative model: what is the vision and current state, what is the measurable target, which steps and owners, how will success be verified, and how will the result be fed back. Name the metric and the review cadence explicitly.
Treating cloud cost management as a finance-only activity and failing to connect consumption-based charging to demand management, capacity planning and value-stream economics in scenario questions.
On-premises thinking separates capacity decisions from budgeting, whereas cloud makes consumption, elasticity and spend a single operational lever that ITIL frames through demand and value-stream practices.
What to do instead
Link each cost question to the practice that controls it: demand management shapes consumption, capacity and performance management sets service targets, and portfolio management decides what should exist. State the lever, the metric and the owner rather than only 'monitor spend'.
Assuming a cloud provider's compliance certifications and audit reports automatically make the consumer's deployed solution compliant, and answering compliance questions on that basis.
Provider attestations are visible and reassuring, so candidates overlook that the consumer must still configure controls, classify data, manage identities and evidence its own use of the service.
What to do instead
Separate provider attestation (inherited controls) from consumer obligations (configured and operated controls). For each compliance requirement, state what is inherited, what must be configured, and what evidence the consumer must produce.
Describing cloud change management as a choice between 'all changes need a full approval board' and 'cloud means no change control', rather than matching the change approach to risk and type.
Candidates overcorrect from traditional heavy governance to a permissive stance, or cling to the old model, missing the ITIL 4 position that change enablement scales control to risk and automates standard changes.
What to do instead
Classify the change first: standard, normal or emergency, and note whether it is automated through a pipeline. Then describe the proportionate authorisation, the automated checks that replace manual review, and how the change record supports later improvement.
Answering incident and problem questions with cloud-provider escalation alone, omitting the consumer's own diagnostic data, service level evidence and the distinction between restoring service and removing the underlying cause.
The provider owns parts of the stack, so candidates assume the provider owns the whole response and forget the consumer's obligations to monitor, supply evidence and manage its own configuration.
What to do instead
For each incident scenario, state what the consumer monitors and can diagnose locally, what it escalates and with what evidence, what the agreed service level says, and separately how the problem record will pursue root cause across the shared boundary.
Treating cloud migration as a one-off project decision and ignoring exit, portability and reversibility considerations when the scenario asks about strategy or design.
Candidates focus on the benefits of adoption and forget that cloud strategy includes avoiding lock-in, retaining exit options and designing for portability, which exam scenarios test through vendor-dependency and data-return questions.
What to do instead
For any strategy or design question, add an exit check: what data and configuration must be portable, what contractual and technical exit terms apply, and what would trigger a move. Include reversibility as an explicit design criterion alongside availability and cost.
Using vague value language such as 'improves customer satisfaction' without naming the stakeholder, the outcome, the co-created value and the feedback loop that confirms it.
Value creation is easy to state abstractly, and candidates default to generic benefits rather than the ITIL 4 emphasis on outcomes, co-creation with stakeholders and continuous feedback.
What to do instead
For each value question, name the stakeholder group, the outcome they need, which organisation and partners co-create it, the service or product that enables it, and the feedback mechanism that shows whether the outcome was achieved.