CIAN Basic Certificate common mistakes
CIAN Basic Certificate · Understand the traps and how to avoid them.
Treating the ITIL 4 definition of a service as 'a product the customer buys' and selecting answers that describe goods or deliverables rather than a means of enabling value co-creation.
Candidates carry over everyday commercial intuition and skim the definition, so they miss that the service definition centres on enabling customer outcomes without the customer owning specific costs and risks.
What to do instead
Memorise the service definition word-for-word and test each option against it: does the option describe enabling an outcome, and does it reference shifting costs and risks away from the consumer? Reject options that only describe outputs or tangible goods.
Confusing the four dimensions of service management with the components of the ITIL service value system, and picking an answer that lists 'organizations and people, information and technology, partners and suppliers, value streams and processes' when the question asks about SVS components.
Both are four- or multi-item lists learned close together, and candidates pattern-match on the first familiar list they recognise rather than reading what the question stem actually asks for.
What to do instead
Build a two-column recall sheet: one column for the four dimensions, one for the SVS components (guiding principles, governance, service value chain, practices, continual improvement). Before answering, underline the term in the stem and match it to the correct column.
Describing value as something the provider creates and delivers to the consumer, rather than as co-created through the interaction of provider and consumer.
The phrasing 'value creation' invites a one-directional mental model from manufacturing, and many distractors are written to sound plausible under that model.
What to do instead
Adopt the rule 'no service, no value'. For any value-related question, check whether the option requires the consumer's active participation (outcomes, use, feedback). Eliminate options where the provider alone produces value.
Mixing up the purpose of the service value chain activities, for example assigning 'ensure continual improvement of products and services' to Engage instead of Improve, or placing warranty-related activity in Plan.
The six activities are memorised as a list without their distinct purposes, and several activities overlap in everyday language (Engage sounds like it covers everything customer-facing).
What to do instead
Write a one-line purpose for each of the six activities in your own words and drill with scenario stems: identify the verb in the scenario (negotiating, designing, building, supporting, improving) and map it to the activity whose purpose uses that verb.
Treating utility and warranty as synonyms or assuming a service with high utility automatically has high warranty, then choosing an answer that says the service is 'fit for purpose' when the scenario describes capacity or availability failures.
Candidates remember 'fit for purpose' and 'fit for use' as a pair but swap which one belongs to utility versus warranty, especially under time pressure.
What to do instead
Anchor with a mnemonic you generate yourself linking utility to purpose (what it does) and warranty to use (how reliably it does it). In scenarios, look for failure keywords: 'doesn't do what we need' points to utility; 'unavailable, too slow, insecure, not continuous' points to warranty.
Confusing the purpose of service design with that of service transition, for example selecting 'design' answers for questions about release, deployment, or change control.
The design and transition domains share vocabulary (changes, releases, configurations) and candidates answer based on the noun in the stem rather than the lifecycle phase being tested.
What to do instead
Classify each practice by its core question: design asks 'what should it look like and meet which requirements?'; transition asks 'how do we move it into live operation safely?'. Practise sorting a list of activities into these two buckets until it is automatic.
Selecting 'change management' as the answer for any question involving a change, even when the scenario is about planning and scheduling many changes together, which belongs to release and deployment or change scheduling and planning activities.
Change enablement is the best-known practice, so it becomes a default answer; candidates do not distinguish the control of individual changes from the coordination of many changes into a release.
What to do instead
Learn the boundary: change enablement authorises and assesses risk of changes; release management makes changes available for use; deployment moves components into live environments. Read the stem for 'authorise/assess' versus 'schedule/bundle/make available' and choose accordingly.
Assigning incident and problem management to the wrong trigger, for example treating a recurring incident as automatically a problem record, or using problem management to restore service.
The overlap between restoring service quickly and finding root cause is intuitive but the exam tests the distinct purposes; candidates answer from general troubleshooting instinct.
What to do instead
Fix the two purposes in memory: incident management restores normal service as quickly as possible; problem management reduces the likelihood and impact of incidents by managing causes and workarounds. In each scenario ask 'is the question about speed of recovery or about eliminating the cause?' and choose only that practice.
Confusing the service desk's role with that of technical support teams, or misclassifying a request as an incident (and vice versa) when the user asks for information, access, or a standard change.
Both practices involve user contact and both are logged as tickets, so candidates classify by who is talking rather than by the nature of the demand.
What to do instead
Apply a decision rule: has something stopped working or degraded unexpectedly (incident), or is this a normal, pre-approved request for something the user wants (service request)? Separately, remember the service desk is the single point of contact and owns capture and communication, while support teams own resolution.
Choosing a metric because it is easy to count rather than because it measures an outcome, and failing to distinguish leading from lagging indicators or to recognise the role of KPIs in the continual improvement model.
Candidates default to familiar operational numbers (tickets closed, uptime) and have not practised evaluating whether a measure reflects value, so distractors that look quantitative feel authoritative.
What to do instead
Before selecting a measure, ask three questions: whose behaviour does it change, does it reflect an outcome or just activity, and is it leading or lagging? Reject pure activity counts. Also revise the continual improvement model steps so you can place 'where are we now' and 'how do we get there' correctly in sequence.
Treating governance and compliance as interchangeable with management, or assuming the governing body makes operational decisions, leading to answers that give the board responsibility for approving individual changes.
Everyday usage of 'governance' as a synonym for 'management' conflicts with the exam's separation of direction, oversight, and evaluation from day-to-day decision-making.
What to do instead
Learn governance as evaluate, direct, monitor performed by the governing body, and management as planning, executing, and controlling. For any scenario, ask whether the question is about setting direction and assurance or about running the process, and assign responsibility to the matching level.