A service level agreement lists twenty individual measures such as CPU utilisation, network latency and patch currency, but no measure of what the customer is trying to achieve. Why is this a weakness?
ITIL 4 Foundation, objective 7. Seven ITIL practices in detail medium
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Not correct Operational metrics belong in an operational level agreement, and may never appear in a customer-facing agreement
Too absolute. Component and operational measures can be useful supporting detail; the failure is having only those, with nothing that expresses the customer's desired outcome.
Not correct Twenty measures is too many; an agreement should never contain more than a handful of targets
The problem is what the measures are about, not how many there are. A count limit is not the principle; relating targets to outcomes is.
Correct Service level agreements should relate to defined outcomes, ideally through a balanced bundle of measures, rather than to operational metrics alone
Correct. Targets tied to defined outcomes — supported by a balance of measures such as business results and customer satisfaction — tell you whether the service is actually helping the customer.
Not correct Technical measures cannot be monitored reliably enough to be used as agreed targets
These measures are usually the easiest of all to collect reliably. Ease of measurement is precisely why organizations over-use them and end up measuring the wrong thing well.
Why
A good SLA expresses what the customer wants to achieve, not just how the components behaved. Component metrics are easy to collect and easy to hit, which is how organizations end up with agreements that are met in full while the customer's outcome is not. The corrective principle is outcome-related targets carried by a balanced bundle of measures, not a cap on the number of targets or a ban on technical data.
Where this comes from
- Cited
- ITIL 4 syllabus clause 7
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 7 and space the ones you get wrong.
More questions on this objective
- Which statement best describes what the incident management practice is intended to achieve? machine-checked
- How is an incident defined in ITIL? machine-checked
- Several incidents are open at once and the support team must decide which to work on first. On what basis should the order be decided? machine-checked
- A difficult incident is worked on by pulling several specialists from different teams into the same session at the same time; once it becomes clear who is best placed to continue, the others step away. What is this technique called? machine-checked
- Why does an organisation define a separate procedure for major incidents rather than handling them exactly like all other incidents? machine-checked
- A support team routinely fixes incidents by phone and updates the incident record only with the word 'fixed'. What is the most significant consequence of this? machine-checked