ITIL® Foundation (Version 5) interview questions

An incident is an unplanned interruption or loss of quality of a service; the goal is to restore service quickly. A problem is the cause, or potential cause, of one or more incidents; problem management finds and removes the root cause. A known error is a problem that has been analysed but not yet fixed, often with a workaround.

What they are checking: The core distinction every ITSM role is asked.

Likely follow-up: When would you open a problem record?

A service request is a normal, pre-agreed request from a user, such as a new laptop, access or a password reset. Nothing is broken. It should follow a standard, often automated, fulfilment process, while incidents follow restoration.

What they are checking: Correct classification at the service desk.

Likely follow-up: Why does wrong classification hurt reporting?

Standard changes are low-risk, pre-authorized and repeatable (often automated). Normal changes need assessment and authorization based on risk. Emergency changes must be done as soon as possible, for example to fix a major incident, with fast-tracked authorization and review after.

What they are checking: Change enablement basics.

Likely follow-up: How do you decide who authorizes a normal change?

Value is not delivered one way by IT; it is created together with the consumer. The service provider supplies the service, and the user or customer contributes their use, data and feedback. Good outcomes depend on both sides, so you design services around what users are trying to achieve.

What they are checking: Understanding modern ITIL thinking, not just processes.

Likely follow-up: Give an example of a service where the user affects the value.

Declare a major incident, assign an incident manager, log one parent incident and link the user calls to it, update users quickly (status page, banner, email to managers) with regular updates, bring in the technical teams, and after recovery open a problem record and hold a review.

What they are checking: Major incident handling and communication.

Likely follow-up: What goes into a post-incident review?

Useful: first contact resolution, time to restore, customer satisfaction and backlog age. Misleading if used alone: number of tickets closed or average handle time, because they push staff to close tickets fast instead of fixing them. Balance speed with quality and outcomes.

What they are checking: Measuring outcomes, not activity.

Likely follow-up: What is a watermelon SLA?

The service described in business terms, targets users care about (availability, response and resolution times by priority), how they are measured and reported, responsibilities on both sides, and how disputes or reviews happen. Targets should reflect real user experience.

What they are checking: Writing SLAs that mean something.

Likely follow-up: What is the difference between an SLA and an OLA?

Look at the data to find the top repeat issues, ask what the vision is, measure where you are, set a target, and act: knowledge articles, self-service, fixing root causes through problem management and automation. Check the results and repeat.

What they are checking: Applying the improvement model to real data.

Likely follow-up: What are the steps of the continual improvement model?

Focus on value: before adding a new approval step, ask whether it helps the user or only adds delay. Start where you are: before replacing a tool, check what already works and reuse it. Others include progress iteratively with feedback, keep it simple and practical, and optimize and automate.

What they are checking: Turning principles into actions.

Likely follow-up: Which principle do teams ignore most often?

Listen and acknowledge the impact, explain what is being done and when the next update will come, keep that promise, and escalate if the business impact justifies it. Stay professional, and do not promise what you cannot deliver.

What they are checking: Customer handling and calm communication.

Likely follow-up: When is it right to escalate a VIP issue?